draft-ietf-bier-mvpn-09.txt   draft-ietf-bier-mvpn-10.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: Experimental M. Sivakumar Intended status: Standards Track M. Sivakumar
Expires: May 17, 2018 Cisco Systems, Inc. Expires: August 26, 2018 Cisco Systems, Inc.
S. Aldrin S. Aldrin
Google, Inc. Google, Inc.
A. Dolganow A. Dolganow
Nokia Nokia
T. Przygienda T. Przygienda
Juniper Networks, Inc. Juniper Networks, Inc.
November 13, 2017 February 22, 2018
Multicast VPN Using BIER Multicast VPN Using BIER
draft-ietf-bier-mvpn-09 draft-ietf-bier-mvpn-10
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 47 skipping to change at page 1, line 47
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 17, 2018. This Internet-Draft will expire on August 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 5 skipping to change at page 3, line 5
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.
Bit Index Explicit Replication (BIER) ([BIER_ARCH]) is an Bit Index Explicit Replication (BIER) ([RFC8279]) is an architecture
architecture that provides optimal multicast forwarding through a that provides optimal multicast forwarding through a "multicast
"multicast domain", without requiring intermediate routers to domain", without requiring intermediate routers to maintain any per-
maintain any per-flow state or to engage in an explicit tree-building flow state or to engage in an explicit tree-building protocol. The
protocol. The purpose of the current document is to specify the purpose of the current document is to specify the protocols and
protocols and procedures needed in order to provide MVPN service procedures needed in order to provide MVPN service using BIER to
using BIER to transport the multicast traffic over the backbone. transport the multicast traffic over the backbone.
Although BIER does not explicitly build and maintain multicast Although BIER does not explicitly build and maintain multicast
tunnels, one can think of BIER as using a number of implicitly tunnels, one can think of BIER as using a number of implicitly
created tunnels through a "BIER domain". In particular, one can created tunnels through a "BIER domain". In particular, one can
think of there as being one Point-to-Multipoint (P2MP) tunnel from think of there as being one Point-to-Multipoint (P2MP) tunnel from
each "Bit Forwarding Ingress Router" (BFIR) to all the "Bit each "Bit Forwarding Ingress Router" (BFIR) to all the "Bit
Forwarding Egress Routers" (BFERs) in the BIER domain, where a BIER Forwarding Egress Routers" (BFERs) in the BIER domain, where a BIER
domain is generally co-extensive with an IGP network. These domain is generally co-extensive with an IGP network. These
"tunnels" are not specific to any particular VPN. However, the MVPN "tunnels" are not specific to any particular VPN. However, the MVPN
architecture provides protocols and procedures that allow the traffic architecture provides protocols and procedures that allow the traffic
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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 [RFC7524]. As long as the Border Routers (ABRs), as described in [RFC7524]. As long as the
segmentation points are capable of acting as BFIRs and BFERs, BIER segmentation points are capable of acting as BFIRs and BFERs, BIER
can be used to provide some or all of the segments of a P-tunnel. can be used to provide some or all of the segments of a P-tunnel.
Procedures to support MVPN customers who are using BIDIR-PIM are Procedures to support MVPN customers who are using BIDIR-PIM are
outside the scope of this document. outside the scope of this document.
This document uses the following terminology from [BIER_ARCH]: This document uses the following terminology from [RFC8279]:
o BFR: Bit-Forwarding Router. o BFR: Bit-Forwarding Router.
o BFIR: Bit-Forwarding Ingress Router. o BFIR: Bit-Forwarding Ingress Router.
o BFER: Bit-Forwarding Egress Router. o BFER: Bit-Forwarding Egress Router.
This document uses the following terminology from [RFC6513]: This document uses the following terminology from [RFC6513]:
o MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in o MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in
skipping to change at page 4, line 49 skipping to change at page 4, line 49
Tunnel attribute is attached to such a route in order to identify Tunnel attribute is attached to such a route in order to identify
a particular P-tunnel that is associated with the PMSI. When a particular P-tunnel that is associated with the PMSI. When
C-flows of multiple VPNs are carried in a single P-tunnel, this C-flows of multiple VPNs are carried in a single P-tunnel, this
attribute also carries the information needed to multiplex and attribute also carries the information needed to multiplex and
demultiplex the C-flows. A PTA can also be carried by a Leaf A-D demultiplex the C-flows. A PTA can also be carried by a Leaf A-D
root. In this case, it contains information that is needed in root. In this case, it contains information that is needed in
order for the originator of the route to join the specified order for the originator of the route to join the specified
P-tunnel. P-tunnel.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes 2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes
As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by
an x-PMSI A-D route identifies the P-tunnel that is used to an x-PMSI A-D route identifies the P-tunnel that is used to
instantiate a particular PMSI. If a PMSI is to be instantiated by instantiate a particular PMSI. If a PMSI is to be instantiated by
BIER, the PTA is constructed by a BFIR. BIER, the PTA is constructed by a BFIR.
If segmented P-tunnels are not being used, the PTA attached to a If segmented P-tunnels are not being used, the PTA attached to a
given x-PMSI A-D route is constructed by the router that originated given x-PMSI A-D route is constructed by the router that originated
the route (typically by the ingress PE), and the PTA is not changed the route (typically by the ingress PE), and the PTA is not changed
as the route is propagated. as the route is propagated.
If segmented P-tunnels are being used, the PTA attached to a given If segmented P-tunnels are being used, the PTA attached to a given
x-PMSI A-D route by the route's originator may replaced, at a x-PMSI A-D route by the route's originator may be replaced, at a
segmentation point (a BFER), by a PTA identifying the next segment of segmentation point (a BFER), by a PTA identifying the next segment of
the P-tunnel. If the next segment of the P-tunnel is instantiated by the P-tunnel. If the next segment of the P-tunnel is instantiated by
BIER, the segmentation point serves as the BFIR for that next BIER, the segmentation point serves as the BFIR for that next
segment. segment.
In either case, a PTA is constructed by a BFIR as follows (see In either case, a PTA is constructed by a BFIR as follows (see
Figure 1): Figure 1):
The PTA contains the following fields: The PTA contains the following fields:
skipping to change at page 5, line 41 skipping to change at page 5, line 41
(PMSI Tunnel) Tunnel Types" registry. This codepoint is used to (PMSI Tunnel) Tunnel Types" registry. This codepoint is used to
indicate that the PMSI is instantiated by BIER. indicate that the PMSI is instantiated by BIER.
Although BIER does not actually create tunnels, the MVPN Although BIER does not actually create tunnels, the MVPN
procedures treat BIER as if it were a type of tunnel. procedures treat BIER as if it were a type of tunnel.
o "Tunnel Identifier". When the "tunnel type" is "BIER", this field o "Tunnel Identifier". When the "tunnel type" is "BIER", this field
contains three subfields: contains three subfields:
1. The first subfield is a single octet, containing a BIER 1. The first subfield is a single octet, containing a BIER
sub-domain-id. (See [BIER_ARCH].) This indicates that sub-domain-id. (See [RFC8279].) This indicates that packets
packets sent on the PMSI will be sent on the specified BIER sent on the PMSI will be sent on the specified BIER
sub-domain. How that sub-domain is chosen is outside the sub-domain. How that sub-domain is chosen is outside the
scope of this document. scope of this document.
2. The second subfield is a two-octet field containing the 2. The second subfield is a two-octet field containing the
BFR-id, in the sub-domain identified in the first subfield, of BFR-id, in the sub-domain identified in the first subfield, of
the router that is constructing the PTA. the router that is constructing the PTA.
3. The third subfield is the BFR-prefix (see [BIER_ARCH]) of the 3. The third subfield is the BFR-prefix (see [RFC8279]) of the
router (a BFIR) that is constructing the PTA. The BFR-prefix router (a BFIR) that is constructing the PTA. The BFR-prefix
will either be a /32 IPv4 address or a /128 IPv6 address. will either be a /32 IPv4 address or a /128 IPv6 address.
Whether the address is IPv4 or IPv6 can be inferred from the Whether the address is IPv4 or IPv6 can be inferred from the
total length of the PTA. total length of the PTA.
The BFR-prefix need not be the same IP address that is carried The BFR-prefix need not be the same IP address that is carried
in any other field of the x-PMSI A-D route, even if the BFIR in any other field of the x-PMSI A-D route, even if the BFIR
is the originating router of the x-PMSI A-D route. is the originating router of the x-PMSI A-D route.
skipping to change at page 9, line 33 skipping to change at page 9, line 33
then the dataplane must be programmed to replace L2 with L4, and to then the dataplane must be programmed to replace L2 with L4, and to
reencapsulate the packet in a BIER header, with B1's BFR-id in the reencapsulate the packet in a BIER header, with B1's BFR-id in the
BFIR-id field. The BitString of the new BIER header is determined by BFIR-id field. The BitString of the new BIER header is determined by
the MVPN explicit tracking procedures (see Section 2.2 in the BIER the MVPN explicit tracking procedures (see Section 2.2 in the BIER
domain of the next segment. domain of the next segment.
2.2. Explicit Tracking 2.2. Explicit Tracking
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 [RFC8279]). The BFIR
BFIR must determine the set of BFERs to which the packet needs to be must determine the set of BFERs to which the packet needs to be
delivered. This can be done in either of two ways: delivered. This can be done in either of two ways:
1. Using the explicit tracking mechanism based on the "Leaf Info 1. Using the explicit tracking mechanism based on the "Leaf Info
Required" flag specified in [RFC6513] and [RFC6514]. This method Required" flag specified in [RFC6513] and [RFC6514]. This method
is further described in Section 2.2.1. is further described in Section 2.2.1.
2. Using the OPTIONAL explicit tracking mechanism based on the 2. Using the OPTIONAL explicit tracking mechanism based on the
LIR-pF flag specified in [EXPLICIT_TRACKING]. This method, LIR-pF flag specified in [EXPLICIT_TRACKING]. This method,
further described in Section 2.2.2, may be used if (and only if) further described in Section 2.2.2, may be used if (and only if)
segmented P-tunnels are not being used. segmented P-tunnels are not being used.
skipping to change at page 12, line 25 skipping to change at page 12, line 25
When an ingress PE receives such a Leaf A-D route, it learns the When an ingress PE receives such a Leaf A-D route, it learns the
BFR-prefix of the egress PE from the PTA. The ingress PE does not BFR-prefix of the egress PE from the PTA. The ingress PE does not
make any use the value of the PTA's MPLS label field. make any use the value of the PTA's MPLS label field.
Failure to properly construct the PTA cannot always be detected by Failure to properly construct the PTA cannot always be detected by
the protocol, and will cause improper delivery of the data packets. the protocol, and will cause improper delivery of the data packets.
4. Data Plane 4. Data Plane
The MVPN application plays the role of the "multicast flow overlay" The MVPN application plays the role of the "multicast flow overlay"
as described in [BIER_ARCH]. as described in [RFC8279].
4.1. Encapsulation and Transmission 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 x-PMSI A-D route that is a "match for [RFC6625] to find the x-PMSI A-D route that is a "match for
transmission" for that packet. (In applying the rules of [RFC6625], transmission" for that packet. (In applying the rules of [RFC6625],
any S-PMSI A-D route with a PTA specifying "no tunnel information" is any S-PMSI A-D route with a PTA specifying "no tunnel information" is
ignored.) If the matching route has a PTA specifying "BIER", the ignored.) If the matching route has a PTA specifying "BIER", the
(upstream-assigned) MPLS label from that PTA is pushed on the (upstream-assigned) MPLS label from that PTA is pushed on the
packet's label stack. Then the packet is encapsulated in a BIER packet's label stack. Then the packet is encapsulated in a BIER
header. That is, the ingress PE functions as a BFIR. The BIER sub- header. That is, the ingress PE functions as a BFIR. The BIER
domain used for transmitting the packet is specified in the PTA of sub-domain used for transmitting the packet is specified in the PTA
the abovementioned x-PMSI A-D route. of the abovementioned x-PMSI A-D route.
In order to create the proper BIER header for a given packet, the 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 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 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. the S-PMSI A-D route that is the packet's match for transmission.
There are two different cases to consider: There are two different cases to consider:
1. The S-PMSI A-D route that is the match for transmission carries a 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 PTA that has the LIR flag set but does not have the LIR-pF flag
set. set.
skipping to change at page 13, line 23 skipping to change at page 13, line 23
The Leaf A-D route from a given BFER will contain a PTA that The Leaf A-D route from a given BFER will contain a PTA that
specifies the BFER's BFR-prefix. With this information, the BFIR can specifies the BFER's BFR-prefix. With this information, the BFIR can
construct the BIER BitString. construct the BIER BitString.
However, if the PTA of the Leaf A-D route from a given BFER specifies However, if the PTA of the Leaf A-D route from a given BFER specifies
a sub-domain other than the one being used for transmitting the a sub-domain other than the one being used for transmitting the
packet, the bit for that BFER cannot be determined, and that BFER packet, the bit for that BFER cannot be determined, and that BFER
will not receive the packet. will not receive the packet.
The BIER-encapsulated packet is then forwarded, according to the The BIER-encapsulated packet is then forwarded, according to the
procedures of [BIER_ARCH] and [BIER_ENCAPS]. (See especially procedures of [RFC8279] and [RFC8296]. (See especially Section 4,
Section 4, "Imposing and Processing the BIER Encapsulation", of "Imposing and Processing the BIER Encapsulation", of [RFC8296].)
[BIER_ENCAPS].)
4.2. Disposition 4.2. Disposition
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, the BIER layer passes the following information to
the multicast flow overlay: the multicast flow overlay:
o The sub-domain-id and the BFIR-id from the BIER header. (As the o The sub-domain-id and the BFIR-id from the BIER header. (As the
sub-domain-id is inferred from the BIFT-id field of the BIER sub-domain-id is inferred from the BIFT-id field of the BIER
header, an implementation might choose to pass the BIFT-id rather header, an implementation might choose to pass the BIFT-id rather
skipping to change at page 15, line 7 skipping to change at page 15, line 7
contributions to this work. We also thank Stig Venaas for his review contributions to this work. We also thank Stig Venaas for his review
and comments. and comments.
7. IANA Considerations 7. IANA Considerations
IANA has assigned the codepoint 0x0B to "BIER" in the "P-Multicast IANA has assigned the codepoint 0x0B to "BIER" in the "P-Multicast
Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry.
8. Security Considerations 8. Security Considerations
The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513] The security considerations of [RFC8279], [RFC8296], [RFC6513] and
and [RFC6514] are applicable. [RFC6514] are applicable.
9. References 9. References
9.1. Normative References 9.1. Normative References
[BIER_ARCH]
Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T.,
and S. Aldrin, "Multicast using Bit Index Explicit
Replication", internet-draft draft-ietf-bier-architecture-
07, June 2017.
[BIER_ENCAPS]
Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and
S. Aldrin, "Encapsulation for Bit Index Explicit
Replication in MPLS Networks", internet-draft draft-ietf-
bier-mpls-encapsulation-07.txt, June 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
skipping to change at page 16, line 5 skipping to change at page 15, line 42
[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, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
RFC 6625, DOI 10.17487/RFC6625, May 2012, RFC 6625, DOI 10.17487/RFC6625, May 2012,
<https://www.rfc-editor.org/info/rfc6625>. <https://www.rfc-editor.org/info/rfc6625>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
9.2. Informative References 9.2. Informative References
[EXPLICIT_TRACKING] [EXPLICIT_TRACKING]
Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang,
"Explicit Tracking with Wild Card Routes in Multicast "Explicit Tracking with Wild Card Routes in Multicast
VPN", internet-draft draft-ietf-bess-mvpn-expl-track-02, VPN", internet-draft draft-ietf-bess-mvpn-expl-track-02,
June 2017. June 2017.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., [RFC7524] 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
 End of changes. 18 change blocks. 
43 lines changed or deleted 48 lines changed or added

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