draft-ietf-bier-mvpn-08.txt   draft-ietf-bier-mvpn-09.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: April 19, 2018 Cisco Systems, Inc. Expires: May 17, 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.
October 16, 2017 November 13, 2017
Multicast VPN Using BIER Multicast VPN Using BIER
draft-ietf-bier-mvpn-08 draft-ietf-bier-mvpn-09
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 April 19, 2018. This Internet-Draft will expire on May 17, 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
(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
skipping to change at page 5, line 50 skipping to change at page 5, line 50
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 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 [BIER_ARCH]) 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.
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
skipping to change at page 7, line 14 skipping to change at page 7, line 14
+---------------------------------+ +---------------------------------+
| Flags (1 octet) | | Flags (1 octet) |
+---------------------------------+ +---------------------------------+
| Tunnel Type = 0x0B (1 octet) | | Tunnel Type = 0x0B (1 octet) |
+---------------------------------+ +---------------------------------+
| MPLS Label (3 octets) | | MPLS Label (3 octets) |
+---------------------------------+ +---------------------------------+
| Sub-domain-id (1 octet) | <--- | Sub-domain-id (1 octet) | <---
+---------------------------------+ | +---------------------------------+ |
| BFIR-id (2 octets) | |-- Tunnel | BFR-id (2 octets) | |-- Tunnel
+---------------------------------+ | Identifier +---------------------------------+ | Identifier
| BFIR-Prefix (4 or 16 octets) | <--- | BFR-prefix (4 or 16 octets) | <---
+---------------------------------+ +---------------------------------+
Figure 1: PMSI Tunnel Attribute for BIER 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. The MPLS Label carried in the PTA is an upstream-assigned label.
If two PTAs contain the same BFR-prefix in their respective Tunnel If two PTAs contain the same BFR-prefix in their respective Tunnel
skipping to change at page 8, line 35 skipping to change at page 8, line 35
also Section 4. also Section 4.
When segmented P-tunnels are being used, a segmentation point, call When segmented P-tunnels are being used, a segmentation point, call
it "B1", may receive, from within a given BIER domain, an x-PMSI A-D it "B1", may receive, from within a given BIER domain, an x-PMSI A-D
route whose PTA specifies "BIER". This means that BIER is being used route whose PTA specifies "BIER". This means that BIER is being used
for the previous segment of a segmented P-tunnel. If the next for the previous segment of a segmented P-tunnel. If the next
segment is also of type "BIER", B1 will be the BFIR for the next segment is also of type "BIER", B1 will be the BFIR for the next
segment. That is, B1 is a BFER of one BIER domain (corresponding to segment. That is, B1 is a BFER of one BIER domain (corresponding to
the previous segment), and a BFIR of another BIER domain the previous segment), and a BFIR of another BIER domain
(corresponding to the next segment). B1 needs to replace the PTA of (corresponding to the next segment). B1 needs to replace the PTA of
the x-PMSI A-D route with a new PTA, specifying its own BFR-Prefix, the x-PMSI A-D route with a new PTA, specifying its own BFR-prefix,
and specifying an upstream-assigned label assigned by B1 itself. and specifying an upstream-assigned label assigned by B1 itself.
Suppose B1 has received two x-PMSI A-D routes, R1 and R2, where: Suppose B1 has received two x-PMSI A-D routes, R1 and R2, where:
o R1 and R2 each have a PTA specifying BIER, o R1 and R2 each have a PTA specifying BIER,
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
skipping to change at page 9, line 25 skipping to change at page 9, line 25
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
o the BIER header specifies the BFIR-id that corresponds to B2,and o the BIER header specifies the BFIR-id that corresponds to B2,and
o the BIER payload is an MPLS packet with upstream-assigned label, o the BIER payload is an MPLS packet with upstream-assigned label,
and and
o the top label value is L2, o the top label value is L2,
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 BFIR-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 [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 can be done in either of two ways: delivered. This can be done in either of two ways:
skipping to change at page 12, line 7 skipping to change at page 12, line 7
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 subfield 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-id subfield of the Tunnel Identifier field MUST be set to 4. The BFR-id subfield of the Tunnel Identifier field MUST be set to
the BFR-id, in the sub-domain identified by the sub-domain-id the BFR-id, in the sub-domain identified by the sub-domain-id
subfield, of the egress PE. subfield, of the egress PE (BFER).
5. The BFR-Prefix field of the Tunnel Identifier field (as defined 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. in Section 2) MUST be set to the egress PE's (BFER'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.
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 [BIER_ARCH].
skipping to change at page 13, line 14 skipping to change at page 13, line 14
2. The S-PMSI A-D route that is the match for transmission carries a 2. The S-PMSI A-D route that is the match for transmission carries a
PTA that has the LIR-pF flag. PTA that has the LIR-pF flag.
In this case, the corresponding Leaf A-D routes are those whose 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 key" field is derived from the NLRI of the S-PMSI A-D
route according to the procedures described in Section 5.2 of route according to the procedures described in Section 5.2 of
[EXPLICIT_TRACKING]. [EXPLICIT_TRACKING].
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 [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
 End of changes. 18 change blocks. 
20 lines changed or deleted 20 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/