draft-ietf-bier-mvpn-00.txt   draft-ietf-bier-mvpn-01.txt 
Internet Engineering Task Force E. Rosen, Ed. Internet Engineering Task Force E. Rosen, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track M. Sivakumar Intended status: Standards Track M. Sivakumar
Expires: October 29, 2015 IJ. Wijnands Expires: January 7, 2016 IJ. Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
S. Aldrin S. Aldrin
Huawei Technologies Google, Inc.
A. Dolganow A. Dolganow
Alcatel-Lucent Alcatel-Lucent
T. Przygienda T. Przygienda
Ericsson Ericsson
April 27, 2015 July 6, 2015
Multicast VPN Using BIER Multicast VPN Using BIER
draft-ietf-bier-mvpn-00 draft-ietf-bier-mvpn-01
Abstract Abstract
The Multicast Virtual Private Network (MVPN) specifications require The Multicast Virtual Private Network (MVPN) specifications require
the use of multicast tunnels ("P-tunnels") that traverse a Service the use of multicast tunnels ("P-tunnels") that traverse a Service
Provider's backbone network. The P-tunnels are used for carrying Provider's backbone network. The P-tunnels are used for carrying
multicast traffic across the backbone. A variety of P-tunnel types multicast traffic across the backbone. A variety of P-tunnel types
are supported. Bit Index Explicit Replication (BIER) is a new are supported. Bit Index Explicit Replication (BIER) is a new
architecture that provides optimal multicast forwarding through a architecture that provides optimal multicast forwarding through a
"multicast domain", without requiring intermediate routers to "multicast domain", without requiring intermediate routers to
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 October 29, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4 2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4
3. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 6 3. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 6
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Using the LIR Flag . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4.1. Encapsulation and Transmission . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 8 4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
[RFC6513] and [RFC6514] specify the protocols and procedures that a [RFC6513] and [RFC6514] specify the protocols and procedures that a
Service Provider (SP) can use to provide Multicast Virtual Private Service Provider (SP) can use to provide Multicast Virtual Private
Network (MVPN) service to its customers. Multicast tunnels are Network (MVPN) service to its customers. Multicast tunnels are
created through an SP's backbone network; these are known as created through an SP's backbone network; these are known as
"P-tunnels". The P-tunnels are used for carrying multicast traffic "P-tunnels". The P-tunnels are used for carrying multicast traffic
across the backbone. The MVPN specifications allow the use of across the backbone. The MVPN specifications allow the use of
several different kinds of P-tunnel technology. several different kinds of P-tunnel technology.
skipping to change at page 3, line 23 skipping to change at page 3, line 27
architecture provides protocols and procedures that allow the traffic architecture provides protocols and procedures that allow the traffic
of multiple MVPNs to be aggregated on a single P-tunnel. In this of multiple MVPNs to be aggregated on a single P-tunnel. In this
document, we specify how to use these multi-VPN aggregation document, we specify how to use these multi-VPN aggregation
procedures to enable BIER to transport traffic from multiple MVPNs. procedures to enable BIER to transport traffic from multiple MVPNs.
MVPN traffic must sometimes traverse more than one IGP domain, MVPN traffic must sometimes traverse more than one IGP domain,
whereas BIER only carries multicast traffic within a single IGP whereas BIER only carries multicast traffic within a single IGP
domain. However, the MVPN specifications allow P-tunnels to be domain. However, the MVPN specifications allow P-tunnels to be
"segmented", where the segmentation points may either be Autonomous "segmented", where the segmentation points may either be Autonomous
System Border Routers (ASBRs), as described in [RFC6514], or Area System Border Routers (ASBRs), as described in [RFC6514], or Area
Border Routers (ABRs), as described in [SEAMLESS_MCAST]. As long as Border Routers (ABRs), as described in [RFC7524]. As long as the
the segmentation points are capable of acting as BFIRs and BFERs, segmentation points are capable of acting as BFIRs and BFERs, BIER
BIER can be used to provide some or all of the segments of a can be used to provide some or all of the segments of a P-tunnel.
P-tunnel.
This revision of the document does not specify the procedures This revision of the document does not specify the procedures
necessary to support MVPN customers that are using BIDIR-PIM. Those necessary to support MVPN customers that are using BIDIR-PIM. Those
procedures will be added in a future revision. procedures will be added in a future revision.
This document uses the following terminology from [BIER_ARCH]: This document uses the following terminology from [BIER_ARCH]:
o BFR: Bit-Forwarding Router. o BFR: Bit-Forwarding Router.
o BFIR: Bit-Forwarding Ingress Router. o BFIR: Bit-Forwarding Ingress Router.
skipping to change at page 5, line 16 skipping to change at page 5, line 20
originator of the route that is carrying this PTA. This will originator of the route that is carrying this PTA. This will
either be a /32 IPv4 address or a /128 IPv6 address. Whether either be a /32 IPv4 address or a /128 IPv6 address. Whether
the address is IPv4 or IPv6 can be inferred from the total the address is IPv4 or IPv6 can be inferred from the total
length of the PMSI Tunnel attribute. length of the PMSI Tunnel attribute.
o "MPLS label". This field contains an upstream-assigned MPLS o "MPLS label". This field contains an upstream-assigned MPLS
label. It is assigned by the router that originates the BGP route label. It is assigned by the router that originates the BGP route
to which the PTA is attached. Constraints on the way in which the to which the PTA is attached. Constraints on the way in which the
originating router selects this label are discussed below. originating router selects this label are discussed below.
o "Leaf Info Required Bit". The setting of this bit depends upon o "Flags". When the tunnel type is BIER, two of the bits in the PTA
the type of route and the NLRI of the route that carries the PTA. Flags field are meaningful. Details about the use of these bits
can be found in Section 3.
* In an I-PMSI A-D route or a (C-*,C-*) S-PMSI A-D route, the bit * "Leaf Info Required per Flow (LIR-pF)". This bit is introduced
SHOULD be clear. in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this bit UNLESS
it knows that all the BFERs in the BIER domain (or at least all
the BFERs to which it needs to transmit) support this bit.
(How this is known is outside the scope of this document.)
This bit MAY be set in a (C-*,C-*) S-PMSI A-D route, but MUST
NOT be set in I-PMSI A-D routes or in other S-PMSI A-D routes.
* In other S-PMSI A-D routes, the bit SHOULD be set. * "Leaf Info Required Bit". The setting of this bit depends upon
the type of route and the NLRI of the route that carries the
PTA.
+ In an I-PMSI A-D route or a (C-*,C-*) S-PMSI A-D route, the
bit SHOULD be clear, unless the LIR-pF bit has also been set
(see above). This bit SHOULD also be clear in a (C-S,C-*)
or (C-*,C-G) S-PMSI A-D route.
+ In other S-PMSI A-D routes, the bit SHOULD be set.
Note that if a PTA specifying "BIER" is attached to an I-PMSI or Note that if a PTA specifying "BIER" is attached to an I-PMSI or
S-PMSI A-D route, the route MUST NOT be distributed beyond the S-PMSI A-D route, the route MUST NOT be distributed beyond the
boundaries of a BIER domain. That is, any routers that receive the boundaries of a BIER domain. That is, any routers that receive the
route must be in the same BIER domain as the originator of the route. route must be in the same BIER domain as the originator of the route.
If the originator is in more than one BIER domain, the route must be If the originator is in more than one BIER domain, the route must be
distributed only within the BIER domain in which the BFR-Prefix in distributed only within the BIER domain in which the BFR-Prefix in
the PTA uniquely identifies the originator. As with all MVPN routes, the PTA uniquely identifies the originator. As with all MVPN routes,
distribution of these routes is controlled by the provisioning of distribution of these routes is controlled by the provisioning of
Route Targets. Route Targets.
skipping to change at page 6, line 5 skipping to change at page 6, line 24
functionality, and if the two routes originate from different functionality, and if the two routes originate from different
VRFs, then the respective PTAs of the two routes MUST contain VRFs, then the respective PTAs of the two routes MUST contain
different MPLS label values. different MPLS label values.
o If the ingress PE is supporting the "Extranet Separation" feature o If the ingress PE is supporting the "Extranet Separation" feature
of MVPN extranet (see Section 7.3 of [EXTRANET], section ), and if of MVPN extranet (see Section 7.3 of [EXTRANET], section ), and if
one of the routes carries the "Extranet Separation" extended one of the routes carries the "Extranet Separation" extended
community and the other does not, then the respective PTAs of the community and the other does not, then the respective PTAs of the
two routes MUST contain different MPLS label values. two routes MUST contain different MPLS label values.
o If segmented P-tunnels are being used, then the respective PTAs of
the two routes MUST contain different MPLS label values, as long
as the NLRIs are not identical. In this case, the MPLS label can
be used by the BFER to identify the particular C-flow to which a
data packet belongs, and this greatly simplifies the process of
forwarding a received packet to its next P-tunnel segment. This
is explained further in Section 4.
When segmented P-tunnels are being used, an ABR or ASBR may receive, When segmented P-tunnels are being used, an ABR or ASBR may receive,
from a BIER domain, an x-PMSI A-D route whose PTA specifies "BIER". from a BIER domain, an x-PMSI A-D route whose PTA specifies "BIER".
This means that BIER is being used for one segment of a segmented This means that BIER is being used for one segment of a segmented
P-tunnel. The ABR/ASBR may in turn need to originate an x-PMSI A-D P-tunnel. The ABR/ASBR may in turn need to originate an x-PMSI A-D
route whose PTA identifies the next segment of the P-tunnel. The route whose PTA identifies the next segment of the P-tunnel. The
next segment may also be "BIER". Suppose an ASBR receives x-PMSI A-D next segment may also be "BIER". Suppose an ASBR receives x-PMSI A-D
routes R1 and R2, and as a result originates x-PMSI A-D routes R3 and routes R1 and R2, and as a result originates x-PMSI A-D routes R3 and
R4 respectively, where the PTAs of each of the four routes specify a R4 respectively, where the PTAs of each of the four routes specify a
BIER.. Then the PTAs of R3 and R4 MUST NOT specify the same MPLS BIER. Then the PTAs of R3 and R4 MUST NOT specify the same MPLS
label, UNLESS both of the following conditions hold: label, UNLESS both of the following conditions hold:
o R1 and R2 have the same "originating router" in their respective o R1 and R2 have the same "originating router" in their respective
NLRIs. NLRIs.
o R1 and R2 specify the same MPLS label in their respective PTAs. o R1 and R2 specify the same MPLS label in their respective PTAs.
3. Explicit Tracking 3. Explicit Tracking
[Editor's note: The procedures of this section are still under
discussion, and significant changes may be expected in the next
revision.]
When using BIER to transport an MVPN data packet through a BIER When using BIER to transport an MVPN data packet through a BIER
domain, an ingress PE functions as a BFIR (see [BIER_ARCH]). The domain, an ingress PE functions as a BFIR (see [BIER_ARCH]). The
BFIR must determine the set of BFERs to which the packet needs to be BFIR must determine the set of BFERs to which the packet needs to be
delivered. This is done by using the explicit tracking mechanism delivered. This can be done in either of two ways:
specified in [RFC6513] and [RFC6514].
1. By using the explicit tracking mechanism based on the "Leaf Info
Required" flag, as specified in [RFC6513] and [RFC6514], or
2. By using the explicit tracking mechanism based on the LIR-pF flag
as specified in [EXPLICIT_TRACKING]. This mechanism MAY be used
if (and only if) segmented P-tunnels are not being used.
3.1. Using the LIR Flag
To determine the set of BFERs to which a given MVPN data packet needs To determine the set of BFERs to which a given MVPN data packet needs
to be delivered, the BFIR originating an S-PMSI A-D route sets the to be delivered, the BFIR originating an S-PMSI A-D route sets the
LIR bit in the route's PTA. Per [RFC6514], the BFERs will respond LIR bit in the route's PTA. Per [RFC6514], the BFERs will respond
with Leaf A-D routes. By matching the received Leaf A-D routes to with Leaf A-D routes. By matching the received Leaf A-D routes to
the originated S-PMSI A-D routes, the originator of the S-PMSI A-D the originated S-PMSI A-D routes, the originator of the S-PMSI A-D
route determines the set of BFERs that need to receive the multicast route determines the set of BFERs that need to receive the multicast
data flow (or flows) that is (are) identified in the NLRI of the of data flow (or flows) that is (are) identified in the NLRI of the of
the S-PMSI A-D route. the S-PMSI A-D route.
This requires that each BFIR originate an S-PMSI A-D route for each This requires that each BFIR originate an S-PMSI A-D route for each
C-flow for which it serves as BFIR. The BFIR MAY include, in each C-flow for which it serves as BFIR. The BFIR MAY include, in each
such route, a PTA as described in Section 2. However, if the BFIR such route, a PTA as described in Section 2. However, if the BFIR
has originated an I-PMSI A-D route or a wildcard S-PMSI A-D route has originated an I-PMSI A-D route or a wildcard S-PMSI A-D route
that "matches" (according to the rules of [RFC6625]) a particular that "matches" (according to the rules of [RFC6625]) a particular
C-flow, then it may do explicit tracking for that C-flow by C-flow, then it may do explicit tracking for that C-flow by
originating an S-PMSI A-D route for that C-flow, but including a PTA originating an S-PMSI A-D route for that C-flow, but including a PTA
that specifies "no tunnel type". that specifies "no tunnel type".
3.2. Using the LIR-pF Flag
If segmented P-tunnels are not being used, the BFIR can determine the
set of BFERs to which a given MVPN data packet needs to be delivered
by originating a (C-*,C-*) S-PMSI A-D route, and by setting the LIR-
pF flag in the PTA of that route. Per [EXPLICIT_TRACKING], each BFER
will respond with one or more Leaf A-D routes, identifying the flows
that it is expecting to receive from the BFIR that originated the
(C-*,C-*) S-PMSI A-D route.
A BFIR MUST NOT use this method of finding the set of BFERs needing
to receive a given C-flow unless it knows that all those BFERs
support the LIR-pF flag. How this is known is outside the scope of
this document.
This option greatly reduces the number of S-PMSI A-D routes that a
BFIR needs to originate; it now needs to originate only one such
route, rather than one for each C-flow. However, it does not provide
a way for the BFIR to assign a distinct label to each C-flow.
Therefore it cannot be used when segmented P-tunnels are in use (see
Section 4 for an explanation).
4. Data Plane 4. Data Plane
The MVPN application plays the role of the "multicast flow layer" as The MVPN application plays the role of the "multicast flow layer" as
described in [BIER_ARCH]. described in [BIER_ARCH].
4.1. Encapsulation and Transmission
To transmit an MVPN data packet, an ingress PE follows the rules of To transmit an MVPN data packet, an ingress PE follows the rules of
[RFC6625] to find the S-PMSI A-D route or I-PMSI A-D route that is a [RFC6625] to find the S-PMSI A-D route or I-PMSI A-D route that is a
"match for transmission" for that packet. (In applying the rules of "match for transmission" for that packet. (In applying the rules of
[RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel [RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel
information" is ignored.) If the matching route has a PTA specifying information" is ignored.) If the matching route has a PTA specifying
a "BIER", the (upstream-assigned) MPLS label from that PTA is pushed a "BIER", the (upstream-assigned) MPLS label from that PTA is pushed
on the packet's label stack. Then the packet is forwarded according on the packet's label stack. Then the packet is encapsulated in a
to the procedures of [BIER_ARCH] and [BIER_ENCAPS]. (See especially BIER header and forwarded, according to the procedures of [BIER_ARCH]
Section 4, "Imposing and Processing the BIER Encapsulation", of and [BIER_ENCAPS]. (See especially Section 4, "Imposing and
[BIER_ENCAPS].) Processing the BIER Encapsulation", of [BIER_ENCAPS].)
In order to create the proper BIER header for a given packet, the
BFIR must know all the BFERs that need to receive that packet. It
determines this by finding all the Leaf A-D routes that correspond to
the S-PMSI A-D route that is the packet's match for transmission.
There are two different cases to consider:
1. The S-PMSI A-D route that is the match for transmission carries a
PTA that has the LIR flag set but does not have the LIR-pF flag
set.
In this case, the corresponding Leaf A-D routes are those whose
"route key" field is identical to the NLRI of the S-PMSI A-D
route.
2. The S-PMSI A-D route that is the match for transmission carries a
PTA that has the LIR-pF flag.
In this case, the corresponding Leaf A-D routes are those whose
"route key" field is derived from the NLRI of the S-PMSI A-D
route according to the procedures described in Section 5.2 of
[EXPLICIT_TRACKING].
4.2. Disposition
The procedures for handling a received BIER packet at BFER depend on
whether the BFER is an egress PE for the packet. A BFER can tell
whether it is an egress PE for a given BIER packet by examining the
MPLS label that the packet is carrying immediately after the BIER
header. This will be an upstream-assigned label (from the BFIR) that
has been advertised in the PTA of an S-PMSI A-D route.
Note that if segmented P-tunnels are in use, a BFER might be a
P-tunnel segmentation border router rather than an egress PE, or a
BFER might be both an egress PE and a P-tunnel segmentation border
router.
Depending upon the role of the BFER for given packet, it may need to
follow the procedures of Section 4.2.1, the procedures of
Section 4.2.2, or both.
4.2.1. At a BFER that is an Egress PE
When a BFER receives an MVPN multicast data packet that has been When a BFER receives an MVPN multicast data packet that has been
BIER-encapsulated, the BIER layer passes the following information to BIER-encapsulated, it determines from the MPLS label at the top of
the multicast flow layer: the packet's label stack whether it is an egress PE for the packet or
not. If it is an egress PE, the BIER layer passes the following
information to the multicast flow layer:
o The BFR-prefix corresponding to the sub-domain-id and BFIR-id in o The BFR-prefix corresponding to the sub-domain-id and BFIR-id in
the BIER header. the BIER header.
o The "payload", which is an MPLS packet whose top label is an o The "payload", which is an MPLS packet whose top label is an
upstream-assigned label. The BFR-prefix provides the "context" in upstream-assigned label. The BFR-prefix provides the "context" in
which the upstream-assigned label is interpreted. which the upstream-assigned label is interpreted.
Note that per [RFC5331], the context for an upstream-assigned Note that per [RFC5331], the context for an upstream-assigned
label is the IP address of the label assigner, which in this case label is the IP address of the label assigner, which in this case
is the BFR-prefix of the BFIR. is the BFR-prefix of the BFIR.
4.2.2. At a BFER that is a P-tunnel Segmentation Boundary
When segmented P-tunnels are being used, a BFER that receives a BIER-
encapsulated MVPN multicast data packet may need to be forwarded on
its next P-tunnel segment. The choice of the next P-tunnel segment
for the packet depends upon the C-flow to which the packet belongs.
Since the BFIR assigns a distinct upstream-assigned MPLS label for
each C-flow, the BFER can select the proper "next P-tunnel segment"
for a given packet simply by looking up the upstream-assigned label
that immediately follows the BIER header. (If the BFIR had not
assigned a distinct label to each C-flow, the BFER would need to
maintain all the state from the Multicast Flow Overlay in order to
select the next P-tunnel segment.)
5. Acknowledgments 5. Acknowledgments
The authors wish to thank Jeffrey Zhang for his ideas and The authors wish to thank Jeffrey Zhang for his ideas and
contributions to this work. contributions to this work.
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign a value for "BIER" from the "P-Multicast IANA is requested to assign a value for "BIER" from the "P-Multicast
Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The
reference should be this document. reference should be this document.
skipping to change at page 8, line 44 skipping to change at page 11, line 15
[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.
8.2. Informative References 8.2. Informative References
[EXPLICIT_TRACKING]
Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang,
"Explicit Tracking with Wild Card Routes in Multicast
VPN", internet-draft draft-ietf-bess-mvpn-expl-track-00,
March 2015.
[EXTRANET] [EXTRANET]
Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
MPLS VPNs", internet-draft draft-ietf-bess-mvpn-extranet- Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet-
01, April 2015. draft draft-ietf-bess-mvpn-extranet-02, May 2015.
[SEAMLESS_MCAST] [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area P2MP Point-to-Multipoint (P2MP) Segmented Label Switched Paths
Segmented LSPs", internet-draft draft-ietf-mpls-seamless- (LSPs)", RFC 7524, May 2015.
mcast-17, February 2015.
Authors' Addresses Authors' Addresses
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
United States United States
Email: erosen@juniper.net Email: erosen@juniper.net
skipping to change at page 9, line 28 skipping to change at page 12, line 4
Email: erosen@juniper.net Email: erosen@juniper.net
Mahesh Sivakumar Mahesh Sivakumar
Cisco Systems, Inc. Cisco Systems, Inc.
510 McCarthy Blvd 510 McCarthy Blvd
Milpitas, California 95035 Milpitas, California 95035
United States United States
Email: masivaku@cisco.com Email: masivaku@cisco.com
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
Sam K Aldrin Sam K Aldrin
Huawei Technologies Google, Inc.
2330 Central Express Way 1600 Amphitheatre Parkway
Santa Clara, California Mountain View, California
United States United States
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Andrew Dolganow Andrew Dolganow
Alcatel-Lucent Alcatel-Lucent
600 March Rd. 600 March Rd.
Ottawa, Ontario K2K 2E6 Ottawa, Ontario K2K 2E6
Canada Canada
Email: andrew.dolganow@alcatel-lucent.com Email: andrew.dolganow@alcatel-lucent.com
Tony Przygienda Tony Przygienda
Ericsson Ericsson
 End of changes. 25 change blocks. 
47 lines changed or deleted 166 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/