doc: Add RFC documents

1 files changed, 542 insertions, 0 deletions

diff --git a/doc/rfc/rfc9655.txt b/doc/rfc/rfc9655.txt
new file mode 100644
index 0000000..4b61e71
--- /dev/null
+++ b/doc/rfc/rfc9655.txt
@@ -0,0 +1,542 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                     D. Rathi, Ed.
+Request for Comments: 9655                                         Nokia
+Category: Standards Track                                  S. Hegde, Ed.
+ISSN: 2070-1721                                    Juniper Networks Inc.
+                                                                K. Arora
+                                                  Individual Contributor
+                                                                  Z. Ali
+                                                               N. Nainar
+                                                     Cisco Systems, Inc.
+                                                           November 2024
+
+
+Egress Validation in Label Switched Path Ping and Traceroute Mechanisms
+
+Abstract
+
+   The MPLS ping and traceroute mechanisms described in RFC 8029 and the
+   related extensions for Segment Routing (SR) defined in RFC 8287 are
+   highly valuable for validating control plane and data plane
+   synchronization.  In certain environments, only some intermediate or
+   transit nodes may have been upgraded to support these validation
+   procedures.  A straightforward MPLS ping and traceroute mechanism
+   allows traversal of any path without validation of the control plane
+   state.  RFC 8029 supports this mechanism with the Nil Forwarding
+   Equivalence Class (FEC).  The procedures outlined in RFC 8029 are
+   primarily applicable when the Nil FEC is used as an intermediate FEC
+   in the FEC stack.  However, challenges arise when all labels in the
+   label stack are represented using the Nil FEC.
+
+   This document introduces a new Type-Length-Value (TLV) as an
+   extension to the existing Nil FEC.  It describes MPLS ping and
+   traceroute procedures using the Nil FEC with this extension to
+   address and overcome these challenges.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9655.
+
+Copyright Notice
+
+   Copyright (c) 2024 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Requirements Language
+   2.  Problem with Nil FEC
+   3.  Egress TLV
+   4.  Procedure
+     4.1.  Sending Egress TLV in MPLS Echo Request
+       4.1.1.  Ping Mode
+       4.1.2.  Traceroute Mode
+       4.1.3.  Detailed Example
+     4.2.  Receiving Egress TLV in MPLS Echo Request
+   5.  Backward Compatibility
+   6.  IANA Considerations
+     6.1.  New TLV
+     6.2.  New Return Code
+   7.  Security Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   Segment routing supports the creation of explicit paths by using one
+   or more Link-State IGP Segments or BGP Segments defined in [RFC8402].
+   In certain use cases, the TE paths are built using mechanisms
+   described in [RFC9256] by stacking the labels that represent the
+   nodes and links in the explicit path.  Controllers are often deployed
+   to construct paths across multi-domain networks.  In such
+   deployments, the headend routers may have the link-state database of
+   their domain and may not be aware of the FEC associated with labels
+   that are used by the controller to build paths across multiple
+   domains.  A very useful Operations, Administration, and Maintenance
+   (OAM) requirement is to be able to ping and trace these paths.
+
+   [RFC8029] describes a simple and efficient mechanism to detect data
+   plane failures in MPLS Label Switched Paths (LSPs).  It defines a
+   probe message called an "MPLS echo request" and a response message
+   called an "MPLS echo reply" for returning the result of the probe.
+   SR-related extensions for these are specified in [RFC8287].
+   [RFC8029] provides mechanisms primarily to validate the data plane
+   and secondarily to verify the consistency of the data plane with the
+   control plane.  It also provides the ability to traverse Equal-Cost
+   Multipaths (ECMPs) and validate each of the ECMP paths.  The Target
+   FEC Stack TLV [RFC8029] contains sub-TLVs that carry information
+   about the label.  This information gets validated on each node for
+   traceroute and on the egress for ping.  The use of the Target FEC
+   Stack TLV requires all nodes in the network to have implemented the
+   validation procedures, but all intermediate nodes may not have been
+   upgraded to support validation procedures.  In such cases, it is
+   useful to have the ability to traverse the paths in ping/traceroute
+   mode without having to obtain the FEC for each label.
+
+   A simple MPLS echo request/reply mechanism allows for traversing the
+   SR Policy path without validating the control plane state.  [RFC8029]
+   supports this mechanism with FECs like the Nil FEC and the Generic
+   FECs (i.e., Generic IPv4 prefix and Generic IPv6 prefix).  However,
+   there are challenges in reusing the Nil FEC and Generic FECs for
+   validation of SR Policies [RFC9256].  The Generic IPv4 prefix and
+   Generic IPv6 prefix FECs are used when the protocol that is
+   advertising the label is unknown.  The information that is carried in
+   the Generic FECs is the IPv4 or IPv6 prefix and prefix length.  Thus,
+   the Generic FEC types perform an additional control plane validation.
+   However, the Generic FECs and relevant validation procedures are not
+   thoroughly detailed in [RFC8029].  The use case mostly specifies
+   inter-AS (Autonomous System) VPNs as the motivation.  Certain aspects
+   of SR, such as anycast Segment Identifiers (SIDs), require clear
+   guidelines on how the validation procedure should work.  Also, the
+   Generic FECs may not be widely supported, and if transit routers are
+   not upgraded to support validation of Generic FECs, traceroute may
+   fail.  On the other hand, the Nil FEC consists of the label, and
+   there is no other associated FEC information.  The Nil FEC is used to
+   traverse the path without validation for cases where the FEC is not
+   defined or routers are not upgraded to support the FECs.  Thus, it
+   can be used to check any combination of segments on any data path.
+   The procedures described in [RFC8029] are mostly applicable when the
+   Nil FEC is used as an intermediate FEC in the FEC stack.  Challenges
+   arise when all labels in the label stack are represented using the
+   Nil FEC.
+
+   Section 2 discusses the problems associated with using the Nil FEC in
+   an MPLS ping/traceroute procedure, and Sections 3 and 4 discuss
+   simple extensions needed to solve the problem.
+
+   The problems and the solutions described in this document apply to
+   the MPLS data plane.  Segment Routing over IPv6 (SRv6) is out of
+   scope for this document.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Problem with Nil FEC
+
+   The purpose of the Nil FEC, as described in [RFC8029], is to ensure
+   that transit tunnel information is hidden and, in some cases, to
+   avoid false negatives when the FEC information is unknown.
+
+   This document uses a Nil FEC to represent the complete label stack in
+   an MPLS echo request message in ping and traceroute mode.  A single
+   Nil FEC is used in the MPLS echo request message irrespective of the
+   number of segments in the label stack.  Section 4.4.1 of [RFC8029]
+   notes:
+
+   |  If the outermost FEC of the Target FEC stack is the Nil FEC, then
+   |  the node MUST skip the Target FEC validation completely.
+
+   When a router in the label stack path receives an MPLS echo request
+   message, there is no definite way to decide whether it is the
+   intended egress router since the Nil FEC does not carry any
+   information and no validation is performed by the router.  Thus,
+   there is a high possibility that the packet may be misforwarded to an
+   incorrect destination but the MPLS echo reply might still return
+   success.
+
+   To mitigate this issue, it is necessary to include additional
+   information, along with the Nil FEC, in the MPLS echo request message
+   in both ping and traceroute modes and to perform minimal validation
+   on the egress/destination router.  This will enable the router to
+   send appropriate success and failure information to the headend
+   router of the SR Policy.  This supplementary information should
+   assist in reporting transit router details to the headend router,
+   which can be utilized by an offline application to validate the
+   traceroute path.
+
+   Consequently, the inclusion of egress information in the MPLS echo
+   request messages in ping and traceroute modes will facilitate the
+   validation of the Nil FEC on the egress router, ensuring the correct
+   destination.  Egress information can be employed to verify any
+   combination of segments on any path without requiring upgrades to
+   transit nodes.  The Egress TLV can be silently dropped if not
+   recognized; alternately, it may be stepped over, or an error message
+   may be sent (per [RFC8029] and the clarifications in [RFC9041]
+   regarding code points in the range 32768-65535).
+
+   If a transit node does not recognize the Egress TLV and chooses to
+   silently drop or step over the Egress TLV, the headend will continue
+   to send the Egress TLV in the next echo request message, and if
+   egress recognizes the Egress TLV, egress validation will be executed
+   at the egress.  If a transit node does not recognize the Egress TLV
+   and chooses to send an error message, the headend will log the
+   message for informational purposes and continue to send echo requests
+   with the Egress TLV, with the TTL incremented.  If the egress node
+   does not recognize the Egress TLV and chooses to silently drop or
+   step over the Egress TLV, egress validation will not be done, and the
+   ping/traceroute procedure will proceed as if the Egress TLV were not
+   received.
+
+3.  Egress TLV
+
+   The Egress TLV MAY be included in an MPLS echo request message.  It
+   is an optional TLV and, if present, MUST appear before the Target FEC
+   Stack TLV in the MPLS echo request packet.  This TLV can only be used
+   in LSP ping/traceroute requests that are generated by the headend
+   node of an LSP or SR Policy for which verification is performed.  In
+   cases where multiple Nil FECs are present in the Target FEC Stack
+   TLV, the Egress TLV must be added corresponding to the ultimate
+   egress of the label stack.  Explicit paths can be created using Node-
+   SID, Adj-SID, Binding SID, etc.  The Address field of the Egress TLV
+   must be derived from the path egress/destination.  The format is as
+   specified in Figure 1.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |      Type = 32771 (Egress TLV)  |          Length             |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                      Address (4 or 16 octets)                 |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                            Figure 1: Egress TLV
+
+   Type:  32771 (Section 6.1)
+
+   Length:  Variable (4 octets for IPv4 addresses and 16 octets for IPv6
+      addresses).  Length excludes the length of the Type and Length
+      fields.
+
+   Address:  This field carries a valid 4-octet IPv4 address or a valid
+      16-octet IPv6 address.  The address can be obtained from the
+      egress of the path and corresponds to the last label in the label
+      stack or the SR Policy Endpoint field [SR-POLICY-BGP].
+
+4.  Procedure
+
+   This section describes aspects of LSP ping and traceroute operations
+   that require further considerations beyond those detailed in
+   [RFC8029].
+
+4.1.  Sending Egress TLV in MPLS Echo Request
+
+   As previously mentioned, when the sender node constructs an echo
+   request with a Target FEC Stack TLV, the Egress TLV, if present, MUST
+   appear before the Target FEC Stack TLV in the MPLS echo request
+   packet.
+
+4.1.1.  Ping Mode
+
+   When the sender node constructs an echo request with a Target FEC
+   Stack TLV that contains a single Nil FEC corresponding to the last
+   segment of the SR Policy path, the sender node MUST add an Egress TLV
+   with the address obtained from the SR Policy Endpoint field
+   [SR-POLICY-BGP].  The Label value in the Nil FEC MAY be set to zero
+   when a single Nil FEC is added for multiple labels in the label
+   stack.  In case the endpoint is not specified or is equal to zero
+   (Section 8.8.1 of [RFC9256]), the sender MUST use the address
+   corresponding to the last segment of the SR Policy in the Address
+   field of the Egress TLV.  Some specific cases on how to derive the
+   Address field in the Egress TLV are listed below:
+
+   *  If the last SID in the SR Policy is an Adj-SID, the Address field
+      in the Egress TLV is derived from the node at the remote end of
+      the corresponding adjacency.
+
+   *  If the last SID in the SR Policy is a Binding SID, the Address
+      field in the Egress TLV is derived from the last node of the path
+      represented by the Binding SID.
+
+4.1.2.  Traceroute Mode
+
+   When the sender node builds an echo request with a Target FEC Stack
+   TLV that contains a Nil FEC corresponding to the last segment of the
+   segment list of the SR Policy, the sender node MUST add an Egress TLV
+   with the address obtained from the SR Policy Endpoint field
+   [SR-POLICY-BGP].
+
+   Although there is no requirement to do so, an implementation MAY send
+   multiple Nil FECs if that makes it easier for the implementation.  If
+   the SR Policy headend sends multiple Nil FECs, the last one MUST
+   correspond to the Egress TLV.  The Label value in the Nil FEC MAY be
+   set to zero for the last Nil FEC.  If the endpoint is not specified
+   or is equal to zero (Section 8.8.1 of [RFC9256]), the sender MUST use
+   the address corresponding to the last segment endpoint of the SR
+   Policy path (i.e., the ultimate egress is used as the address in the
+   Egress TLV).
+
+4.1.3.  Detailed Example
+
+                     ----R3----
+                    /  (1003)  \
+         (1001)    /            \(1005)     (1007)
+           R1----R2(1002)        R5----R6----R7(address X)
+                   \            /     (1006)
+                    \   (1004) /
+                     ----R4----
+
+             Figure 2: Egress TLV Processing in Sample Topology
+
+   Consider the SR Policy configured on router R1 to destination X,
+   configured with label stack as 1002, 1004, 1007.  Segment 1007
+   belongs to R7, which has the address X locally configured on it.
+
+   Let us look at an example of a ping echo request message.  The echo
+   request message contains a Target FEC Stack TLV with the Nil FEC sub-
+   TLV.  An Egress TLV is added before the Target FEC Stack TLV.  The
+   Address field contains X (corresponding to a locally configured
+   address on R7).  X could be an IPv4 or IPv6 address, and the Length
+   field in the Egress TLV will be either 4 or 16 octets, based on the
+   address type of address X.
+
+   Let us look at an example of an echo request message in a traceroute
+   packet.  The echo request message contains a Target FEC Stack TLV
+   with the Nil FEC sub-TLV corresponding to the complete label stack
+   (1002, 1004, 1007).  An Egress TLV is added before the Target FEC
+   Stack TLV.  The Address field contains X (corresponding to a locally
+   configured address on destination R7).  X could be an IPv4 or IPv6
+   address, and the Length field in the Egress TLV will be either 4 or
+   16 octets, based on the address type of address X.  If the
+   destination/endpoint is set to zero (as in the case of the color-only
+   SR Policy), the sender should use the endpoint of segment 1007 (the
+   last segment in the segment list) as the address for the Egress TLV.
+
+4.2.  Receiving Egress TLV in MPLS Echo Request
+
+   Any node that receives an MPLS echo request message and processes it
+   is referred to as the "receiver".  In the case of the ping procedure,
+   the actual destination/egress is the receiver.  In the case of
+   traceroute, every node is a receiver.  This document does not propose
+   any change in the processing of the Nil FEC (as defined in [RFC8029])
+   in the node that receives an MPLS echo request with a Target FEC
+   Stack TLV.  The presence of the Egress TLV does not affect the
+   validation of the Target FEC Stack sub-TLV at FEC-stack-depth if it
+   is different than Nil FEC.
+
+   Additional processing MUST be done for the Egress TLV on the receiver
+   node as follows.  Note that <RSC> refers to the Return Subcode.
+
+   1.  If the Label-stack-depth is greater than 0 and the Target FEC
+       Stack sub-TLV at FEC-stack-depth is Nil FEC, set Best-return-code
+       to 8 ("Label switched at stack-depth <RSC>") and Best-rtn-subcode
+       to Label-stack-depth to report transit switching in the MPLS echo
+       reply message.
+
+   2.  If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at
+       FEC-stack-depth is Nil FEC, then do a lookup for an exact match
+       of the Address field of the Egress TLV to any of the locally
+       configured interfaces or loopback addresses.
+
+       a.  If the Egress TLV address lookup succeeds, set Best-return-
+           code to 36 ("Replying router is an egress for the address in
+           the Egress TLV for the FEC at stack depth <RSC>")
+           (Section 6.2) in the MPLS echo reply message.
+
+       b.  If the Egress TLV address lookup fails, set the Best-return-
+           code to 10 ("Mapping for this FEC is not the given label at
+           stack-depth <RSC>").
+
+   3.  In some cases, multiple Nil FECs (one corresponding to each label
+       in the label stack), along with the Egress TLV, are sent from the
+       SR Policy headend.  When the packet reaches the egress, the
+       number of labels in the received packet (size of stack-R) becomes
+       zero, or a label with the Bottom-of-Stack bit set to 1 is
+       processed.  All Nil FEC sub-TLVs MUST be removed, and the Egress
+       TLV MUST be validated.
+
+5.  Backward Compatibility
+
+   The extensions defined in this document are backward compatible with
+   the procedures described in [RFC8029].  A router that does not
+   support the Egress TLV will ignore it and use the Nil FEC procedures
+   described in [RFC8029].
+
+   When the egress node in the path does not support the extensions
+   defined in this document, egress validation will not be done, and
+   Best-return-code will be set to 3 ("Replying router is an egress for
+   the FEC at stack-depth <RSC>") and Best-rtn-subcode to stack-depth in
+   the MPLS echo reply message.
+
+   When the transit node in the path does not support the extensions
+   defined in this document, Best-return-code will be set to 8 ("Label
+   switched at stack-depth <RSC>") and Best-rtn-subcode to Label-stack-
+   depth to report transit switching in the MPLS echo reply message.
+
+6.  IANA Considerations
+
+6.1.  New TLV
+
+   IANA has added the following entry to the "TLVs" registry within the
+   "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
+   Ping Parameters" registry group [IANA-MPLS-LSP]:
+
+                    +=======+============+===========+
+                    | Type  | TLV Name   | Reference |
+                    +=======+============+===========+
+                    | 32771 | Egress TLV | RFC 9655  |
+                    +-------+------------+-----------+
+
+                          Table 1: TLVs Registry
+
+6.2.  New Return Code
+
+   IANA has added the following entry to the "Return Codes" registry
+   within the "Multiprotocol Label Switching (MPLS) Label Switched Paths
+   (LSPs) Ping Parameters" registry group [IANA-MPLS-LSP]:
+
+         +=======+==================================+===========+
+         | Value | Meaning                          | Reference |
+         +=======+==================================+===========+
+         | 36    | Replying router is an egress for | RFC 9655  |
+         |       | the address in the Egress TLV    |           |
+         |       | for the FEC at stack depth <RSC> |           |
+         +-------+----------------------------------+-----------+
+
+                      Table 2: Return Codes Registry
+
+7.  Security Considerations
+
+   This document defines an additional TLV for MPLS LSP ping and
+   conforms to the mechanisms defined in [RFC8029].  All the security
+   considerations defined in [RFC8287] apply to this document.  This
+   document does not introduce any additional security challenges to be
+   considered.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
+              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
+              Switched (MPLS) Data-Plane Failures", RFC 8029,
+              DOI 10.17487/RFC8029, March 2017,
+              <https://www.rfc-editor.org/info/rfc8029>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8287]  Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
+              N., Kini, S., and M. Chen, "Label Switched Path (LSP)
+              Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
+              IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
+              Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
+              <https://www.rfc-editor.org/info/rfc8287>.
+
+   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
+              Decraene, B., Litkowski, S., and R. Shakir, "Segment
+              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
+              July 2018, <https://www.rfc-editor.org/info/rfc8402>.
+
+   [RFC9041]  Andersson, L., Chen, M., Pignataro, C., and T. Saad,
+              "Updating the MPLS Label Switched Paths (LSPs) Ping
+              Parameters IANA Registry", RFC 9041, DOI 10.17487/RFC9041,
+              July 2021, <https://www.rfc-editor.org/info/rfc9041>.
+
+   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
+              A., and P. Mattes, "Segment Routing Policy Architecture",
+              RFC 9256, DOI 10.17487/RFC9256, July 2022,
+              <https://www.rfc-editor.org/info/rfc9256>.
+
+8.2.  Informative References
+
+   [IANA-MPLS-LSP]
+              IANA, "Multiprotocol Label Switching (MPLS) Label Switched
+              Paths (LSPs) Ping Parameters",
+              <http://www.iana.org/assignments/mpls-lsp-ping-
+              parameters>.
+
+   [SR-POLICY-BGP]
+              Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
+              P., and D. Jain, "Advertising Segment Routing Policies in
+              BGP", Work in Progress, Internet-Draft, draft-ietf-idr-sr-
+              policy-safi-10, 7 November 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
+              policy-safi-10>.
+
+Acknowledgements
+
+   The authors would like to thank Stewart Bryant, Greg Mirsky,
+   Alexander Vainshtein, Sanga Mitra Rajgopal, and Adrian Farrel for
+   their careful review and comments.
+
+Authors' Addresses
+
+   Deepti N. Rathi (editor)
+   Nokia
+   Manyata Embassy Business Park
+   Bangalore 560045
+   Karnataka
+   India
+   Email: deepti.nirmalkumarji_rathi@nokia.com
+
+
+   Shraddha Hegde (editor)
+   Juniper Networks Inc.
+   Exora Business Park
+   Bangalore 560103
+   Karnataka
+   India
+   Email: shraddha@juniper.net
+
+
+   Kapil Arora
+   Individual Contributor
+   Email: kapil.it@gmail.com
+
+
+   Zafar Ali
+   Cisco Systems, Inc.
+   Email: zali@cisco.com
+
+
+   Nagendra Kumar Nainar
+   Cisco Systems, Inc.
+   Email: naikumar@cisco.com