doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7442.txt b/doc/rfc/rfc7442.txt
new file mode 100644
index 0000000..b1d41ea
--- /dev/null
+++ b/doc/rfc/rfc7442.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        Y. Rekhter
+Request for Comments: 7442                              Juniper Networks
+Category: Standards Track                                    R. Aggarwal
+ISSN: 2070-1721                                                   Arktan
+                                                              N. Leymann
+                                                        Deutsche Telekom
+                                                           W. Henderickx
+                                                          Alcatel-Lucent
+                                                                 Q. Zhao
+                                                                   R. Li
+                                                                  Huawei
+                                                           February 2015
+
+
+     Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM)
+  in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)
+
+Abstract
+
+   When IP multicast trees created by Protocol Independent Multicast -
+   Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass
+   through an MPLS domain, it may be desirable to map such trees to
+   Point-to-Multipoint Label Switched Paths (P2MP LSPs).  This document
+   describes how to accomplish this in the case where such P2MP LSPs are
+   established using Label Distribution Protocol (LDP) Extensions for
+   P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP).
+
+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 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7442.
+
+
+
+
+
+
+
+
+
+
+
+Rekhter, et al.              Standards Track                    [Page 1]
+
+RFC 7442               PIM-SM over P2MP mLDP LSPs          February 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 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
+   (http://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 Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Specification of Requirements ..............................4
+   2. Mechanism 1 - Non-transitive Mapping of IP Multicast
+      Shared Trees ....................................................4
+      2.1. Originating Source Active Auto-discovery Routes
+           (Mechanism 1) ..............................................4
+      2.2. Receiving Source Active Auto-discovery Routes by LSR .......5
+      2.3. Handling (S,G,RPT-bit) State ...............................5
+   3. Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees ...6
+      3.1. In-Band Signaling for IP Multicast Shared Trees ............6
+      3.2. Originating Source Active Auto-discovery Routes
+           (Mechanism 2) ..............................................7
+      3.3. Receiving Source Active Auto-discovery Routes ..............8
+      3.4. Pruning Sources Off the Shared Tree ........................8
+      3.5. More on Handling (S,G,RPT-bit) State .......................9
+   4. IANA Considerations .............................................9
+   5. Security Considerations .........................................9
+   6. References .....................................................10
+      6.1. Normative References ......................................10
+      6.2. Informative References ....................................10
+   Acknowledgements ..................................................11
+   Authors' Addresses ................................................11
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter, et al.              Standards Track                    [Page 2]
+
+RFC 7442               PIM-SM over P2MP mLDP LSPs          February 2015
+
+
+1.  Introduction
+
+   [RFC6826] describes how to map Point-to-Multipoint Label Switched
+   Paths (P2MP LSPs) created by mLDP [RFC6388] to multicast trees
+   created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in
+   Source-Specific Multicast (SSM) mode [RFC4607].  This document
+   describes how to map mLDP P2MP trees to multicast trees created by
+   PIM-SM in Any-Source Multicast (ASM) mode.  It describes two possible
+   mechanisms for doing this.
+
+   The first mechanism, described in Section 2, is OPTIONAL for
+   implementations, but the second mechanism, described in Section 3, is
+   REQUIRED for all implementations claiming conformance to this
+   specification.
+
+   Note that from a deployment point of view these two mechanisms are
+   mutually exclusive.  That is, on the same network one could deploy
+   either one of the mechanisms, but not both.
+
+   The reader of this document is expected to be familiar with PIM-SM
+   [RFC4601] and mLDP [RFC6388].
+
+   This document relies on the procedures in [RFC6826] to support source
+   trees.  For example, following these procedures a Label Switching
+   Router (LSR) may initiate an mLDP Label Map with the Transit
+   IPv4/IPv6 Source TLV for (S,G) when receiving a PIM (S,G) Join.
+
+   This document uses BGP Source Active auto-discovery routes, as
+   defined in [RFC6514].  For the sake of brevity in the rest of this
+   document, we'll refer to these routes as just "Source Active
+   auto-discovery routes".
+
+   Consider a deployment scenario where the service provider has
+   provisioned the network in such a way that the Rendezvous Point (RP)
+   for a particular ASM group G is always between the receivers and the
+   sources.  If the network is provisioned in this manner, the ingress
+   Provider Edge (PE) for (S,G) is always the same as the ingress PE for
+   the RP, and thus the Source Active auto-discovery (A-D) routes are
+   never needed.  If it is known a priori that the network is
+   provisioned in this manner, mLDP in-band signaling can be supported
+   using a different set of procedures, as specified in [RFC7438].  A
+   service provider will provision the PE routers to use either the
+   procedures in [RFC7438] or those described in this document.
+
+
+
+
+
+
+
+
+Rekhter, et al.              Standards Track                    [Page 3]
+
+RFC 7442               PIM-SM over P2MP mLDP LSPs          February 2015
+
+
+   Like [RFC6826], each IP multicast tree is mapped one-to-one to a P2MP
+   LSP in the MPLS network.  This type of service works well if the
+   number of LSPs that are created is under the control of the MPLS
+   network operator, or if the number of LSPs for a particular service
+   is known to be limited.
+
+   It is to be noted that the existing BGP Multicast VPN (MVPN)
+   procedures [RFC6514] can be used to map Internet IP multicast trees
+   to P2MP LSPs.  These procedures would accomplish this for IP
+   multicast trees created by PIM-SM in SSM mode, as well as for IP
+   multicast trees created by PIM-SM in ASM mode.  Furthermore, these
+   procedures would also support the ability to aggregate multiple IP
+   multicast trees to one P2MP LSP in the MPLS network.  The details of
+   this particular approach are out of scope for this document.
+
+   This document assumes that a given LSR may have some interfaces that
+   are IP multicast capable, while other interfaces would be MPLS
+   capable.
+
+1.1.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees
+
+   This mechanism does not transit IP multicast shared trees over the
+   MPLS network.  Therefore, when an LSR creates (*,G) state (as a
+   result of receiving PIM messages on one of its IP multicast
+   interfaces), the LSR does not propagate this state in mLDP.
+
+2.1.  Originating Source Active Auto-discovery Routes (Mechanism 1)
+
+   Whenever (as a result of receiving either PIM Register or Multicast
+   Source Discovery Protocol (MSDP) messages) an RP discovers a new
+   multicast source, the RP SHOULD originate a Source Active
+   auto-discovery route.  The route carries a single MCAST-VPN Network
+   Layer Reachability Information (NLRI) [RFC6514], constructed as
+   follows:
+
+   + The Route Distinguisher (RD) in this NLRI is set to 0.
+
+   + The Multicast Source field is set to S.  This could be either an
+     IPv4 or an IPv6 address.  The Multicast Source Length field is set
+     appropriately to reflect the address type.
+
+
+
+
+
+Rekhter, et al.              Standards Track                    [Page 4]
+
+RFC 7442               PIM-SM over P2MP mLDP LSPs          February 2015
+
+
+   + The Multicast Group field is set to G.  This could be either an
+     IPv4 or an IPv6 address.  The Multicast Group Length field is set
+     appropriately to reflect this address type.
+
+   To constrain distribution of the Source Active auto-discovery route
+   to the Autonomous System (AS) of the advertising RP, this route
+   SHOULD carry the NO_EXPORT Community ([RFC1997]).
+
+   Using the normal BGP procedures, the Source Active auto-discovery
+   route is propagated to all other LSRs within the AS.
+
+   Whenever the RP discovers that the source is no longer active, the RP
+   MUST withdraw the Source Active auto-discovery route if such a route
+   was previously advertised by the RP.
+
+2.2.  Receiving Source Active Auto-discovery Routes by LSR
+
+   Consider an LSR that has some of its interfaces capable of IP
+   multicast and some capable of MPLS multicast.
+
+   When, as a result of receiving PIM messages on one of its IP
+   multicast interfaces, an LSR creates in its Tree Information Base
+   (TIB) a new (*,G) entry with a non-empty outgoing interface list that
+   contains one or more IP multicast interfaces, the LSR MUST check to
+   see if it has any Source Active auto-discovery routes for that G.  If
+   there is such a route, S of that route is reachable via an MPLS
+   interface, and the LSR does not have (S,G) state in its TIB for (S,G)
+   carried in the route, then the LSR originates the mLDP Label Map with
+   the Transit IPv4/IPv6 Source TLV carrying (S,G), as specified in
+   [RFC6826].
+
+   When an LSR receives a new Source Active auto-discovery route, the
+   LSR MUST check to see if its TIB contains a (*,G) entry with the same
+   G as that carried in the Source Active auto-discovery route.  If such
+   an entry is found, S is reachable via an MPLS interface, and the LSR
+   does not have (S,G) state in its TIB for (S,G) carried in the route,
+   then the LSR originates an mLDP Label Map with the Transit IPv4/IPv6
+   Source TLV carrying (S,G), as specified in [RFC6826].
+
+2.3.  Handling (S,G,RPT-bit) State
+
+   The creation and deletion of (S,G,RPT-bit) PIM state ([RFC4601]) on
+   an LSR that resulted from receiving PIM messages on one of its IP
+   multicast interfaces do not result in any mLDP and/or BGP actions by
+   the LSR.
+
+
+
+
+
+
+Rekhter, et al.              Standards Track                    [Page 5]
+
+RFC 7442               PIM-SM over P2MP mLDP LSPs          February 2015
+
+
+3.  Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees
+
+   This mechanism enables transit of IP multicast shared trees over the
+   MPLS network.  Therefore, when an LSR creates (*,G) state as a result
+   of receiving PIM messages on one of its IP multicast interfaces, the
+   LSR propagates this state in mLDP, as described below.
+
+   Note that in the deployment scenarios where, for a given G, none of
+   the PEs originate an (S,G) mLDP Label Map with the Transit IPv4/IPv6
+   Source TLV, no Source Active auto-discovery routes will be used.  One
+   other scenario where no Source Active auto-discovery routes will be
+   used is described in Section 3.2 ("Originating Source Active
+   Auto-discovery Routes (Mechanism 2)").  In all of these scenarios,
+   the only part of Mechanism 2 that is used is the in-band signaling
+   for IP Multicast Shared Trees, as described in the next section.
+
+3.1.  In-Band Signaling for IP Multicast Shared Trees
+
+   To provide support for in-band mLDP signaling of IP multicast shared
+   trees, this document defines two new mLDP TLVs: the Transit IPv4
+   Shared Tree TLV and the Transit IPv6 Shared Tree TLV.
+
+   These two TLVs have exactly the same encoding/format as the IPv4/IPv6
+   Source Tree TLVs defined in [RFC6826], except that instead of the
+   Source field they have an RP field that carries the address of the
+   RP, as follows:
+
+      Transit IPv4 Shared Tree TLV:
+
+      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          | Length                        | RP            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                               | Group         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Type:  11
+
+        Length:  8
+
+        RP:  IPv4 RP address, 4 octets.
+
+        Group:  IPv4 multicast group address, 4 octets.
+
+
+
+
+
+Rekhter, et al.              Standards Track                    [Page 6]
+
+RFC 7442               PIM-SM over P2MP mLDP LSPs          February 2015
+
+
+      Transit IPv6 Shared Tree TLV:
+
+      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          | Length                        | RP            ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                                               | Group         ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Type:  12
+
+        Length:  32
+
+        RP:  IPv6 RP address, 16 octets.
+
+        Group:  IPv6 multicast group address, 16 octets.
+
+   Procedures for in-band signaling for IP multicast shared trees with
+   mLDP follow the same procedures as those for in-band signaling for
+   IP multicast source trees, as specified in [RFC6826], except that
+   while the latter signals (S,G) state using Transit IPv4/IPv6 Source
+   TLVs, the former signals (*,G) state using Transit IPv4/IPv6 Shared
+   Tree TLVs.
+
+3.2.  Originating Source Active Auto-discovery Routes (Mechanism 2)
+
+   Consider an LSR that has some of its interfaces capable of IP
+   multicast and some capable of MPLS multicast.
+
+   Whenever such an LSR creates an (S,G) state as a result of receiving
+   an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G),
+   the LSR MUST originate a Source Active auto-discovery route if all of
+   the following are true:
+
+   + S is reachable via one of the IP-multicast-capable interfaces,
+
+   + the LSR determines that G is in the PIM-SM in ASM mode range, and
+
+   + the LSR does not have a (*,G) state with one of the IP-multicast-
+     capable interfaces as an incoming interface (iif) for that state.
+
+
+
+
+
+
+
+
+Rekhter, et al.              Standards Track                    [Page 7]
+
+RFC 7442               PIM-SM over P2MP mLDP LSPs          February 2015
+
+
+   The route carries a single MCAST-VPN NLRI, constructed as follows:
+
+   + The RD in this NLRI is set to 0.
+
+   + The Multicast Source field is set to S.  The Multicast Source
+     Length field is set appropriately to reflect this address type.
+
+   + The Multicast Group field is set to G.  The Multicast Group Length
+     field is set appropriately to reflect this address type.
+
+   To constrain distribution of the Source Active auto-discovery route
+   to the AS of the advertising LSR, this route SHOULD carry the
+   NO_EXPORT Community ([RFC1997]).
+
+   Using the normal BGP procedures, the Source Active auto-discovery
+   route is propagated to all other LSRs within the AS.
+
+   Whenever the LSR receiving an mLDP Label Map with the Transit
+   IPv4/IPv6 Source TLV for (S,G) deletes the (S,G) state that was
+   previously created, the LSR that deletes the state MUST also withdraw
+   the Source Active auto-discovery route, if such a route was
+   advertised when the state was created.
+
+   Note that whenever an LSR creates an (S,G) state as a result of
+   receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for
+   (S,G) with S reachable via one of the IP-multicast-capable
+   interfaces, and the LSR already has a (*,G) state with the RP
+   reachable via one of the IP-multicast-capable interfaces as a result
+   of receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree
+   TLV for (*,G), the LSR does not originate a Source Active
+   auto-discovery route.
+
+3.3.  Receiving Source Active Auto-discovery Routes
+
+   Procedures for receiving Source Active auto-discovery routes are the
+   same as those for Mechanism 1.
+
+3.4.  Pruning Sources Off the Shared Tree
+
+   If, after receiving a new Source Active auto-discovery route for
+   (S,G), the LSR determines that (a) it has the (*,G) entry in its TIB,
+   (b) the incoming interface (iif) list for that entry contains one of
+   the IP interfaces, (c) at least one of the MPLS interfaces is in the
+   outgoing interface (oif) list for that entry, and (d) the LSR does
+   not originate an mLDP Label Mapping message for (S,G) with the
+   Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the
+   (S,G,RPT-bit) downstream state to the Prune state.  (Conceptually,
+   the PIM state machine on the LSR will act "as if" it had received
+
+
+
+Rekhter, et al.              Standards Track                    [Page 8]
+
+RFC 7442               PIM-SM over P2MP mLDP LSPs          February 2015
+
+
+   Prune(S,G,rpt) on one of its MPLS interfaces, without actually having
+   received one.)  Depending on the (S,G,RPT-bit) state on the iif, this
+   may result in the LSR using PIM procedures to prune S off the Shared
+   (*,G) tree.
+
+   The LSR MUST keep the (S,G,RPT-bit) downstream state machine in the
+   Prune state for as long as (a) the outgoing interface (oif) list for
+   (*,G) contains one of the MPLS interfaces, (b) the LSR has at least
+   one Source Active auto-discovery route for (S,G), and (c) the LSR
+   does not originate the mLDP Label Mapping message for (S,G) with the
+   Transit IPv4/IPv6 Source TLV.  Once one or more of these conditions
+   become no longer valid, the LSR MUST transition the (S,G,RPT-bit)
+   downstream state machine to the NoInfo state.
+
+   Note that except for the scenario described in the first paragraph of
+   this section, it is sufficient to rely solely on the PIM procedures
+   on the LSR to ensure the correct behavior when pruning sources off
+   the shared tree.
+
+3.5.  More on Handling (S,G,RPT-bit) State
+
+   The creation and deletion of (S,G,RPT-bit) state on an LSR that
+   resulted from receiving PIM messages on one of its IP multicast
+   interfaces do not result in any mLDP and/or BGP actions by the LSR.
+
+4.  IANA Considerations
+
+   IANA maintains a registry called "Label Distribution Protocol (LDP)
+   Parameters" with a subregistry called "LDP MP Opaque Value Element
+   basic type".  IANA has allocated two new values, as follows:
+
+      Value | Name                         | Reference
+      ------+------------------------------+------------
+        11  | Transit IPv4 Shared Tree TLV | [RFC7442]
+        12  | Transit IPv6 Shared Tree TLV | [RFC7442]
+
+5.  Security Considerations
+
+   All of the security considerations for mLDP ([RFC6388]) apply here.
+
+   From the security considerations point of view, the use of Shared
+   Tree TLVs is no different than the use of Source TLVs [RFC6826].
+
+
+
+
+
+
+
+
+
+Rekhter, et al.              Standards Track                    [Page 9]
+
+RFC 7442               PIM-SM over P2MP mLDP LSPs          February 2015
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities
+              Attribute", RFC 1997, August 1996,
+              <http://www.rfc-editor.org/info/rfc1997>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+              Protocol Specification (Revised)", RFC 4601, August 2006,
+              <http://www.rfc-editor.org/info/rfc4601>.
+
+   [RFC6388]  Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
+              Thomas, "Label Distribution Protocol Extensions for Point-
+              to-Multipoint and Multipoint-to-Multipoint Label Switched
+              Paths", RFC 6388, November 2011,
+              <http://www.rfc-editor.org/info/rfc6388>.
+
+   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
+              Encodings and Procedures for Multicast in MPLS/BGP IP
+              VPNs", RFC 6514, February 2012,
+              <http://www.rfc-editor.org/info/rfc6514>.
+
+   [RFC6826]  Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M.
+              Napierala, "Multipoint LDP In-Band Signaling for Point-to-
+              Multipoint and Multipoint-to-Multipoint Label Switched
+              Paths", RFC 6826, January 2013,
+              <http://www.rfc-editor.org/info/rfc6826>.
+
+6.2.  Informative References
+
+   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
+              IP", RFC 4607, August 2006, <http://www.rfc-editor.org/
+              info/rfc4607>.
+
+   [RFC7438]  Wijnands, IJ., Ed., Rosen, E., Gulko, A., Joorde, U., and
+              J.  Tantsura, "Multipoint LDP (mLDP) In-Band Signaling
+              with Wildcards", RFC 7438, January 2015,
+              <http://www.rfc-editor.org/info/rfc7438>.
+
+
+
+
+
+
+
+Rekhter, et al.              Standards Track                   [Page 10]
+
+RFC 7442               PIM-SM over P2MP mLDP LSPs          February 2015
+
+
+Acknowledgements
+
+   The use of Source Active auto-discovery routes was borrowed from
+   [RFC6514].  Some text in this document was borrowed from [RFC6514].
+
+   Some of the text in this document was borrowed from [RFC6826].
+
+   We would like to acknowledge Arkadiy Gulko for his review and
+   comments.
+
+   We would also like to thank Xuxiaohu, Gregory Mirsky, Rajiv Asati,
+   and Adrian Farrel for their review and comments.
+
+Authors' Addresses
+
+   Yakov Rekhter
+   Juniper Networks, Inc.
+   EMail: yakov@juniper.net
+
+
+   Rahul Aggarwal
+   Arktan
+   EMail: raggarwa_1@yahoo.com
+
+
+   Nicolai Leymann
+   Deutsche Telekom
+   Winterfeldtstrasse 21
+   Berlin  10781
+   Germany
+   EMail: N.Leymann@telekom.de
+
+
+   Wim Henderickx
+   Alcatel-Lucent
+   EMail: wim.henderickx@alcatel-lucent.com
+
+
+   Quintin Zhao
+   Huawei
+   EMail: quintin.zhao@huawei.com
+
+
+   Richard Li
+   Huawei
+   EMail: renwei.li@huawei.com
+
+
+
+
+
+Rekhter, et al.              Standards Track                   [Page 11]
+