tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7117

 
 
 

Multicast in Virtual Private LAN Service (VPLS)

Part 3 of 3, p. 38 to 50
Prev RFC Part

 


prevText      Top      Up      ToC       Page 38 
9.  BGP Extensions

   This section describes the encoding of the BGP extensions required by
   this document.

9.1.  Inclusive Tree/Selective Tree Identifier

   Inclusive P-multicast tree and Selective P-multicast tree
   advertisements carry the P-multicast tree identifier.  For the
   purpose of carrying this identifier, this document reuses the BGP
   attribute, called "PMSI_TUNNEL" that is defined in [RFC6514].

   This document supports only the following Tunnel Types when the PMSI
   Tunnel attribute is carried in VPLS A-D or VPLS S-PMSI A-D routes:

     + 0 - No tunnel information present
     + 1 - RSVP-TE P2MP LSP
     + 2 - LDP P2MP LSP
     + 6 - Ingress Replication

Top      Up      ToC       Page 39 
9.2.  MCAST-VPLS NLRI

   This document defines a new BGP NLRI, called the "MCAST-VPLS NLRI".

   Following is the format of the MCAST-VPLS NLRI:

                +-----------------------------------+
                |    Route Type (1 octet)           |
                +-----------------------------------+
                |     Length (1 octet)              |
                +-----------------------------------+
                |    Route Type specific (variable) |
                +-----------------------------------+

   The Route Type field defines encoding of the Route Type specific
   field of MCAST-VPLS NLRI.

   The Length field indicates the length in octets of the Route Type
   specific field of MCAST-VPLS NLRI.

   This document defines the following route types for A-D routes:

     + 3 - Selective Tree A-D route;
     + 4 - Leaf A-D route.

   The MCAST-VPLS NLRI is carried in BGP using BGP Multiprotocol
   Extensions [RFC4760] with an Address Family Identifier (AFI) of 25
   (L2VPN AFI), and a Subsequent Address Family Identifier (SAFI) of
   MCAST-VPLS.  The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI
   attribute contains the MCAST-VPLS NLRI (encoded as specified above).

   In order for two BGP speakers to exchange labeled MCAST-VPLS NLRI,
   they must use BGP Capabilities Advertisement to ensure that they both
   are capable of properly processing such NLRI.  This is done as
   specified in [RFC4760], by using capability code 1 (multiprotocol
   BGP) with an AFI of 25 and a SAFI of MCAST-VPLS.

   The following describes the format of the Route Type specific field
   of MCAST-VPLS NLRI for various route types defined in this document.

Top      Up      ToC       Page 40 
9.2.1.  S-PMSI A-D Route

   The Route Type specific field of MCAST-VPLS NLRI of an S-PMSI A-D
   route consists of the following:

                +-----------------------------------+
                |      RD   (8 octets)              |
                +-----------------------------------+
                | Multicast Source Length (1 octet) |
                +-----------------------------------+
                |  Multicast Source (Variable)      |
                +-----------------------------------+
                |  Multicast Group Length (1 octet) |
                +-----------------------------------+
                |  Multicast Group   (Variable)     |
                +-----------------------------------+
                |   Originating Router's IP Addr    |
                +-----------------------------------+

   The RD is encoded as described in [RFC4364].

   The Multicast Source field contains the C-S address, i.e., the
   address of the multicast source.  If the Multicast Source field
   contains an IPv4 address, then the value of the Multicast Source
   Length field is 32.  If the Multicast Source field contains an IPv6
   address, then the value of the Multicast Source Length field is 128.
   The value of the Multicast Source Length field may be set to 0 to
   indicate a wildcard.

   The Multicast Group field contains the C-G address, i.e., the address
   of the multicast group.  If the Multicast Group field contains an
   IPv4 address, then the value of the Multicast Group Length field is
   32.  If the Multicast Group field contains an IPv6 address, then the
   value of the Multicast Group Length field is 128.  The Multicast
   Group Length field may be set to 0 to indicate a wildcard.

   Whether the Originating Router's IP Address field carries an IPv4 or
   IPv6 address is determined by the value of the Length field of the
   MCAST-VPLS NLRI.  If the Multicast Source field contains an IPv4
   address and the Multicast Group field contains an IPv4 address, then
   the value of the Length field is 22 bytes if the Originating Router's
   IP Address carries an IPv4 address and 34 bytes if it is an IPv6
   address.  If the Multicast Source and Multicast Group fields contain
   IPv6 addresses, then the value of the Length field is 46 bytes if the
   Originating Router's IP Address carries an IPv4 address and 58 bytes
   if it is an IPv6 address.  The following table summarizes the above.

Top      Up      ToC       Page 41 
      Multicast   Multicast                Originating Router's   Length
      Source      Group                       IP Address

        IPv4      IPv4                        IPv4                  22
        IPv4      IPv4                        IPv6                  34
        IPv6      IPv6                        IPv4                  46
        IPv6      IPv6                        IPv6                  58

   Usage of Selective Tree A-D routes is described in the "Optimizing
   Multicast Distribution via Selective Trees" section.

9.2.2.  Leaf A-D Route

   The Route Type specific field of MCAST-VPLS NLRI of a leaf A-D route
   consists of the following:

                +-----------------------------------+
                |      Route Key (variable)         |
                +-----------------------------------+
                |   Originating Router's IP Addr    |
                +-----------------------------------+

   Whether the Originating Router's IP Address field carries an IPv4 or
   IPv6 address is determined by the Length field of the MCAST-VPLS NLRI
   and the length of the Route Key field.  From these two length fields,
   one can compute the length of the Originating Router's IP Address.
   If this computed length is 4, then the address is an IPv4 address; if
   its 16, then the address is an IPv6 address.

   Usage of leaf A-D routes is described in the "Inter-AS Inclusive
   P-Multicast Tree A-D/Binding" and "Optimizing Multicast Distribution
   via Selective Trees" sections.

10.  Aggregation Considerations

   This document does not specify the mandatory implementation of any
   particular set of rules for determining whether or not the Inclusive
   or Selective trees of two particular VPLS instances are to be
   instantiated by the same Aggregate Inclusive/Selective tree.  This
   determination can be made by implementation-specific heuristics, by
   configuration, or even perhaps by the use of offline tools.

   This section discusses potential methodologies with respect to
   aggregation.

Top      Up      ToC       Page 42 
   In general, the heuristic used to decide which VPLS instances or
   <C-S, C-G> entries to aggregate is implementation dependent.  It is
   also conceivable that offline tools can be used for this purpose.
   This section discusses some trade-offs with respect to aggregation.

   The "congruency" of aggregation is defined by the amount of overlap
   in the leaves of the client trees that are aggregated on an SP tree.
   For Aggregate Inclusive trees, the congruency depends on the overlap
   in the membership of the VPLS instances that are aggregated on the
   Aggregate Inclusive tree.  If there is complete overlap, aggregation
   is perfectly congruent.  As the overlap between the VPLS instances
   that are aggregated reduces, the congruency reduces.

   From the above definition of "congruency", it follows that in order
   for a given PE to determine the congruency of the client trees that
   this PE could aggregate, the PE has to know the leaves of these
   client trees.  This is irrespective of whether the aggregated SP tree
   is established using mLDP or RSVP-TE.

   If aggregation is done such that it is not perfectly congruent, a PE
   may receive traffic for VPLS instances to which it doesn't belong.
   As the amount of multicast traffic in these unwanted VPLS instances
   increases, aggregation becomes less optimal with respect to delivered
   traffic.  Hence, there is a trade-off between reducing multicast
   state in the core and delivering unwanted traffic.

   An implementation should provide knobs to control aggregation based
   on the congruency of the tree to be aggregated.  This will allow an
   SP to deploy aggregation depending on the VPLS membership and traffic
   profiles in its network.  If different PEs are setting up Aggregate
   Inclusive trees, this will also allow an SP to engineer the maximum
   amount of unwanted VPLS instances for which a particular PE may
   receive traffic.

   The state/bandwidth optimality trade-off can be further improved by
   having a versatile many-to-many association between client trees and
   provider trees.  Thus, a VPLS instance can be mapped to multiple
   Aggregate trees.  The mechanisms for achieving this are for further
   study.  Also, it may be possible to use both ingress replication and
   an Aggregate tree for a particular VPLS.  Mechanisms for achieving
   this are also for further study.

Top      Up      ToC       Page 43 
11.  Data Forwarding

11.1.  MPLS Tree Encapsulation

11.1.1.  Mapping Multiple VPLS Instances to a P2MP LSP

   The following diagram shows the progression of the VPLS multicast
   packet as it enters and leaves the SP network when MPLS trees are
   being used for multiple VPLS instances.  RSVP-TE P2MP LSPs are
   examples of such trees.

      Packets received        Packets in transit      Packets forwarded
      at ingress PE           in the service          by egress PEs
                              provider network

                              +---------------+
                              |MPLS Tree Label|
                              +---------------+
                              | VPLS Label    |
      ++=============++       ++=============++       ++=============++
      ||C-Ether Hdr  ||       || C-Ether Hdr ||       || C-Ether Hdr ||
      ++=============++ >>>>> ++=============++ >>>>> ++=============++
      || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
      ++=============++ >>>>> ++=============++ >>>>> ++=============++
      || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
      ++=============++       ++=============++       ++=============++

   When an ingress PE receives a packet, the ingress PE using the
   procedures defined in [RFC4761] and [RFC4762] determines the VPLS
   instance associated with the packet.  If the packet is an IP
   multicast packet, and the ingress PE uses an Aggregate Selective tree
   for the (C-S, C-G) carried in the packet, then the ingress PE pushes
   the VPLS Label associated with the VPLS instance on the ingress PE
   and the MPLS Tree Label associated with the Aggregate Selective tree,
   and it sends the packet over the P2MP LSP associated with the
   Aggregate Selective tree.  Otherwise, if the ingress PE does not use
   an Aggregate Selective tree for the (C-S, C-G), or the packet is
   either non-IP multicast or broadcast, the ingress PE pushes the VPLS
   label associated with the VPLS instance on the ingress PE and the
   MPLS Tree Label associated with the Aggregate Inclusive tree, and it
   sends the packet over the P2MP LSP associated with the Aggregate
   Inclusive tree.

   The egress PE does a lookup on the outer MPLS tree label, and
   determines the MPLS forwarding table in which to look up the inner
   MPLS label (VPLS label).  This table is specific to the tree label
   space (as identified by the MPLS Tree Label).  The inner label (VPLS
   label) is unique within the context of the root of the tree (as it is

Top      Up      ToC       Page 44 
   assigned by the root of the tree, without any coordination with any
   other nodes).  Thus, it is not unique across multiple roots.  So, to
   unambiguously identify a particular VPLS, one has to know the VPLS
   label, and the context within which that label is unique.  The
   context is provided by the outer MPLS label (MPLS Tree Label)
   [RFC5331].

   The outer MPLS label is popped.  The lookup of the resulting MPLS
   label determines the VSI in which the egress PE needs to do the
   C-multicast data packet lookup.  It then pops the inner MPLS label
   and sends the packet to the VSI for multicast data forwarding.

11.1.2.  Mapping One VPLS Instance to a P2MP LSP

   The following diagram shows the progression of the VPLS multicast
   packet as it enters and leaves the SP network when a given MPLS tree
   is being used for a single VPLS instance.  RSVP-TE P2MP LSPs are
   examples of such trees.

      Packets received        Packets in transit      Packets forwarded
      at ingress PE           in the service          by egress PEs
                              provider network

                              +---------------+
                              |MPLS Tree Label|
      ++=============++       ++=============++       ++=============++
      ||C-Ether Hdr  ||       || C-Ether Hdr ||       || C-Ether Hdr ||
      ++=============++ >>>>> ++=============++ >>>>> ++=============++
      || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
      ++=============++ >>>>> ++=============++ >>>>> ++=============++
      || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
      ++=============++       ++=============++       ++=============++

   When an ingress PE receives a packet, the ingress PE using the
   procedures defined in [RFC4761] and [RFC4762] determines the VPLS
   instance associated with the packet.  If the packet is an IP
   multicast packet, and the ingress PE uses a Selective tree for the
   (C-S, C-G) carried in the packet, then the ingress PE pushes the MPLS
   Tree Label associated with the Selective tree, and it sends the
   packet over the P2MP LSP associated with the Selective tree.
   Otherwise, if the ingress PE does not use a Selective tree for the
   (C-S, C-G), or the packet is either non-IP multicast or broadcast,
   the ingress PE pushes the MPLS Tree Label associated with the
   Inclusive tree, and it sends the packet over the P2MP LSP associated
   with the Inclusive tree.

Top      Up      ToC       Page 45 
   The egress PE does a lookup on the MPLS tree label and determines the
   VSI in which the receiver PE needs to do the C-multicast data packet
   lookup.  It then pops the MPLS label and sends the packet to the VSI
   for multicast data forwarding.

12.  VPLS Data Packet Treatment

   If the destination MAC address of a VPLS packet received by an
   ingress PE from a VPLS site is a multicast address, a P-multicast
   tree SHOULD be used to transport the packet, if possible.  If the
   packet is an IP multicast packet and a Selective tree exists for that
   multicast stream, the Selective tree MUST be used.  Else, if a
   (C-*, C-*) Selective tree exists for the VPLS it SHOULD be used.
   Else, if an Inclusive tree exists for the VPLS, it SHOULD be used.

   If the destination MAC address of a VPLS packet is a broadcast
   address, it is flooded.  If a (C-*, C-*) Selective tree exists for
   the VPLS, the PE SHOULD flood over it.  Else, if an Inclusive tree
   exists for the VPLS, the PE SHOULD flood over it.  Else, the PE MUST
   flood the packet using the procedures in [RFC4761] or [RFC4762].

   If the destination MAC address of a packet is a unicast address and
   it has not been learned, the packet MUST be sent to all PEs in the
   VPLS.  Inclusive P-multicast trees or a Selective P-multicast tree
   bound to (C-*, C-*) SHOULD be used for sending unknown unicast MAC
   packets to all PEs.  When this is the case, the receiving PEs MUST
   support the ability to perform MAC address learning for packets
   received on a multicast tree.  In order to perform such learning, the
   receiver PE MUST be able to determine the sender PE when a VPLS
   packet is received on a P-multicast tree.  This further implies that
   the MPLS P-multicast tree technology MUST allow the egress PE to
   determine the sender PE from the received MPLS packet.

   When a receiver PE receives a VPLS packet with a source MAC address,
   which has not yet been learned, on a P-multicast tree, the receiver
   PE determines the PW to the sender PE.  The receiver PE then creates
   forwarding state in the VPLS instance with a destination MAC address
   being the same as the source MAC address being learned, and the PW
   being the PW to the sender PE.

   It should be noted that when a sender PE that is sending packets
   destined to an unknown unicast MAC address over a P-multicast tree
   learns the PW to use for forwarding packets destined to this unicast
   MAC address, it might immediately switch to transport such packets
   over this particular PW.  Since the packets were initially being
   forwarded using a P-multicast tree, this could lead to packet

Top      Up      ToC       Page 46 
   reordering.  This constraint should be taken into consideration if
   unknown unicast frames are forwarded using a P-multicast tree,
   instead of multiple PWs based on [RFC4761] or [RFC4762].

   An implementation SHOULD support the ability to transport unknown
   unicast traffic over Inclusive P-multicast trees.  Furthermore, an
   implementation MUST support the ability to perform MAC address
   learning for packets received on a P-multicast tree.

13.  Security Considerations

   Security considerations discussed in [RFC4761] and [RFC4762] apply to
   this document.  This section describes additional considerations.

   As mentioned in [RFC4761], there are two aspects to achieving data
   privacy and protecting against denial-of-service attacks in a VPLS:
   securing the control plane and protecting the forwarding path.
   Compromise of the control plane could result in a PE sending
   multicast data belonging to some VPLS to another VPLS, or black-
   holing VPLS multicast data, or even sending it to an eavesdropper;
   none of which are acceptable from a data privacy point of view.  In
   addition, compromise of the control plane could result in black-
   holing VPLS multicast data and could provide opportunities for
   unauthorized VPLS multicast usage (e.g., exploiting traffic
   replication within a multicast tree to amplify a denial-of-service
   attack based on sending large amounts of traffic).

   The mechanisms in this document use BGP for the control plane.
   Hence, techniques such as in [RFC5925] help authenticate BGP
   messages, making it harder to spoof updates (which can be used to
   divert VPLS traffic to the wrong VPLS) or withdrawals (denial-of-
   service attacks).  In the multi-AS methods (b) and (c) described in
   the "Inter-AS Inclusive P-Multicast Tree A-D/Binding" section, this
   also means protecting the inter-AS BGP sessions, between the ASBRs,
   the PEs, or the Route Reflectors.

   Note that [RFC5925] will not help in keeping MPLS labels, associated
   with P2MP LSPs or the upstream MPLS labels used for aggregation,
   private -- knowing the labels, one can eavesdrop on VPLS traffic.
   However, this requires access to the data path within an SP network,
   which is assumed to be composed of trusted nodes/links.

   One of the requirements for protecting the data plane is that the
   MPLS labels be accepted only from valid interfaces.  This applies
   both to MPLS labels associated with P2MP LSPs and to the upstream-
   assigned MPLS labels.  For a PE, valid interfaces comprise links from
   other routers in the PE's own AS.  For an ASBR, valid interfaces
   comprise links from other routers in the ASBR's own AS, and links

Top      Up      ToC       Page 47 
   from other ASBRs in ASes that have instances of a given VPLS.  It is
   especially important in the case of multi-AS VPLS instances that one
   accept VPLS packets only from valid interfaces.

14.  IANA Considerations

   This document defines a new NLRI, called "MCAST-VPLS", to be carried
   in BGP using multiprotocol extensions.  IANA has assigned it a SAFI
   value of 8.

   This document defines a BGP-optional transitive attribute called
   "PMSI_TUNNEL".  This is the same attribute as the one defined in
   [RFC6514] and the code point for this attribute has already been
   assigned by IANA as 22 [BGP-IANA].  Hence, no further action is
   required from IANA regarding this attribute.

15.  References

15.1.  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
               Tunnels", RFC 3209, December 2001.

   [RFC4760]   Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
               "Multiprotocol Extensions for BGP-4", RFC 4760, January
               2007.

   [RFC4761]   Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
               LAN Service (VPLS) Using BGP for Auto-Discovery and
               Signaling", RFC 4761, January 2007.

   [RFC4762]   Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
               LAN Service (VPLS) Using Label Distribution Protocol
               (LDP) Signaling", RFC 4762, January 2007.

   [RFC5036]   Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
               "LDP Specification", RFC 5036, October 2007.

   [RFC5331]   Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
               Label Assignment and Context-Specific Label Space", RFC
               5331, August 2008.

Top      Up      ToC       Page 48 
   [RFC6511]   Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate
               Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE
               Label Switched Paths", RFC 6511, February 2012.

   [RFC6512]   Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann,
               "Using Multipoint LDP When the Backbone Has No Route to
               the Root", RFC 6512, February 2012.

15.2.  Informative References

   [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.

   [RFC6513]   Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
               MPLS/BGP IP VPNs", RFC 6513, February 2012.

   [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.

   [RFC6074]   Rosen, E., Davie, B., Radoaca, V., and W. Luo,
               "Provisioning, Auto-Discovery, and Signaling in Layer 2
               Virtual Private Networks (L2VPNs)", RFC 6074, January
               2011.

   [RFC5925]   Touch, J., Mankin, A., and R. Bonica, "The TCP
               Authentication Option", RFC 5925, June 2010.

   [RFC5501]   Kamite, Y., Ed., Wada, Y., Serbest, Y., Morin, T., and L.
               Fang, "Requirements for Multicast Support in Virtual
               Private LAN Services", RFC 5501, March 2009.

   [RFC5332]   Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
               "MPLS Multicast Encapsulations", RFC 5332, August 2008.

   [RFC4684]   Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
               R., Patel, K., and J. Guichard, "Constrained Route
               Distribution for Border Gateway Protocol/MultiProtocol
               Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
               Private Networks (VPNs)", RFC 4684, November 2006.

   [RFC4875]   Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
               Yasukawa, Ed., "Extensions to Resource Reservation
               Protocol - Traffic Engineering (RSVP-TE) for Point-to-
               Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
               2007.

Top      Up      ToC       Page 49 
   [RFC4601]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
               "Protocol Independent Multicast - Sparse Mode (PIM-SM):
               Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4541]   Christensen, M., Kimball, K., and F. Solensky,
               "Considerations for Internet Group Management Protocol
               (IGMP) and Multicast Listener Discovery (MLD) Snooping
               Switches", RFC 4541, May 2006.

   [RFC4447]   Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
               G. Heron, "Pseudowire Setup and Maintenance Using the
               Label Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC4364]   Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
               Networks (VPNs)", RFC 4364, February 2006.

   [RFC3810]   Vida, R., Ed., and L. Costa, Ed., "Multicast Listener
               Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June
               2004.

   [RFC3376]   Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
               Thyagarajan, "Internet Group Management Protocol, Version
               3", RFC 3376, October 2002.

   [RFC2710]   Deering, S., Fenner, W., and B. Haberman, "Multicast
               Listener Discovery (MLD) for IPv6", RFC 2710, October
               1999.

   [RFC2236]   Fenner, W., "Internet Group Management Protocol, Version
               2", RFC 2236, November 1997.

   [RFC1997]   Chandra, R., Traina, P., and T. Li, "BGP Communities
               Attribute", RFC 1997, August 1996.

   [MULTI-HOMING]
               Kothari, B., Kompella, K., Henderickx, W., Balus, F.,
               Uttaro, J., Palislamovic, S., and W. Lin, "BGP based
               Multi-homing in Virtual Private LAN Service", Work in
               Progress, July 2013.

   [BGP-IANA]  IANA, "Border Gateway Protocol (BGP) Parameters",
               <http://www.iana.org/assignments/bgp-parameters>.

Top      Up      ToC       Page 50 
16.  Acknowledgments

   Many thanks to Thomas Morin for his support of this work.

   We would also like to thank authors of [RFC6514] and [RFC6513], as
   the details of the inter-AS segmented tree procedures in this
   document, as well as some text that describes these procedures have
   benefited from those in [RFC6514] and [RFC6513].  The same applies to
   the notion of Inclusive and Selective trees, as well as the
   procedures for switching from Inclusive to Selective trees.

   We would also like to thank Nabil Bitar, Stewart Bryant, Wim
   Henderickx, and Eric Rosen for their review and comments.

Authors' Addresses

   Rahul Aggarwal
   998 Lucky Avenue
   Menlo Park, CA 94025
   USA
   Phone: +1-415-806-5527
   EMail: raggarwa_1@yahoo.com

   Yuji Kamite
   NTT Communications Corporation
   Granpark Tower
   3-4-1 Shibaura, Minato-ku
   Tokyo  108-8118
   Japan
   EMail: y.kamite@ntt.com

   Luyuan Fang
   Microsoft
   EMail: lufang@microsoft.com

   Yakov Rekhter
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   USA
   EMail: yakov@juniper.net

   Chaitanya Kodeboniya
   EMail: chaitk@yahoo.com