draft-ietf-bier-mvpn-07.txt   draft-ietf-bier-mvpn-08.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: Experimental M. Sivakumar
Expires: January 27, 2018 Cisco Systems, Inc. Expires: April 19, 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.
July 26, 2017 October 16, 2017
Multicast VPN Using BIER Multicast VPN Using BIER
draft-ietf-bier-mvpn-07 draft-ietf-bier-mvpn-08
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 40 skipping to change at page 1, line 40
over an SP backbone network. over an SP backbone network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 January 27, 2018. This Internet-Draft will expire on April 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (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
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 in x-PMSI A-D Routes . . . . 5 2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes . . . . 5
2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 8 2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 9 2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 9
2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 9 2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 10
3. Use of the PMSI Tunnel Attribute in Leaf A-D routes . . . . . 10 3. Use of the PMSI Tunnel Attribute in Leaf A-D routes . . . . . 11
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Encapsulation and Transmission . . . . . . . . . . . . . 11 4.1. Encapsulation and Transmission . . . . . . . . . . . . . 12
4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 13 4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 14
4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 13 4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 14
5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 13 5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 5, line 24 skipping to change at page 5, line 24
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 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: In either case, a PTA is constructed by a BFIR as follows (see
Figure 1):
The PTA contains the following fields: The PTA contains the following fields:
o "Tunnel Type". IANA is requested to assign a new tunnel type o "Tunnel Type". IANA has assigned 0x0B as the tunnel type
codepoint for "BIER" from the "P-Multicast Service Interface codepoint for "BIER" in the "P-Multicast Service Interface Tunnel
Tunnel (PMSI Tunnel) Tunnel Types" registry. This codepoint will (PMSI Tunnel) Tunnel Types" registry. This codepoint is used to
be 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 two 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 [BIER_ARCH].) This indicates that
packets sent on the PMSI will be sent on the specified BIER packets 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 the BFR-Prefix (see [BIER_ARCH]) of the 2. The second subfield is a two-octet field containing the
router (a BFIR) that is constructing the PTA. This must be BFR-id, in the sub-domain identified in the first subfield, of
the BFIR's BFR-prefix in the specified sub-domain. The the router that is constructing the PTA.
BFR-Prefix will either be a /32 IPv4 address or a /128 IPv6
address. Whether the address is IPv4 or IPv6 can be inferred 3. The third subfield is the BFR-Prefix (see [BIER_ARCH]) of the
from the total length of the PTA. router (a BFIR) that is constructing the PTA. The BFR-Prefix
will either be a /32 IPv4 address or a /128 IPv6 address.
Whether the address is IPv4 or IPv6 can be inferred from the
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.
Failure to properly set the Tunnel Identifier field cannot be Failure to properly set the Tunnel Identifier field cannot be
detected by the protocol, and will result in improper delivery of detected by the protocol, and will result in improper delivery of
the data packets sent on the PMSI. the data packets sent on the PMSI.
o "MPLS label". This field MUST contain an upstream-assigned non- o "MPLS Label". This field MUST contain an upstream-assigned non-
zero MPLS label. It is assigned by the router (a BFIR) that zero MPLS label. It is assigned by the router (a BFIR) that
constructs the PTA. Constraints on the way in which a BFIR constructs the PTA. Constraints on the way in which a BFIR
selects this label are discussed in Section 2.1. selects this label are discussed in Section 2.1.
Failure to follow the constraints on label assignment cannot be Failure to follow the constraints on label assignment cannot be
detected by the protocol, and may result in improper handling of detected by the protocol, and may result in improper handling of
data packets by the egress PE routers. data packets by the egress PE routers.
o "Flags". When the tunnel type is BIER, two of the flags in the o "Flags". When the tunnel type is BIER, two of the flags in the
PTA Flags field are meaningful. Details about the use of these PTA Flags field are meaningful. Details about the use of these
skipping to change at page 6, line 36 skipping to change at page 7, line 5
* "Leaf Info Required per Flow (LIR-pF)". This flag is * "Leaf Info Required per Flow (LIR-pF)". This flag is
introduced in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this introduced in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this
flag UNLESS it knows that all the BFERs in the BIER domain (or flag UNLESS it knows that all the BFERs in the BIER domain (or
at least all the BFERs to which it needs to transmit) support at least all the BFERs to which it needs to transmit) support
this flag. (How this is known is outside the scope of this this flag. (How this is known is outside the scope of this
document.) Procedures for the use of this flag are given in document.) Procedures for the use of this flag are given in
Section 2.2.2. Support for this flag is OPTIONAL. Section 2.2.2. Support for this flag is OPTIONAL.
* "Leaf Info Required Bit". See Section 2.2.1. * "Leaf Info Required Bit". See Section 2.2.1.
+---------------------------------+
| Flags (1 octet) |
+---------------------------------+
| Tunnel Type = 0x0B (1 octet) |
+---------------------------------+
| MPLS Label (3 octets) |
+---------------------------------+
| Sub-domain-id (1 octet) | <---
+---------------------------------+ |
| BFIR-id (2 octets) | |-- Tunnel
+---------------------------------+ | Identifier
| BFIR-Prefix (4 or 16 octets) | <---
+---------------------------------+
Figure 1: PMSI Tunnel Attribute for BIER
If a PTA specifying tunnel type "BIER" is attached to an x-PMSI A-D If a PTA specifying tunnel type "BIER" is attached to an x-PMSI A-D
route, the route MUST NOT be distributed beyond the boundaries of a route, the route MUST NOT be distributed beyond the boundaries of a
BIER domain. That is, any routers that receive the route must be in BIER domain. That is, any routers that receive the route must be in
the same BIER domain as the originator of the route. If the the same BIER domain as the originator of the route. If the
originator is in more than one BIER domain, the route must be 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. Thus the requirement expressed in this paragraph is Route Targets. Thus the requirement expressed in this paragraph is
really a requirement on the way the Route Targets are provisioned. really a requirement on the way the Route Targets are provisioned.
2.1. MPLS Label 2.1. MPLS Label
The MPLS Label carried in the PTA is an upstream-assigned label.
If two PTAs contain the same BFR-prefix in their respective Tunnel
Identifier fields, then the labels carried in those PTAs MUST come
from the same label space. (See section 7 of [RFC5331].) An
implementation may choose to use this fact when setting up the tables
it uses to interpret the upstream-assigned labels.
Suppose a BFIR attaches a PTA to each of two x-PMSI A-D routes, and Suppose a BFIR attaches a PTA to each of two x-PMSI A-D routes, and
both PTAs specify a tunnel type of "BIER". both PTAs specify a tunnel type of "BIER".
o If the two routes do not carry the same set of Route Targets o If the two routes do not carry the same set of Route Targets
(RTs), then their respective PTAs MUST contain different MPLS (RTs), then their respective PTAs MUST contain different MPLS
label values. label values.
o If the two routes do not have the same Address Family Identifier o If the two routes do not have the same Address Family Identifier
(AFI) value, then their respective PTAs MUST contain different (AFI) value, then their respective PTAs MUST contain different
MPLS label values. This ensures that when an egress PE receives a MPLS label values. This ensures that when an egress PE receives a
skipping to change at page 8, line 11 skipping to change at page 9, line 5
o R1's PTA specifies BFR-Prefix B2 and Label L2. o R1's PTA specifies BFR-Prefix B2 and Label L2.
o R2's PTA specifies BFR-Prefix B3 and Label L3. o R2's PTA specifies BFR-Prefix B3 and Label L3.
Suppose B1 decides to propagate both R1 and R2, replacing each PTA Suppose B1 decides to propagate both R1 and R2, replacing each PTA
with a new PTA specifying BIER. Suppose these new PTAs specify with a new PTA specifying BIER. Suppose these new PTAs specify
labels L4 and L5 respectively. Then L4 and L5 MUST be different labels L4 and L5 respectively. Then L4 and L5 MUST be different
(upstream-assigned) label values, UNLESS both of the following (upstream-assigned) label values, UNLESS both of the following
conditions hold: conditions hold:
o R1 and R2 have the same value in the "originating router" field of o R1 and R2 have the same value in the Originating Router field of
their respective NLRIs, and their respective NLRIs, and
o B2 is equal to B3, and o B2 is equal to B3, and
o L2 is equal to L3. o L2 is equal to L3.
The segmentation point (B1 in this example) MUST also program its The segmentation point (B1 in this example) MUST also program its
dataplane appropriately. For example, when: dataplane appropriately. For example, when:
o B1 receives a BIER packet for which it is a BFER, and o B1 receives a BIER packet for which it is a BFER, and
skipping to change at page 10, line 45 skipping to change at page 11, line 38
modified here to exclude any x-PMSI A-D route that does not have a modified here to exclude any x-PMSI A-D route that does not have a
PTA, or whose PTA specifies "no tunnel type". PTA, or whose PTA specifies "no tunnel type".
If such a route is found, we refer to it as the "matching x-PMSI If such a route is found, we refer to it as the "matching x-PMSI
A-D route." A-D route."
If no matching x-PMSI A-D route for (C-S,C-G) is found, the egress PE If no matching x-PMSI A-D route for (C-S,C-G) is found, the egress PE
cannot receive the (C-S,C-G) flow from the ingress PE via BIER until cannot receive the (C-S,C-G) flow from the ingress PE via BIER until
such time as a matching route is received. such time as a matching route is received.
When an egress PE determines that it needs to receive a (C-S,C-) flow When an egress PE determines that it needs to receive a (C-S,C-G)
from a particular ingress PE via BIER, it originates a Leaf A-D flow from a particular ingress PE via BIER, it originates a Leaf A-D
route. Construction of the Leaf A-D route generally follows the route. Construction of the Leaf A-D route generally follows the
procedures specified in [RFC6514], or optionally, the procedures procedures specified in [RFC6514], or optionally, the procedures
specified in [EXPLICIT_TRACKING]. However, when BIER is being used, specified in [EXPLICIT_TRACKING]. However, when BIER is being used,
the Leaf A-D route MUST carry a PTA that is constructed as follows: the Leaf A-D route MUST carry a PTA that is constructed as follows:
1. The tunnel type MUST be set to "BIER". 1. The tunnel type MUST be set to "BIER".
2. The MPLS label field SHOULD be set to zero. 2. The MPLS Label field SHOULD be set to zero.
3. The sub-domain-id field of the Tunnel Identifier field (as 3. The Sub-domain-id subfield of the Tunnel Identifier field (as
defined in Section 2) MUST be set to the corresponding value from defined in Section 2) MUST be set to the corresponding value from
the PTA of the matching x-PMSI A-D route. the PTA of the matching x-PMSI A-D route.
4. The BFR-Prefix field of the Tunnel Identifier field (as defined 4. The BFR-id subfield of the Tunnel Identifier field MUST be set to
in Section 2) MUST be set to the egress PE's BFR-Prefix in the the BFR-id, in the sub-domain identified by the sub-domain-id
sub-domain identifiers in the PTA of the matching x-PMSI A-D subfield, of the egress PE.
route.
5. The BFR-Prefix field of the Tunnel Identifier field (as defined
in Section 2) MUST be set to the egress PE's BFR-Prefix.
The BFR-Prefix need not be the same IP address that is carried in The BFR-Prefix need not be the same IP address that is carried in
any other field of the Leaf A-D route. any other field of the Leaf A-D route.
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.
skipping to change at page 12, line 41 skipping to change at page 13, line 33
procedures of [BIER_ARCH] and [BIER_ENCAPS]. (See especially procedures of [BIER_ARCH] and [BIER_ENCAPS]. (See especially
Section 4, "Imposing and Processing the BIER Encapsulation", of Section 4, "Imposing and Processing the BIER Encapsulation", of
[BIER_ENCAPS].) [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 BFR-prefix corresponding to the sub-domain-id and BFIR-id in o The sub-domain-id and the BFIR-id from the BIER header. (As the
the BIER header. sub-domain-id is inferred from the BIFT-id field of the BIER
header, an implementation might choose to pass the BIFT-id rather
than the sub-domain-id; this is an implementation matter.)
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. In the dataplane, the BFIR-id and the
which the upstream-assigned label is interpreted. sub-domain-id provide the context in which the upstream-assigned
label is interpreted.
Note that per [RFC5331], the context for an upstream-assigned
label is the IP address of the label assigner, which in this case
is the BFR-prefix of the BFIR.
By looking up the upstream-assigned label in the appropriate context, By looking up the upstream-assigned label in the appropriate context,
the multicast flow overlay determines whether the BFER is an egress the multicast flow overlay determines whether the BFER is an egress
PE for the packet. PE for the packet.
Note that if segmented P-tunnels are in use, a BFER might be a 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 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 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 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 need to follow the procedures of Section 4.2.1, the procedures of
skipping to change at page 14, line 13 skipping to change at page 14, line 47
Email: ice@cisco.com Email: ice@cisco.com
6. Acknowledgments 6. 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. 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 is requested to assign a value for "BIER" from the "P-Multicast IANA has assigned the codepoint 0x0B to "BIER" in the "P-Multicast
Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry.
reference should be this document.
8. Security Considerations 8. Security Considerations
The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513] The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513]
and [RFC6514] are applicable. and [RFC6514] are applicable.
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 14, line 41 skipping to change at page 15, line 29
[BIER_ENCAPS] [BIER_ENCAPS]
Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and
S. Aldrin, "Encapsulation for Bit Index Explicit S. Aldrin, "Encapsulation for Bit Index Explicit
Replication in MPLS Networks", internet-draft draft-ietf- Replication in MPLS Networks", internet-draft draft-ietf-
bier-mpls-encapsulation-07.txt, June 2017. 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,
<http://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, <http://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
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008, RFC 5331, DOI 10.17487/RFC5331, August 2008,
<http://www.rfc-editor.org/info/rfc5331>. <https://www.rfc-editor.org/info/rfc5331>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc6625>. <https://www.rfc-editor.org/info/rfc6625>.
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
Point-to-Multipoint (P2MP) Segmented Label Switched Paths Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<http://www.rfc-editor.org/info/rfc7524>. <https://www.rfc-editor.org/info/rfc7524>.
[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
RFC 7900, DOI 10.17487/RFC7900, June 2016, RFC 7900, DOI 10.17487/RFC7900, June 2016,
<http://www.rfc-editor.org/info/rfc7900>. <https://www.rfc-editor.org/info/rfc7900>.
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 16, line 19 skipping to change at page 17, line 4
Email: masivaku@cisco.com Email: masivaku@cisco.com
Sam K Aldrin Sam K Aldrin
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, California Mountain View, California
United States United States
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Andrew Dolganow Andrew Dolganow
Nokia Nokia
600 March Rd. 438B Alexandra Rd #08-07/10
Ottawa, Ontario K2K 2E6 Alexandra Technopark
Canada Singapore 119968
Email: andrew.dolganow@nokia.com Email: andrew.dolganow@nokia.com
Tony Przygienda Tony Przygienda
Juniper Networks, Inc. Juniper Networks, Inc.
1137 Innovation Way 1137 Innovation Way
San Jose, California 94089 San Jose, California 94089
United States United States
Email: prz@juniper.net Email: prz@juniper.net
 End of changes. 34 change blocks. 
66 lines changed or deleted 94 lines changed or added

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