draft-ietf-bess-mvpn-extranet-00.txt   draft-ietf-bess-mvpn-extranet-01.txt 
BESS Working Group Y. Rekhter, Ed. BESS Working Group Y. Rekhter, Ed.
Internet-Draft E. Rosen, Ed. Internet-Draft E. Rosen, Ed.
Updates: 6513,6514,6625 (if approved) Juniper Networks, Inc. Updates: 6513,6514,6625 (if approved) Juniper Networks, Inc.
Intended status: Standards Track R. Aggarwal Intended status: Standards Track R. Aggarwal
Expires: May 24, 2015 Arktan Expires: October 22, 2015 Arktan
Y. Cai Y. Cai
Microsoft Microsoft
W. Henderickx W. Henderickx
Alcatel-Lucent Alcatel-Lucent
T. Morin T. Morin
France Telecom - Orange Orange
P. Muley P. Muley
Alcatel-Lucent Alcatel-Lucent
R. Qiu R. Qiu
Juniper Networks, Inc. Juniper Networks, Inc.
IJ. Wijnands IJ. Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
November 20, 2014 April 20, 2015
Extranet Multicast in BGP/IP MPLS VPNs Extranet Multicast in BGP/IP MPLS VPNs
draft-ietf-bess-mvpn-extranet-00 draft-ietf-bess-mvpn-extranet-01
Abstract Abstract
Previous RFCs specify the procedures necessary to allow IP multicast Previous RFCs specify the procedures necessary to allow IP multicast
traffic to travel from one site to another within a BGP/MPLS IP VPN traffic to travel from one site to another within a BGP/MPLS IP VPN
(Virtual Private Network). However, it is sometimes desirable to (Virtual Private Network). However, it is sometimes desirable to
allow multicast traffic whose source is in one VPN to be received by allow multicast traffic whose source is in one VPN to be received by
systems that are in another VPN. This is known as a "Multicast VPN systems that are in another VPN. This is known as a "Multicast VPN
(MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by
specifying the procedures that are necessary in order to provide MVPN specifying the procedures that are necessary in order to provide MVPN
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 24, 2015. This Internet-Draft will expire on October 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 21 skipping to change at page 3, line 21
4.4.1. The Extranet Source Extended 4.4.1. The Extranet Source Extended
Community . . . . . . . . . . . . . . . . . . . . . . 25 Community . . . . . . . . . . . . . . . . . . . . . . 25
4.4.2. Distribution of Extranet Source Extended 4.4.2. Distribution of Extranet Source Extended
Community . . . . . . . . . . . . . . . . . . . . . . 27 Community . . . . . . . . . . . . . . . . . . . . . . 27
4.5. The 'Extranet Separation' Extended Community . . . . . . 27 4.5. The 'Extranet Separation' Extended Community . . . . . . 27
5. Origination and Distribution of BGP A-D Routes . . . . . . . 28 5. Origination and Distribution of BGP A-D Routes . . . . . . . 28
5.1. Route Targets of UMH-eligible Routes and A-D 5.1. Route Targets of UMH-eligible Routes and A-D
Routes . . . . . . . . . . . . . . . . . . . . . . . . . 28 Routes . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Considerations for Particular Inclusive Tunnel 5.2. Considerations for Particular Inclusive Tunnel
Types . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Types . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.1. RSVP-TE P2MP . . . . . . . . . . . . . . . . . . . . 30 5.2.1. RSVP-TE P2MP or Ingress
Replication . . . . . . . . . . . . . . . . . . . . . 30
5.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 31 5.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 31
6. When PIM is the PE-PE C-multicast Control Plane . . . . . . . 32 6. When PIM is the PE-PE C-multicast Control Plane . . . . . . . 32
6.1. Provisioning VRFs with RTs . . . . . . . . . . . . . . . 33 6.1. Provisioning VRFs with RTs . . . . . . . . . . . . . . . 33
6.1.1. Incoming and Outgoing Extranet RTs . . . . . . . . . 33 6.1.1. Incoming and Outgoing Extranet RTs . . . . . . . . . 33
6.1.2. UMH-eligible Routes and RTs . . . . . . . . . . . . . 34 6.1.2. UMH-eligible Routes and RTs . . . . . . . . . . . . . 34
6.1.3. PIM C-Instance Reverse Path Forwarding 6.1.3. PIM C-Instance Reverse Path Forwarding
Determination . . . . . . . . . . . . . . . . . . . . 34 Determination . . . . . . . . . . . . . . . . . . . . 34
6.2. Single PMSI per C-flow Model . . . . . . . . . . . . . . 34 6.2. Single PMSI per C-flow Model . . . . . . . . . . . . . . 35
6.2.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 35 6.2.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 35
6.2.2. S-PMSIs . . . . . . . . . . . . . . . . . . . . . . . 38 6.2.2. S-PMSIs . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.3. Sending PIM Control Packets . . . . . . . . . . . . . 39 6.2.3. Sending PIM Control Packets . . . . . . . . . . . . . 39
6.2.4. Receiving PIM Control Packets . . . . . . . . . . . . 39 6.2.4. Receiving PIM Control Packets . . . . . . . . . . . . 39
6.2.5. Sending and Receiving Data Packets . . . . . . . . . 39 6.2.5. Sending and Receiving Data Packets . . . . . . . . . 40
6.3. Multiple PMSIs per C-flow Model . . . . . . . . . . . . . 40 6.3. Multiple PMSIs per C-flow Model . . . . . . . . . . . . . 40
6.3.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 40 6.3.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 41
7. When BGP is the PE-PE C-multicast Control Plane . . . . . . . 42 7. When BGP is the PE-PE C-multicast Control Plane . . . . . . . 42
7.1. Originating C-multicast Routes . . . . . . . . . . . . . 42 7.1. Originating C-multicast Routes . . . . . . . . . . . . . 43
7.2. Originating A-D Routes Without Extranet 7.2. Originating A-D Routes Without Extranet
Separation . . . . . . . . . . . . . . . . . . . . . . . 43 Separation . . . . . . . . . . . . . . . . . . . . . . . 43
7.2.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 43 7.2.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 43
7.2.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 44 7.2.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 44
7.2.3. Source Active A-D Routes . . . . . . . . . . . . . . 44 7.2.3. Source Active A-D Routes . . . . . . . . . . . . . . 45
7.2.3.1. When Inter-Site Shared Trees Are Used . . . . . . 44 7.2.3.1. When Inter-Site Shared Trees Are Used . . . . . . 45
7.2.3.2. When Inter-Site Shared Trees Are Not Used . . . . 45 7.2.3.2. When Inter-Site Shared Trees Are Not Used . . . . 45
7.3. Originating A-D Routes With Extranet Separation . . . . . 45 7.3. Originating A-D Routes With Extranet Separation . . . . . 46
7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 45 7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 46
7.3.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 46 7.3.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 47
7.3.3. Source Active A-D Routes . . . . . . . . . . . . . . 48 7.3.3. Source Active A-D Routes . . . . . . . . . . . . . . 48
7.4. Determining the Expected P-tunnel for a C-flow . . . . . 48 7.4. Determining the Expected P-tunnel for a C-flow . . . . . 48
7.4.1. (C-S,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 50 7.4.1. (C-S,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 50
7.4.2. (C-S,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 50 7.4.2. (C-S,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 51
7.4.3. (C-*,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 50 7.4.3. (C-*,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 51
7.4.4. (C-*,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 52 7.4.4. (C-*,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 52
7.4.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 52 7.4.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 52
7.5. Packets Arriving from the Wrong P-tunnel . . . . . . . . 53 7.5. Packets Arriving from the Wrong P-tunnel . . . . . . . . 53
8. Multiple Extranet VRFs on the same 8. Multiple Extranet VRFs on the same
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
10. Security Considerations . . . . . . . . . . . . . . . . . . . 54 10. Security Considerations . . . . . . . . . . . . . . . . . . . 55
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.1. Normative References . . . . . . . . . . . . . . . . . . 56 12.1. Normative References . . . . . . . . . . . . . . . . . . 56
12.2. Informative References . . . . . . . . . . . . . . . . . 56 12.2. Informative References . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
Previous RFCs ([RFC6513], [RFC6514]) specify the procedures necessary Previous RFCs ([RFC6513], [RFC6514]) specify the procedures necessary
to allow IP multicast traffic to travel from one site to another to allow IP multicast traffic to travel from one site to another
within a BGP/MPLS IP VPN (Virtual Private Network). However, it is within a BGP/MPLS IP VPN (Virtual Private Network). However, it is
sometimes desirable to allow multicast traffic whose source is in one sometimes desirable to allow multicast traffic whose source is in one
VPN to be received by systems that are in another VPN. This is known VPN to be received by systems that are in another VPN. This is known
as an "extranet MVPN". This document specifies the procedures that as an "extranet MVPN". This document specifies the procedures that
are necessary in order to provide Extranet MVPN functionality. are necessary in order to provide Extranet MVPN functionality.
skipping to change at page 7, line 21 skipping to change at page 7, line 21
Source Mode" (ASM), as the multicast control protocol at the customer Source Mode" (ASM), as the multicast control protocol at the customer
sites. Support for other customer IP multicast control protocols sites. Support for other customer IP multicast control protocols
(e.g., [RFC5015], PIM "Dense Mode") is outside the scope of this (e.g., [RFC5015], PIM "Dense Mode") is outside the scope of this
document. Support for the customer use of MPLS multicast control document. Support for the customer use of MPLS multicast control
protocols (e.g., [RFC6388], [RFC4875]) is also outside the scope of protocols (e.g., [RFC6388], [RFC4875]) is also outside the scope of
this document. this document.
When a VPN customer uses ASM, the customer routers need to be able to When a VPN customer uses ASM, the customer routers need to be able to
map from a C-group address to a C-RP address. These mappings can be map from a C-group address to a C-RP address. These mappings can be
provisioned in each router, or can be discovered dynamically through provisioned in each router, or can be discovered dynamically through
protocols such as BSR [RFC5015]. However, it cannot be assumed that protocols such as BSR [RFC5059]. However, it cannot be assumed that
such protocols will automatically work in the context of an extranet. such protocols will automatically work in the context of an extranet.
Discussion of the use of such protocols in an extranet is outside the Discussion of the use of such protocols in an extranet is outside the
scope of this document. scope of this document.
1.2.2. Provider Multicast Control Protocols 1.2.2. Provider Multicast Control Protocols
[RFC6513] allows either PIM or BGP to be used as the protocol for [RFC6513] allows either PIM or BGP to be used as the protocol for
distributing customer multicast routing information. Except where distributing customer multicast routing information. Except where
otherwise specified, such as in Sections 6 and 7, the procedures of otherwise specified, such as in Sections 6 and 7, the procedures of
this document cover both cases. this document cover both cases.
skipping to change at page 18, line 43 skipping to change at page 18, line 43
o The MPLS Label field of R3's PMSI Tunnel attribute is zero, and o The MPLS Label field of R3's PMSI Tunnel attribute is zero, and
the MPLS label value of R4's PMSI Tunnel attribute is zero. the MPLS label value of R4's PMSI Tunnel attribute is zero.
In this example, it can be concluded that T3 and T4 are carrying In this example, it can be concluded that T3 and T4 are carrying
packets from the same ingress VRF. Thus if T3 is the expected packets from the same ingress VRF. Thus if T3 is the expected
P-tunnel for a (C-S,C-G) flow, (S,G) packets from T4 can be safely P-tunnel for a (C-S,C-G) flow, (S,G) packets from T4 can be safely
delivered to the egress VRF; they do not need to be discarded. delivered to the egress VRF; they do not need to be discarded.
Similarly, if T4 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) Similarly, if T4 is the expected P-tunnel for a (C-S,C-G) flow, (S,G)
packets from T3 can be safely delivered to the egress VRF. packets from T3 can be safely delivered to the egress VRF.
When Ingress Replication P-tunnels are being used, please see When Ingress Replication (IR) P-tunnels are being used, please see
[MVPN-IR], especially Section 6 ("The PTA's MPLS Label Field") for a [MVPN-IR], especially Section 6 ("The PTA's MPLS Label Field") for a
discussion of how to determine when packets from other than the discussion of how to determine when packets from other than the
expected P-tunnel must be discarded. expected P-tunnel must be discarded.
2.3.2. Policies to Prevent Ambiguity on a P-tunnel 2.3.2. Policies to Prevent Ambiguity on a P-tunnel
For P-tunnels that are advertised in S-PMSI A-D routes whose NLRI For P-tunnels that are advertised in S-PMSI A-D routes whose NLRI
contains (C-S,C-G) or (C-S,C-*), the ambiguities described in contains (C-S,C-G) or (C-S,C-*), the ambiguities described in
Sections 2.1 and 2.2 can be prevented by provisioning a policy that Sections 2.1 and 2.2 can be prevented by provisioning a policy that
assigns, to such P-tunnels, only flows from the same C-source. assigns, to such P-tunnels, only flows from the same C-source.
skipping to change at page 30, line 36 skipping to change at page 30, line 36
and Section 7 for more details on determining the expected P-tunnel and Section 7 for more details on determining the expected P-tunnel
for a given extranet C-flow. for a given extranet C-flow.
While the assignment of import and export RTs to routes is a While the assignment of import and export RTs to routes is a
deployment and provisioning issue rather than a protocol issue, it deployment and provisioning issue rather than a protocol issue, it
should be understood that failure to follow these rules is likely to should be understood that failure to follow these rules is likely to
result in VPN security violations. result in VPN security violations.
5.2. Considerations for Particular Inclusive Tunnel Types 5.2. Considerations for Particular Inclusive Tunnel Types
5.2.1. RSVP-TE P2MP 5.2.1. RSVP-TE P2MP or Ingress Replication
This section applies when Inclusive Tunnels are created using either
RSVP-TE P2MP or Ingress Replication.
Suppose a VRF, VRF-S, contains a given extranet C-source C-S, and Suppose a VRF, VRF-S, contains a given extranet C-source C-S, and
that VRF-S advertises in its Intra-AS I-PMSI A-D route a P2MP RSVP-TE that VRF-S advertises in its Intra-AS I-PMSI A-D route either a P2MP
as the P-tunnel to carry (extranet multicast) traffic. Suppose VRF-R RSVP-TE P-tunnel or an Ingress Replication P-tunnel to carry extranet
contains an extranet C-receiver that is allowed by policy to receive traffic.
extranet flows from C-S. Then the RT(s) carried by the Intra-AS
I-PMSI A-D routes originated by VRF-R must be such that those Intra- In order for VRF-S to set up the P2MP RSVP-TE or Ingress Replication
AS I-PMSI A-D routes will be imported into VRF-S. (I.e., In order P-tunnel, it must know all the PEs that are leaf nodes of the
for VRF-S to set up the P2MP RSVP-TE P-tunnel, it must know all the P-tunnel, and to learn this it MUST import an Intra-AS I-PMSI A-D
PEs that are leaf nodes of the P-tunnel, and to learn this it MUST route from every VRF that needs to receive data through that tunnel.
import an Intra-AS I-PMSI A-D route from every VRF that needs to
receive data through that tunnel.) Therefore if VRF-R contains an extranet C-receiver that is allowed by
policy to receive extranet flows from C-S, the the RT(s) carried by
the Intra-AS I-PMSI A-D routes originated by VRF-R must be such that
those Intra-AS I-PMSI A-D routes will be imported into VRF-S.
In the case of Ingress Replication, this has the following
consequence. If an egress PE has n VRFs with receivers for a flow
that VRF-S transmits on its I-PMSI, that egress PE will receive n
copies of the same packet, one for each of the n VRFs.
Note that Section 9.1.1 of [RFC6514] prohibits the Leaf Information
Required flag from being set in the PTA of an Intra-AS I-PMSI A-D
route. If this prohibition is ever removed, the requirement of this
section will apply only if VRF-S does not set that flag.
5.2.2. Ingress Replication 5.2.2. Ingress Replication
This section applies only when Inclusive Tunnels are created via
Ingress Replication.
[RFC6513] and [RFC6514] specify procedures that allow I-PMSIs to be [RFC6513] and [RFC6514] specify procedures that allow I-PMSIs to be
instantiated by "ingress replication" (IR). The concept of an IR instantiated by Ingress Replication. The concept of an IR P-tunnel,
P-tunnel, and the procedures for supporting IR P-tunnels, are and the procedures for supporting IR P-tunnels, are explained more
explained more fully in [MVPN-IR]. An IR P-tunnel can be thought of fully in [MVPN-IR]. An IR P-tunnel can be thought of as a P2MP tree
as a P2MP tree in which a packet is transmitted from one node on the in which a packet is transmitted from one node on the tree to another
tree to another by being encapsulated and sent through a unicast by being encapsulated and sent through a unicast tunnel.
tunnel.
As discussed in Section 2, when I-PMSIs are used to support As discussed in Section 2, when I-PMSIs are used to support
extranets, egress PEs MUST have the ability to discard customer extranets, egress PEs MUST have the ability to discard customer
multicast data packets that arrive on the wrong P-tunnel. When multicast data packets that arrive on the wrong P-tunnel. When
I-PMSIs are instantiated by IR, this implies that the following two I-PMSIs are instantiated by IR, this implies that the following two
procedures MUST be followed: procedures MUST be followed:
1. One of the following three procedures MUST be followed: 1. One of the following three procedures MUST be followed:
a. the "Single Forwarder Selection" procedures of [RFC6513] a. the "Single Forwarder Selection" procedures of [RFC6513]
skipping to change at page 56, line 44 skipping to change at page 57, line 18
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, February 2012.
[RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu,
"Wildcards in Multicast VPN Auto-Discovery Routes", RFC "Wildcards in Multicast VPN Auto-Discovery Routes", RFC
6625, May 2012. 6625, May 2012.
12.2. Informative References 12.2. Informative References
[MVPN-IR] Rosen, E., Subramanian, K., and J. Zhang, "Ingress [MVPN-IR] Rosen, E., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", internet-draft Replication Tunnels in Multicast VPN", internet-draft
draft-rosen-l3vpn-ir-02, July 2014. draft-ietf-bess-ir-00, July 2014.
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
Rendevous Point (RP) mechanism using Protocol Independent Rendevous Point (RP) mechanism using Protocol Independent
Multicast (PIM) and Multicast Source Discovery Protocol Multicast (PIM) and Multicast Source Discovery Protocol
(MSDP)", RFC 3446, January 2003. (MSDP)", RFC 3446, January 2003.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003. Protocol (MSDP)", RFC 3618, October 2003.
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
skipping to change at page 57, line 35 skipping to change at page 58, line 11
"Label Distribution Protocol Extensions for Point-to- "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011. Paths", RFC 6388, November 2011.
Authors' Addresses Authors' Addresses
Yakov Rekhter (editor) Yakov Rekhter (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US United States
Email: yakov@juniper.net
Eric C. Rosen (editor) Eric C. Rosen (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
US United States
Email: erosen@juniper.net Email: erosen@juniper.net
Rahul Aggarwal Rahul Aggarwal
Arktan Arktan
Email: raggarwa_1@yahoo.com Email: raggarwa_1@yahoo.com
Yiqun Cai Yiqun Cai
Microsoft Microsoft
1065 La Avenida 1065 La Avenida
Mountain View, CA 94043 Mountain View, CA 94043
US United States
Email: yiqunc@microsoft.com Email: yiqunc@microsoft.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Copernicuslaan 50 Copernicuslaan 50
Antwerp 2018 Antwerp 2018
BE Belgium
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@alcatel-lucent.com
Thomas Morin Thomas Morin
France Telecom - Orange Orange
2 Avenue Pierre-Marzin 2 Avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
FR France
Email: thomas.morin@orange.com Email: thomas.morin@orange.com
Praveen Muley Praveen Muley
Alcatel-Lucent Alcatel-Lucent
Email: Praveen.Muley@alcatel-lucent.com Email: Praveen.Muley@alcatel-lucent.com
Ray Qiu Ray Qiu
Juniper Networks, Inc. Juniper Networks, Inc.
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US United States
Email: rqiu@juniper.net Email: rqiu@juniper.net
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
BE Belgium
Email: ice@cisco.com Email: ice@cisco.com
 End of changes. 35 change blocks. 
55 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/