draft-ietf-bier-mvpn-11.txt   rfc8556.txt 
Internet Engineering Task Force E. Rosen, Ed. Internet Engineering Task Force (IETF) E. Rosen, Ed.
Internet-Draft Juniper Networks, Inc. Request for Comments: 8556 M. Sivakumar
Intended status: Standards Track M. Sivakumar Category: Standards Track T. Przygienda
Expires: September 20, 2018 Cisco Systems, Inc. ISSN: 2070-1721 Juniper Networks, Inc.
S. Aldrin S. Aldrin
Google, Inc. Google, Inc.
A. Dolganow A. Dolganow
Nokia Nokia
T. Przygienda April 2018
Juniper Networks, Inc.
March 19, 2018
Multicast VPN Using BIER Multicast VPN Using Bit Index Explicit Replication (BIER)
draft-ietf-bier-mvpn-11
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
maintain any per-flow state or to engage in an explicit tree-building maintain any per-flow state or to engage in an explicit tree-building
protocol. This document specifies the protocol and procedures that protocol. This document specifies the protocol and procedures that
allow MVPN to use BIER as the method of carrying multicast traffic allow MVPN to use BIER as the method of carrying multicast traffic
over an SP backbone network. over a service provider's backbone network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 20, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8556.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
skipping to change at page 2, line 22 skipping to change at page 2, line 23
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 9 2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 9 2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 10
2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 10 2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 10
3. Use of the PMSI Tunnel Attribute in Leaf A-D routes . . . . . 11 3. Use of the PMSI Tunnel Attribute in Leaf A-D Routes . . . . . 11
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Encapsulation and Transmission . . . . . . . . . . . . . 12 4.1. Encapsulation and Transmission . . . . . . . . . . . . . 12
4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 14 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 . 14 4.2.2. At a BFER That Is a P-tunnel Segmentation Boundary . 14
5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 17 skipping to change at page 3, line 27
domain", without requiring intermediate routers to maintain any per- domain", without requiring intermediate routers to maintain any per-
flow state or to engage in an explicit tree-building protocol. The flow state or to engage in an explicit tree-building protocol. The
purpose of the current document is to specify the protocols and purpose of the current document is to specify the protocols and
procedures needed in order to provide MVPN service using BIER to procedures needed in order to provide MVPN service using BIER to
transport the multicast traffic over the backbone. transport the multicast traffic over the backbone.
Although BIER does not explicitly build and maintain multicast Although BIER does not explicitly build and maintain multicast
tunnels, one can think of BIER as using a number of implicitly tunnels, one can think of BIER as using a number of implicitly
created tunnels through a "BIER domain". In particular, one can created tunnels through a "BIER domain". In particular, one can
think of there as being one Point-to-Multipoint (P2MP) tunnel from think of there as being one Point-to-Multipoint (P2MP) tunnel from
each "Bit Forwarding Ingress Router" (BFIR) to all the "Bit each Bit Forwarding Ingress Router (BFIR) to all the Bit Forwarding
Forwarding Egress Routers" (BFERs) in the BIER domain, where a BIER Egress Routers (BFERs) in the BIER domain, where a BIER domain is
domain is generally co-extensive with an IGP network. These generally co-extensive with an IGP network. These "tunnels" are not
"tunnels" are not specific to any particular VPN. However, the MVPN specific to any particular VPN. However, the MVPN architecture
architecture provides protocols and procedures that allow the traffic provides protocols and procedures that allow the traffic of multiple
of multiple MVPNs to be aggregated on a single P-tunnel. In this MVPNs to be aggregated on a single P-tunnel. In this document, we
document, we specify how to use these multi-VPN aggregation specify how to use these multi-VPN aggregation procedures to enable
procedures to enable BIER to transport traffic from multiple MVPNs. BIER to transport traffic from multiple MVPNs.
MVPN traffic must sometimes traverse more than one IGP domain, MVPN traffic must sometimes traverse more than one IGP domain,
whereas BIER only carries multicast traffic within a single IGP whereas BIER only carries multicast traffic within a single IGP
domain. However, the MVPN specifications allow P-tunnels to be domain. However, the MVPN specifications allow P-tunnels to be
"segmented", where the segmentation points may either be Autonomous segmented (the concept of MVPN segmentation is defined in [RFC6513]
System Border Routers (ASBRs), as described in [RFC6514], or Area and [RFC6514]), where the segmentation points may either be
Border Routers (ABRs), as described in [RFC7524]. As long as the Autonomous System Border Routers (ASBRs) as described in [RFC6514],
segmentation points are capable of acting as BFIRs and BFERs, BIER or Area Border Routers (ABRs) as described in [RFC7524]. As long as
can be used to provide some or all of the segments of a P-tunnel. the 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.
Procedures to support MVPN customers who are using BIDIR-PIM are Procedures to support MVPN customers who are using Bidirectional PIM
outside the scope of this document. (BIDIR-PIM) are outside the scope of this document.
This document uses the following terminology from [RFC8279]: This document uses the following terminology from [RFC8279]:
o BFR: Bit-Forwarding Router. o BFR: Bit-Forwarding Router.
o BFIR: Bit-Forwarding Ingress Router. o BFIR: Bit-Forwarding Ingress Router.
o BFER: Bit-Forwarding Egress Router. o BFER: Bit-Forwarding Egress Router.
This document uses the following terminology from [RFC6513]: This document uses the following terminology from [RFC6513]:
o MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in o MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in
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 o PMSI: Provider Multicast Service Interface. PMSI is an
abstraction that represents a multicast service for carrying abstraction that represents a multicast service for carrying
packets. A PMSI is instantiated via one or more P-tunnels. 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.
skipping to change at page 4, line 24 skipping to change at page 4, line 40
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 PMSI Auto-Discovery route. Carried in o I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route. Carried in
BGP Update messages, these routes are used to advertise the BGP Update messages, these routes are used to advertise the
"default" P-tunnel for a particular MVPN. default P-tunnel for a particular MVPN.
o S-PMSI A-D route: Selective PMSI Auto-Discovery route. Carried in o S-PMSI A-D route: Selective PMSI Auto-Discovery route. Carried in
BGP Update messages, these routes are used to advertise the fact BGP Update messages, these routes are used to advertise the fact
that particular C-flows are bound to (i.e., are traveling through) that particular C-flows are bound to (i.e., are traveling through)
particular P-tunnels. particular P-tunnels.
o x-PMSI A-D route: a route that is either an I-PMSI A-D route or an o x-PMSI A-D route: A route that is either an I-PMSI A-D route or an
S-PMSI A-D route. S-PMSI A-D route.
o Leaf A-D route: a route that a multicast egress node sends in o Leaf A-D route: A route that a multicast egress node sends in
order to join a particular P-tunnel. order to join a particular P-tunnel.
o PMSI Tunnel attribute (PTA). In an x-PMSI A-D route, the NLRI of o PMSI Tunnel attribute (PTA): In an x-PMSI A-D route, the Network
the route identifies a PMSI. The BGP attribute known as the PMSI Layer Reachability Information (NLRI) of the route identifies a
Tunnel attribute is attached to such a route in order to identify PMSI. The BGP attribute known as the PMSI Tunnel attribute is
a particular P-tunnel that is associated with the PMSI. When attached to such a route in order to identify a particular
C-flows of multiple VPNs are carried in a single P-tunnel, this P-tunnel that is associated with the PMSI. When C-flows of
attribute also carries the information needed to multiplex and multiple VPNs are carried in a single P-tunnel, this attribute
demultiplex the C-flows. A PTA can also be carried by a Leaf A-D also carries the information needed to multiplex and demultiplex
root. In this case, it contains information that is needed in the C-flows. A PTA can also be carried by a Leaf A-D root. In
order for the originator of the route to join the specified this case, it contains information that is needed in order for the
P-tunnel. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes 2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes
As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by
an x-PMSI A-D route identifies the P-tunnel that is used to an x-PMSI A-D route identifies the P-tunnel that is used to
instantiate a particular PMSI. If a PMSI is to be instantiated by instantiate a particular PMSI. If a PMSI is to be instantiated by
BIER, the PTA is constructed by a BFIR. BIER, the PTA is constructed by a BFIR.
If segmented P-tunnels are not being used, the PTA attached to a If segmented P-tunnels are not being used, the PTA attached to a
given x-PMSI A-D route is constructed by the router that originated given x-PMSI A-D route is constructed by the router that originated
the route (typically by the ingress PE), and the PTA is not changed the route (typically by the ingress Provider Edge (PE) router), and
as the route is propagated. the PTA is not changed 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 be replaced, at a x-PMSI A-D route by the route's originator may be replaced at a
segmentation point (a BFER), by a PTA identifying the next segment of segmentation point (a BFER) by a PTA identifying the next segment of
the P-tunnel. If the next segment of the P-tunnel is instantiated by the P-tunnel. If the next segment of the P-tunnel is instantiated by
BIER, the segmentation point serves as the BFIR for that next BIER, the segmentation point serves as the BFIR for that next
segment. segment.
In either case, a PTA is constructed by a BFIR as follows (see In either case, a PTA is constructed by a BFIR as follows (see
Figure 1): Figure 1):
The PTA contains the following fields: The PTA contains the following fields:
o "Tunnel Type". IANA has assigned 0x0B as the tunnel type o Tunnel Type: IANA has assigned 0x0B as the tunnel type codepoint
codepoint for "BIER" in the "P-Multicast Service Interface Tunnel for "BIER" in the "P-Multicast Service Interface Tunnel (PMSI
(PMSI Tunnel) Tunnel Types" registry. This codepoint is used to Tunnel) Tunnel Types" registry. This codepoint is used to
indicate that the PMSI is instantiated by BIER. indicate that the PMSI is instantiated by BIER.
Although BIER does not actually create tunnels, the MVPN Although BIER does not actually create tunnels, the MVPN
procedures treat BIER as if it were a type of tunnel. procedures treat BIER as if it were a type of tunnel.
o "Tunnel Identifier". When the "tunnel type" is "BIER", this field o Tunnel Identifier: When the tunnel type is BIER, this field
contains three subfields: contains three subfields:
1. The first subfield is a single octet, containing a BIER 1. The first subfield is a single octet, containing a BIER
sub-domain-id. (See [RFC8279].) This indicates that packets sub-domain-id (see [RFC8279]). This indicates that packets
sent on the PMSI will be sent on the specified BIER sent on the PMSI will be sent on the specified BIER
sub-domain. How that sub-domain is chosen is outside the sub-domain. How that sub-domain is chosen is outside the
scope of this document. scope of this document.
2. The second subfield is a two-octet field containing the 2. The second subfield is a two-octet field containing the BFR-id
BFR-id, in the sub-domain identified in the first subfield, of in the sub-domain identified in the first subfield of the
the router that is constructing the PTA. router that is constructing the PTA.
3. The third subfield is the BFR-prefix (see [RFC8279]) of the 3. The third subfield is the BFR-prefix (see [RFC8279]) of the
router (a BFIR) that is constructing the PTA. The BFR-prefix router (a BFIR) that is constructing the PTA. The BFR-prefix
will either be a /32 IPv4 address or a /128 IPv6 address. will either be a /32 IPv4 address or a /128 IPv6 address.
Whether the address is IPv4 or IPv6 can be inferred from the Whether the address is IPv4 or IPv6 can be inferred from the
total length of the PTA. total length of the PTA.
The BFR-prefix need not be the same IP address that is carried The BFR-prefix need not be the same IP address that is carried
in any other field of the x-PMSI A-D route, even if the BFIR in any other field of the x-PMSI A-D route, even if the BFIR
is the originating router of the x-PMSI A-D route. is the originating router of the x-PMSI A-D route.
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
zero MPLS label. It is assigned by the router (a BFIR) that MPLS label. It is assigned by the router (a BFIR) that constructs
constructs the PTA. Constraints on the way in which a BFIR the PTA. Constraints on the way in which a BFIR selects this
selects this label are discussed in Section 2.1. 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
PTA Flags field are meaningful. Details about the use of these Flags field are meaningful. Details about the use of these flags
flags can be found in Section 2.2. can be found in Section 2.2.
* "Leaf Info Required per Flow (LIR-pF)". This flag is * Leaf Information Required per Flow (LIR-pF): This flag is
introduced in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this introduced in [RFC8534]. A BFIR SHOULD NOT set this flag
flag UNLESS it knows that all the BFERs in the BIER domain (or UNLESS it knows that all the BFERs in the BIER domain (or at
at least all the BFERs to which it needs to transmit) support least all the BFERs to which it needs to transmit) support this
this flag. (How this is known is outside the scope of 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 Information Required (LIR): see Section 2.2.1.
+---------------------------------+ +---------------------------------+
| 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) | <---
+---------------------------------+ | +---------------------------------+ |
| BFR-id (2 octets) | |-- Tunnel | BFR-id (2 octets) | |-- Tunnel
+---------------------------------+ | Identifier +---------------------------------+ | Identifier
| BFR-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 (RTs). Thus, the requirement expressed in this
really a requirement on the way the Route Targets are provisioned. paragraph is 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
Identifier fields, then the labels carried in those PTAs MUST come Identifier fields, then the labels carried in those PTAs MUST come
from the same label space. (See section 7 of [RFC5331].) An from the same label space (see Section 7 of [RFC5331]). An
implementation may choose to use this fact when setting up the tables implementation may choose to use this fact when setting up the tables
it uses to interpret the upstream-assigned labels. 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 that a BFIR attaches a PTA to each of two x-PMSI A-D routes,
both PTAs specify a tunnel type of "BIER". and 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 RTs, then their
(RTs), then their respective PTAs MUST contain different MPLS 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
data packet with the given label, the egress PE can infer from the 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. label whether the payload is an IPv4 packet or an IPv6 packet.
o If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900]) o If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900])
functionality, and if the two routes originate from different VRFs functionality, and if the two routes originate from different VPN
on this ingress PE, then the respective PTAs of the two routes Routing and Forwarding tables (VRFs) on this ingress PE, then the
MUST contain different MPLS label values. respective PTAs of the two routes MUST contain different MPLS
label values.
o If the BFIR is an ingress PE supporting the "Extranet Separation" o If the BFIR is an ingress PE supporting the "Extranet Separation"
feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if
one of the routes carries the "Extranet Separation" extended one of the routes carries the "Extranet Separation" extended
community but the other does not, then the respective PTAs of the community but 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 whenever the two routes MUST contain different MPLS label values whenever
the respective NLRIs of the two routes are not identical. The the respective NLRIs of the two routes are not identical. The
MPLS label can then be used at the next segmentation point to MPLS label can then be used at the next segmentation point to
switch packets from one P-tunnel segment directly to the next, switch packets from one P-tunnel segment directly to the next,
without requiring the segmentation points to contain any other without requiring the segmentation points to contain any other
multicast forwarding state. This is explained further below. See multicast forwarding state. This is explained further below; see
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 an x-PMSI A-D route whose PTA specifies BIER
route whose PTA specifies "BIER". This means that BIER is being used from within a given BIER domain. 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 that 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
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: data plane 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
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 data plane must be programmed to replace L2 with L4 and to
reencapsulate the packet in a BIER header, with B1's BFR-id in the re-encapsulate 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 applying the procedures for MVPN explicit tracking (see Section 2.2)
domain of the next segment. in the BIER domain of the next segment, i.e., in the BIER domain for
which B1 is the BFIR).
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 [RFC8279]). The BFIR domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR
must determine the set of BFERs to which the packet needs to be must determine the set of BFERs to which the packet needs to be
delivered. This can be done in either of two ways: delivered. This can be done in either of two ways:
1. Using the explicit tracking mechanism based on the "Leaf Info 1. Using the explicit tracking mechanism based on the "Leaf
Required" flag specified in [RFC6513] and [RFC6514]. This method Information Required" flag specified in [RFC6513] and [RFC6514].
is further described in Section 2.2.1. This method is further described in Section 2.2.1.
2. Using the OPTIONAL explicit tracking mechanism based on the 2. Using the OPTIONAL explicit tracking mechanism based on the
LIR-pF flag specified in [EXPLICIT_TRACKING]. This method, LIR-pF flag specified in [RFC8534]. This method, further
further described in Section 2.2.2, may be used if (and only if) described in Section 2.2.2, may be used if (and only if)
segmented P-tunnels are not being used. segmented P-tunnels are not being used.
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 Leaf Information Required (LIR) flag in the PTA. Per [RFC6514],
receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By the BFERs that need to receive that C-flow will respond with
matching the received Leaf A-D routes to the originated S-PMSI A-D (C-S,C-G) Leaf A-D routes. By matching the received Leaf A-D routes
routes, the originator of the S-PMSI A-D route determines the set of to the originated S-PMSI A-D routes, the originator of the S-PMSI A-D
BFERs that need to receive the multicast data flow that is identified route determines the set of BFERs that need to receive the multicast
in the NLRI of S-PMSI A-D route. data flow that is identified in the NLRI of S-PMSI A-D route.
Suppose an ingress PE has originated an I-PMSI A-D route or a Suppose that an ingress PE has originated an I-PMSI A-D route or a
wildcard S-PMSI A-D route [RFC6625] with a PTA specifying a tunnel wildcard S-PMSI A-D route [RFC6625] with a PTA specifying a tunnel
type of BIER. Now suppose the ingress PE originates an S-PMSI A-D type of BIER. Now suppose that the ingress PE originates an S-PMSI
route specifying (C-S, C-G), where (C-S, C-G) "matches" (according to A-D route specifying (C-S,C-G), where (C-S,C-G) "matches" (according
the rules of [RFC6625]) the wildcard S-PMSI A-D route or the I-PMSI to the rules of [RFC6625]) the wildcard S-PMSI A-D route or the
A-D route. Instead of attaching to the (C-S, C-G) route a PTA I-PMSI A-D route. Instead of attaching a PTA specifying BIER to the
specifying BIER, the ingress PE MAY attach a PTA specifying a tunnel (C-S,C-G) route, the ingress PE MAY attach a PTA specifying a tunnel
type of "no tunnel information". This is equivalent to attaching the type of "no tunnel information". This is equivalent to attaching the
same PTA attached to the matching "less specific" route. 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
route MUST the following settings: that route MUST use 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 [RFC8534], a BFER that needs to receive (C-S,C-G) traffic from
traffic from the BFIR will respond with a Leaf A-D route. 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 4 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 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 LIR-pF flag set but also originates a more specific wildcard route
that matches a particular (C-S,C-G), the BFERs will not originate that 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 Leaf A-D 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 in the 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. Use of the PMSI Tunnel Attribute in Leaf A-D routes 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 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 PE via BIER, the egress PE must have received one of the following
x-PMSI A-D routes from the ingress PE: 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 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". 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 If such a route is found, we refer to it as the "matching x-PMSI
A-D route." A-D route."
o A "less specific" x-PMSI A-D route (one specifying (C-*,C-*), 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 (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 BIER, and that is the egress PE's "match for reception" of
(C-S,C-G). (C-S,C-G).
The rules for determining which x-PMSI A-D route is the match for The rules for determining which x-PMSI A-D route is the match for
reception are given in [RFC6625]. However, these rules are reception are given in [RFC6625]. However, these rules are
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-G) 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 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 [RFC8534]. However, when BIER is being used, the Leaf
the Leaf A-D route MUST carry a PTA that is constructed as follows: 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 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 (BFER). 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 (BFER'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 [RFC8279]. as described in [RFC8279].
4.1. Encapsulation and Transmission 4.1. Encapsulation and Transmission
To transmit an MVPN data packet, an ingress PE follows the rules of To transmit an MVPN data packet, an ingress PE follows the rules of
[RFC6625] to find the x-PMSI A-D route that is a "match for [RFC6625] to find the x-PMSI A-D route that is a "match for
transmission" for that packet. (In applying the rules of [RFC6625], transmission" for that packet. (In applying the rules of [RFC6625],
any S-PMSI A-D route with a PTA specifying "no tunnel information" is any S-PMSI A-D route with a PTA specifying "no tunnel information" is
ignored.) If the matching route has a PTA specifying "BIER", the ignored.) If the matching route has a PTA specifying BIER, the
(upstream-assigned) MPLS label from that PTA is pushed on the (upstream-assigned) MPLS label from that PTA is pushed on the
packet's label stack. Then the packet is encapsulated in a BIER packet's label stack. Then the packet is encapsulated in a BIER
header. That is, the ingress PE functions as a BFIR. The BIER header. That is, the ingress PE functions as a BFIR. The BIER
sub-domain used for transmitting the packet is specified in the PTA sub-domain used for transmitting the packet is specified in the PTA
of the abovementioned x-PMSI A-D route. of the above-mentioned x-PMSI A-D route.
In order to create the proper BIER header for a given packet, the In order to create the proper BIER header for a given packet, the
BFIR must know all the BFERs that need to receive that packet. It BFIR must know all the BFERs that need to receive that packet. It
determines this by finding all the Leaf A-D routes that correspond to determines this by finding all the Leaf A-D routes that correspond to
the S-PMSI A-D route that is the packet's match for transmission. the S-PMSI A-D route that is the packet's match for transmission.
There are two different cases to consider: There are two different cases to consider:
1. The S-PMSI A-D route that is the match for transmission carries a 1. The S-PMSI A-D route that is the match for transmission carries a
PTA that has the LIR flag set but does not have the LIR-pF flag PTA that has the LIR flag set but does not have the LIR-pF flag
set. set.
skipping to change at page 13, line 11 skipping to change at page 13, line 28
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 identical to the NLRI of the S-PMSI A-D "route key" field is identical to the NLRI of the S-PMSI A-D
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]. [RFC8534].
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
will not receive the packet. 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 [RFC8279] and [RFC8296]. (See especially Section 4, procedures described in [RFC8279] and [RFC8296]. (See especially
"Imposing and Processing the BIER Encapsulation", of [RFC8296].) Section 3, "Imposing and Processing the BIER Encapsulation" in
[RFC8296].)
4.2. Disposition 4.2. Disposition
When a BFER receives an MVPN multicast data packet that has been When a BFER receives an MVPN multicast data packet that has been
BIER-encapsulated, the BIER layer passes the following information to BIER-encapsulated, the BIER layer passes the following information to
the multicast flow overlay: the multicast flow overlay:
o The sub-domain-id and the BFIR-id from the BIER header. (As the o The sub-domain-id and the BFIR-id from the BIER header. (As the
sub-domain-id is inferred from the BIFT-id field of the BIER sub-domain-id is inferred from the BIFT-id field of the BIER
header, an implementation might choose to pass the BIFT-id rather header, an implementation might choose to pass the BIFT-id rather
than the sub-domain-id; this is an implementation matter.) 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. In the dataplane, the BFIR-id and the upstream-assigned label. In the data plane, the BFIR-id and the
sub-domain-id provide the context in which the upstream-assigned sub-domain-id provide the context in which the upstream-assigned
label is interpreted. label is interpreted.
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 the given packet, it
need to follow the procedures of Section 4.2.1, the procedures of may need to follow the procedures of Section 4.2.1, the procedures of
Section 4.2.2, or both. Section 4.2.2, or both.
4.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.
4.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.
5. Contributor Addresses 5. IANA Considerations
Below is a list of other contributing authors in alphabetical order:
IJsbrand Wijnands
Cisco Systems, Inc.
De Kleetlaan 6a
Diegem 1831
Belgium
Email: ice@cisco.com
6. Acknowledgments
The authors wish to thank Jeffrey Zhang for his ideas and
contributions to this work. We also thank Stig Venaas for his review
and comments.
7. IANA Considerations
IANA has assigned the codepoint 0x0B to "BIER" in the "P-Multicast IANA has assigned the codepoint 0x0B to BIER in the "P-Multicast
Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry.
8. Security Considerations 6. Security Considerations
The procedures of this document do not, in themselves, provide The procedures of this document do not, in themselves, provide
privacy, integrity, or authentication for the control plane or the privacy, integrity, or authentication for the control plane or the
data plane. For a discussion of the security considerations data plane. For a discussion of the security considerations
regarding the use of BIER, please see [RFC8279] and [RFC8296]. regarding the use of BIER, please see [RFC8279] and [RFC8296].
Security considerations regarding VPN technology based on [RFC4364], Security considerations regarding VPN technology based on [RFC4364],
[RFC6513], and [RFC6514] can be found in those RFCs. [RFC6513], and [RFC6514] can be found in those RFCs.
9. References 7. References
9.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
skipping to change at page 15, line 41 skipping to change at page 15, line 46
[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, <https://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,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", R. Qiu, "Wildcards in Multicast VPN Auto-Discovery
RFC 6625, DOI 10.17487/RFC6625, May 2012, Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012,
<https://www.rfc-editor.org/info/rfc6625>. <https://www.rfc-editor.org/info/rfc6625>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. <https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non- for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>. 2018, <https://www.rfc-editor.org/info/rfc8296>.
9.2. Informative References [RFC8534] Dolganow, A., Kotalwar, J., Rosen, E., Ed., and Z. Zhang,
"Explicit Tracking with Wildcard Routes in Multicast VPN",
RFC 8534, DOI 10.17487/RFC8534, February 2019,
<https://www.rfc-editor.org/info/rfc8534>.
[EXPLICIT_TRACKING] 7.2. Informative References
Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang,
"Explicit Tracking with Wild Card Routes in Multicast
VPN", internet-draft draft-ietf-bess-mvpn-expl-track-08,
February 2018.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc7900>. <https://www.rfc-editor.org/info/rfc7900>.
Acknowledgments
The authors wish to thank Jeffrey Zhang for his ideas and
contributions to this work. We also thank Stig Venaas for his review
and comments.
Contributors
IJsbrand Wijnands
Cisco Systems, Inc.
De Kleetlaan 6a
Diegem 1831
Belgium
Email: ice@cisco.com
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 of America
Email: erosen52@gmail.com
Email: erosen@juniper.net
Mahesh Sivakumar Mahesh Sivakumar
Cisco Systems, Inc. Juniper Networks, Inc.
510 McCarthy Blvd 1137 Innovation Way
Milpitas, California 95035 Sunnyvale, California 94089
United States United States of America
Email: masivaku@cisco.com Email: sivakumar.mahesh@gmail.com
Tony Przygienda
Juniper Networks, Inc.
1137 Innovation Way
Sunnyvale, California 94089
United States of America
Email: prz@juniper.net
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 of America
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Andrew Dolganow Andrew Dolganow
Nokia Nokia
438B Alexandra Rd #08-07/10 438B Alexandra Rd #08-07/10
Alexandra Technopark Alexandra Technopark
Singapore 119968 Singapore 119968
Email: andrew.dolganow@nokia.com Email: andrew.dolganow@nokia.com
Tony Przygienda
Juniper Networks, Inc.
1137 Innovation Way
San Jose, California 94089
United States
Email: prz@juniper.net
 End of changes. 97 change blocks. 
216 lines changed or deleted 220 lines changed or added

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