< draft-ietf-bier-mvpn-05.txt   draft-ietf-bier-mvpn-06.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: Experimental M. Sivakumar
Expires: July 14, 2017 Cisco Systems, Inc. Expires: December 29, 2017 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.
January 10, 2017 June 27, 2017
Multicast VPN Using BIER Multicast VPN Using BIER
draft-ietf-bier-mvpn-05 draft-ietf-bier-mvpn-06
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 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 July 14, 2017. This Internet-Draft will expire on December 29, 2017.
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 (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 in x-PMSI A-D Routes . . . . 5
2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 7 2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 7 2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 8
2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 7 2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 8
3. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Use of the PMSI Tunnel Attribute in Leaf A-D routes . . . . . 9
3.1. Encapsulation and Transmission . . . . . . . . . . . . . 8 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Encapsulation and Transmission . . . . . . . . . . . . . 10
3.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 10 4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 10 4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 12
4. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 10 4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 12
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 35 skipping to change at page 3, line 35
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 [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.
This revision of the document does not specify the procedures Procedures to support MVPN customers who are using BIDIR-PIM are
necessary to support MVPN customers that are using BIDIR-PIM. Those outside the scope of this document.
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.
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
which multicast service is offered. which multicast service is offered.
o P-tunnel. A multicast tunnel through the network of one or more o P-tunnel. A multicast tunnel through the network of one or more
SPs. P-tunnels are used to transport MVPN multicast data SPs. P-tunnels are used to transport MVPN multicast data
o PMSI: Provider Multicast Service Interface. PMSI is an
abstraction that represents a multicast service for carrying
packets. A PMSI is instantiated via one or more P-tunnels.
o C-S: A multicast source address, identifying a multicast source o C-S: A multicast source address, identifying a multicast source
located at a VPN customer site. located at a VPN customer site.
o C-G: A multicast group address used by a VPN customer. o C-G: A multicast group address used by a VPN customer.
o C-flow: A customer multicast flow. Each C-flow is identified by o C-flow: A customer multicast flow. Each C-flow is identified by
the ordered pair (source address, group address), where each the ordered pair (source address, group address), where each
address is in the customer's address space. The identifier of a address is in the customer's address space. The identifier of a
particular C-flow is usually written as (C-S,C-G). particular C-flow is usually written as (C-S,C-G).
Sets of C-flows can be identified by the use of the "C-*" wildcard Sets of C-flows can be identified by the use of the "C-*" wildcard
(see [RFC6625]), e.g., (C-*,C-G). (see [RFC6625]), e.g., (C-*,C-G).
o I-PMSI A-D Route: Inclusive Provider Multicast Service Interface o I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route. Carried in
Auto-Discovery route. Carried in BGP Update messages, these BGP Update messages, these routes are used to advertise the
routes are used to advertise the "default" P-tunnel for a "default" P-tunnel for a particular MVPN.
particular MVPN.
o S-PMSI A-D route: Selective Provider Multicast Service Interface o S-PMSI A-D route: Selective PMSI Auto-Discovery route. Carried in
Auto-Discovery route. Carried in BGP Update messages, these BGP Update messages, these routes are used to advertise the fact
routes are used to advertise the fact that particular C-flows are that particular C-flows are bound to (i.e., are traveling through)
bound to (i.e., are traveling through) particular P-tunnels. particular P-tunnels.
o PMSI Tunnel attribute (PTA). This BGP attribute carried is used o x-PMSI A-D route: a route that is either an I-PMSI A-D route or an
to identify a particular P-tunnel. When C-flows of multiple VPNs S-PMSI A-D route.
is carried in a single P-tunnel, this attribute also carries the
information needed to multiplex and demultiplex the C-flows. o Leaf A-D route: a route that a multicast egress node sends in
order to join a particular P-tunnel.
o PMSI Tunnel attribute (PTA). In an x-PMSI A-D route, the NLRI of
the route identifies a PMSI. The BGP attribute known as the PMSI
Tunnel attribute is attached to such a route in order to identify
a particular P-tunnel that is associated with the PMSI. When
C-flows of multiple VPNs are carried in a single P-tunnel, this
attribute also carries the information needed to multiplex and
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
order for the originator of the route to join the specified
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Use of the PMSI Tunnel Attribute 2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes
As defined in [RFC6514], the PMSI Tunnel attribute is used to As defined in [RFC6514], the PMSI Tunnel attribute (PTA) is used to
identify the particular P-tunnel to which one or more multicast flows identify the P-tunnel that is used to instantiate a particular PMSI.
are being assigned. If a PMSI is to be instantiated by BIER, the PTA is constructed as
follows.
The PMSI Tunnel attribute (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 is requested to assign a new tunnel type
codepoint for "BIER". This codepoint will be used to indicate codepoint for "BIER" from the "P-Multicast Service Interface
that the PMSI is instantiated by BIER. Tunnel (PMSI Tunnel) Tunnel Types" registry. This codepoint will
be used to indicate that the PMSI is instantiated by BIER.
(Although BIER does not actually create tunnels, the MVPN
procedures treat BIER as if it were a type of tunnel.)
o "Tunnel Identifier". When the "tunnel type" field is "BIER", this o "Tunnel Identifier". When the "tunnel type" is "BIER", this field
field contains two subfields: contains two subfields:
1. The first subfield is a single octet, containing the sub- 1. The first subfield is a single octet, containing a BIER sub-
domain-id of the sub-domain to which the BFIR will assign the domain-id. (See [BIER_ARCH].) This indicates that packets
packets that it transmits on the PMSI identified by the NLRI sent on the PMSI will be sent on the specified BIER sub-
of the BGP I-PMSI or S-PMSI A-D route that contains this PTA. domain. How that sub-domain is chosen is outside the scope of
(How that sub-domain is chosen is outside the scope of this this document.
document.)
2. The second subfield is the BFR-Prefix (see [BIER_ARCH]) of the 2. The second subfield is the BFR-Prefix (see [BIER_ARCH]) of the
originator of the route that is carrying this PTA. This will originator of the route that is carrying this PTA. This must
either be a /32 IPv4 address or a /128 IPv6 address. Whether be the originator's BFR-prefix in the specified sub-domain.
the address is IPv4 or IPv6 can be inferred from the total The BFR-Prefix will either be a /32 IPv4 address or a /128
length of the PMSI Tunnel attribute. IPv6 address. Whether the address is IPv4 or IPv6 can be
inferred from the total length of the PMSI Tunnel attribute.
o "MPLS label". This field contains an upstream-assigned MPLS The BFR-Prefix need not be the same IP address that is carried
in any other field of the x-PMSI A-D route.
Failure to properly set the Tunnel Identifier field cannot be
detected by the protocol, and will result in improper delivery of
the data packets sent on the PMSI.
o "MPLS label". This field MUST contain 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 in
Section 2.1.
Failure to follow the constraints on label assignment cannot be
detected by the protocol, and may result in improper handling of
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
flags can be found in Section 2.2. flags can be found in Section 2.2.
* "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 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.
Note that if a PTA specifying "BIER" is attached to an I-PMSI or If a PTA specifying tunnel type "BIER" is attached to an x-PMSI A-D
S-PMSI A-D route, the route MUST NOT be distributed beyond the route, the route MUST NOT be distributed beyond the boundaries of a
boundaries of a BIER domain. That is, any routers that receive the BIER domain. That is, any routers that receive the route must be in
route must be in the same BIER domain as the originator of the route. the same BIER domain as the originator of the route. If the
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. Route Targets. Thus the requirement expressed in this paragraph is
really a requirement on the way the Route Targets are provisioned.
2.1. MPLS Label 2.1. MPLS Label
Suppose an ingress PE originates two x-PMSI A-D routes, where we use Suppose an ingress PE originates two x-PMSI A-D routes. Suppose each
the term "x-PMSI" to mean "I-PMSI or S-PMSI". Suppose both routes route carries a PTA, and the PTA of each route specifies a tunnel
carry a PTA, and the PTA of each route specifies"BIER". 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
(AFI) value, then their respective PTAs MUST contain different
MPLS label values. This ensures that when an egress PE receives a
data packet with the given label, the egress PE can infer from the
label whether the payload is an IPv4 packet or an IPv6 packet.
o If the ingress PE is supporting MVPN extranet ([RFC7900]) o If the ingress PE is supporting MVPN extranet ([RFC7900])
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 [RFC7900], section ), and if of MVPN extranet (see Section 7.3 of [RFC7900], 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 o If segmented P-tunnels are being used, then the respective PTAs of
the two routes MUST contain different MPLS label values, as long the two routes MUST contain different MPLS label values, as long
as the NLRIs are not identical. In this case, the MPLS label can 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 be used by the BFER to identify the particular C-flow to which a
data packet belongs, and this greatly simplifies the process of data packet belongs, and this greatly simplifies the process of
forwarding a received packet to its next P-tunnel segment. This forwarding a received packet to its next P-tunnel segment. This
is explained further below. See also Section 3. is explained further below. See also 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 R4 respectively, where the PTAs of each of the four routes specify
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
skipping to change at page 7, line 16 skipping to change at page 8, line 5
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:
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 explicit tracking mechanism based on the LIR-pF flag 2. Using the OPTIONAL explicit tracking mechanism based on the LIR-
specified in [EXPLICIT_TRACKING]. This method, further described pF flag specified in [EXPLICIT_TRACKING]. This method, further
in Section 2.2.2, may be used if (and only if) segmented described in Section 2.2.2, may be used if (and only if)
P-tunnels are not being used. segmented P-tunnels are not being used.
2.2.1. Using the LIR Flag 2.2.1. Using the LIR Flag
To determine the set of BFERs to which the packets of a given C-flow To determine the set of BFERs to which the packets of a given C-flow
must be sent, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for must be sent, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for
the given C-flow. It MUST attach a PTA to that route, and MUST set the given C-flow. It MUST attach a PTA to that route, and MUST set
the LIR flag in the PTA. Per [RFC6514], the BFERs that need to the LIR flag in the PTA. Per [RFC6514], the BFERs that need to
receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By
matching the received Leaf A-D routes to the originated S-PMSI A-D matching the received Leaf A-D routes to the originated S-PMSI A-D
routes, the originator of the S-PMSI A-D route determines the set of routes, the originator of the S-PMSI A-D route determines the set of
BFERs that need to receive the multicast data flow that is identified BFERs that need to receive the multicast data flow that is identified
in the NLRI of S-PMSI A-D route. in the NLRI of S-PMSI A-D route.
The PTA MAY specify a tunnel type ("BIER") and a non-zero MPLS label. Suppose an ingress PE has originated an I-PMSI A-D route or a
(If it specifies one of these it MUST also specify the other.) wildcard S-PMSI A-D route [RFC6625] with a PTA specifying a tunnel
Alternatively, the PTA MAY specify "no tunnel type" and a zero MPLS type of BIER. Now suppose the ingress PE originates an S-PMSI A-D
label. In this case, the tunnel type ("BIER") and non-zero MPLS route specifying (C-S, C-G), where (C-S, C-G) "matches" (according to
label MUST be specified in an I-PMSI A-D route or in a wildcard the rules of [RFC6625]) the wildcard S-PMSI A-D route or the I-PMSI
S-PMSI A-D route that "matches" (according to the rules of [RFC6625]) A-D route. Instead of attaching to the (C-S, C-G) route a PTA
the C-flow in question. specifying BIER, the ingress PE MAY attach a PTA specifying a tunnel
type of "no tunnel information". This is equivalent to attaching the
same PTA attached to the matching "less specific" route.
2.2.2. Using the LIR-pF Flag 2.2.2. Using the LIR-pF Flag
If segmented P-tunnels are not being used, the BFIR can determine the If segmented P-tunnels are not being used, the BFIR can determine the
set of BFERs that need to receive the packets of a given (C-S,C-G) set of BFERs that need to receive the packets of a given (C-S,C-G)
C-flow as follows. The BFIR MUST originate a wildcard S-PMSI A-D C-flow as follows. The BFIR MUST originate a wildcard S-PMSI A-D
route (either (C-*,C-*), (C-*,C-G), or (C-S,C-G) and the PTA of that route (either (C-*,C-*), (C-*,C-G), or (C-S,C-G)) and the PTA of that
route MUST the following settings: route MUST the following settings:
o The LIR-pF flag MUST be set; o The LIR-pF flag MUST be set;
o The tunnel type MUST be set to "BIER; o The tunnel type MUST be set to "BIER";
o A non-zero MPLS label MUST be specified. o A non-zero MPLS label MUST be specified.
Per [EXPLICIT_TRACKING], a BFER that needs to receive (C-S,C-G) Per [EXPLICIT_TRACKING], a BFER that needs to receive (C-S,C-G)
traffic from the BFIR will respond with a Leaf A-D route. traffic from the BFIR will respond with a Leaf A-D route.
A BFIR MUST NOT use this method of finding the set of BFERs needing 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 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 support the LIR-pF flag. How this is known is outside the scope of
this document. this document.
This method greatly reduces the number of S-PMSI A-D routes that a This method greatly reduces the number of S-PMSI A-D routes that a
BFIR needs to originate; it can now originate as few as one such BFIR needs to originate; it can now originate as few as one such
route (a (C-*,C-*) S-PMSI A-D route), rather than one for each route (a (C-*,C-*) S-PMSI A-D route), rather than one for each
C-flow. However, the method does not provide a way for the BFIR to C-flow. However, the method does not provide a way for the BFIR to
assign a distinct label to each C-flow. Therefore it cannot be used assign a distinct label to each C-flow. Therefore it cannot be used
when segmented P-tunnels are in use (see Section 3 for an when segmented P-tunnels are in use (see Section 4 for an
explanation). explanation).
Note: if a BFIR originates a (C-*,C-*) S-PMSI A-D route with the LIR- Note: if a BFIR originates a (C-*,C-*) S-PMSI A-D route with the LIR-
pF flag set, but also originates a more specific wildcard route that pF flag set, but also originates a more specific wildcard route that
matches a particular (C-S,C-G), the BFERs will not originate Leaf A-D matches a particular (C-S,C-G), the BFERs will not originate Leaf A-D
routes for that (C-S,C-G) unless the LIR-pF flag is also set in the routes for that (C-S,C-G) unless the LIR-pF flag is also set in the
more specific wildcard route. If the BFIR also originates a more specific wildcard route. If the BFIR also originates a
(C-S,C-G) S-PMSI A-D route without the LIR flag set, the BFERs will (C-S,C-G) S-PMSI A-D route without the LIR flag set, the BFERs will
not originate Leaf A-D routes for that (C-S,C-G) unless the LIR flag not originate Leaf A-D routes for that (C-S,C-G) unless the LIR flag
is also set in that route. is also set in that route.
3. Data Plane 3. Use of the PMSI Tunnel Attribute in Leaf A-D routes
Before an egress PE can receive a (C-S,C-G) flow from a given ingress
PE via BIER, the egress PE must have received one of the following
x-PMSI A-D routes from the ingress PE:
o A (C-S,C-G) S-PMSI A-D route (i.e., an S-PMSI A-D route whose NLRI
encodes (C-S,C-G) and whose PTA specifies a tunnel type of "BIER".
If such a route is found, we refer to it as the "matching x-PMSI
A-D route."
o A "less specific" x-PMSI A-D route (one specifying (C-*,C-*),
(C-*,C-G), or (C-S,C-G)) whose PTA specifies a tunnel type of
"BIER", and that is the egress PE's "match for reception" of
(C-S,C-G).
The rules for determining which x-PMSI A-D route is the match for
reception are given in [RFC6625]. However, these rules are
modified here to exclude any x-PMSI A-D route that does not have a
PTA, or whose PTA specifies "no tunnel type".
If such a route is found, we refer to it as the "matching x-PMSI
A-D route."
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.
When an egress PE determines that it needs to receive a (C-S,C-G)
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
procedures specified in [RFC6514], or optionally, the procedures
specified in [EXPLICIT_TRACKING]. However, when BIER is being used,
the Leaf A-D route MUST carry a PTA that is constructed as follows:
1. The tunnel type MUST be set to "BIER".
2. The MPLS label field SHOULD be set to zero.
3. The sub-domain-id field of the Tunnel Identifier field (as
defined in Section 2) MUST be set to the corresponding value from
the PTA of the matching x-PMSI A-D route.
4. 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 the
sub-domain identifiers in the PTA of the matching x-PMSI A-D
route.
The BFR-Prefix need not be the same IP address that is carried in
any other field of the Leaf A-D route.
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 make
any use the value of the PTA's MPLS label field.
Failure to properly construct the PTA cannot always be detected by
the protocol, and will cause improper delivery of the data packets.
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].
3.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 S-PMSI A-D route or I-PMSI A-D route that is a [RFC6625] to find the x-PMSI A-D route that is a "match for
"match for transmission" for that packet. (In applying the rules of transmission" for that packet. (In applying the rules of [RFC6625],
[RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel any S-PMSI A-D route with a PTA specifying "no tunnel information" is
information" is ignored.) If the matching route has a PTA specifying ignored.) If the matching route has a PTA specifying "BIER", the
"BIER", the (upstream-assigned) MPLS label from that PTA is pushed on (upstream-assigned) MPLS label from that PTA is pushed on the
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 and forwarded, according to the procedures of [BIER_ARCH] and header. That is, the ingress PE functions as a BFIR. The BIER sub-
[BIER_ENCAPS]. (See especially Section 4, "Imposing and Processing domain used for transmitting the packet is specified in the PTA of
the BIER Encapsulation", of [BIER_ENCAPS].) 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 9, line 23 skipping to change at page 11, line 23
route. route.
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].
3.2. Disposition 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
construct the BIER BitString.
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
packet, the bit for that BFER cannot be determined, and that BFER
will not receive the packet.
The BIER-encapsulated packet is then forwarded, according to the
procedures of [BIER_ARCH] and [BIER_ENCAPS]. (See especially
Section 4, "Imposing and Processing the BIER Encapsulation", of
[BIER_ENCAPS].)
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 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
skipping to change at page 9, line 48 skipping to change at page 12, line 17
is the BFR-prefix of the BFIR. 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 3.2.1, the procedures of need to follow the procedures of Section 4.2.1, the procedures of
Section 3.2.2, or both. Section 4.2.2, or both.
3.2.1. At a BFER that is an Egress PE 4.2.1. At a BFER that is an Egress PE
From looking up the packet's upstream-assigned label in the context From looking up the packet's upstream-assigned label in the context
of the packet's BFIR-prefix, the egress PE determines the egress VRF of the packet's BFIR-prefix, the egress PE determines the egress VRF
for the packet. From the IP header of the payload, the multicast for the packet. From the IP header of the payload, the multicast
states of the VRF, the upstream-assigned label, and the BFR-prefix, states of the VRF, the upstream-assigned label, and the BFR-prefix,
the egress PE can determine whether the packet needs to be forwarded the egress PE can determine whether the packet needs to be forwarded
out one or more VRF interfaces. out one or more VRF interfaces.
3.2.2. At a BFER that is a P-tunnel Segmentation Boundary 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- When segmented P-tunnels are being used, a BFER that receives a BIER-
encapsulated MVPN multicast data packet may need to be forwarded on encapsulated MVPN multicast data packet may need to be forwarded on
its next P-tunnel segment. The choice of the next P-tunnel segment 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. for the packet depends upon the C-flow to which the packet belongs.
As long as the BFIR has assigned the MPLS label according to the As long as the BFIR has assigned the MPLS label according to the
constraints specified in Section 2.1, the BFIR will have assigned constraints specified in Section 2.1, the BFIR will have assigned
distinct upstream-assigned MPLS labels to distinct C-flows. The BFER distinct upstream-assigned MPLS labels to distinct C-flows. The BFER
can thus select the proper "next P-tunnel segment" for a given packet can thus select the proper "next P-tunnel segment" for a given packet
simply by looking up the upstream-assigned label that immediately simply by looking up the upstream-assigned label that immediately
follows the BIER header. follows the BIER header.
4. Contributor Addresses 5. Contributor Addresses
Below is a list of other contributing authors in alphabetical order: Below is a list of other contributing authors in alphabetical order:
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
5. 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. contributions to this work. We also thank Stig Venaas for his review
and comments.
6. IANA Considerations 7. 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.
7. 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.
8. References 9. References
8.1. Normative References 9.1. Normative References
[BIER_ARCH] [BIER_ARCH]
Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T.,
and S. Aldrin, "Multicast using Bit Index Explicit and S. Aldrin, "Multicast using Bit Index Explicit
Replication", internet-draft draft-ietf-bier-architecture- Replication", internet-draft draft-ietf-bier-architecture-
05, October 2016. 07, June 2017.
[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-06.txt, December 2016. 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>. <http://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, <http://www.rfc-editor.org/info/rfc4364>.
skipping to change at page 12, line 5 skipping to change at page 14, line 28
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc6625>.
8.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-01, VPN", internet-draft draft-ietf-bess-mvpn-expl-track-02,
December 2016. 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>. <http://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,
 End of changes. 49 change blocks. 
111 lines changed or deleted 224 lines changed or added

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