rfc9573.original   rfc9573.txt 
BESS Z. Zhang Internet Engineering Task Force (IETF) Z. Zhang
Internet-Draft Juniper Networks Request for Comments: 9573 Juniper Networks
Updates: 7432, 6514, 7582 (if approved) E. Rosen Updates: 6514, 7432, 7582 E. Rosen
Intended status: Standards Track Individual Category: Standards Track Individual
Expires: 6 April 2024 W. Lin ISSN: 2070-1721 W. Lin
Juniper Networks Juniper Networks
Z. Li Z. Li
Huawei Technologies Huawei Technologies
I. Wijnands IJ. Wijnands
Individual Individual
4 October 2023 April 2024
MVPN/EVPN Tunnel Aggregation with Common Labels MVPN/EVPN Tunnel Aggregation with Common Labels
draft-ietf-bess-mvpn-evpn-aggregation-label-14
Abstract Abstract
The MVPN specifications allow a single Point-to-Multipoint (P2MP) The Multicast VPN (MVPN) specifications allow a single Point-to-
tunnel to carry traffic of multiple IP VPNs (abbreviated as VPNs). Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs
The EVPN specifications allow a single P2MP tunnel to carry traffic (referred to as VPNs in this document). The EVPN specifications
of multiple Broadcast Domains (BDs). These features require the allow a single P2MP tunnel to carry traffic of multiple Broadcast
ingress router of the P2MP tunnel to allocate an upstream-assigned Domains (BDs). These features require the ingress router of the P2MP
MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or
tunnel then carries the label that is mapped to its VPN or BD (in for each BD. A packet sent on a P2MP tunnel then carries the label
some cases, a distinct upstream-assigned label is needed for each that is mapped to its VPN or BD (in some cases, a distinct upstream-
flow.) Since each ingress router allocates labels independently, assigned label is needed for each flow.) Since each ingress router
with no coordination among the ingress routers, the egress routers allocates labels independently, with no coordination among the
may need to keep track of a large number of labels. The number of ingress routers, the egress routers may need to keep track of a large
labels may need to be as large (or larger) than the product of the number of labels. The number of labels may need to be as large as,
number of ingress routers times the number of VPNs or BDs. However, or larger than, the product of the number of ingress routers times
the number of labels can be greatly reduced if the association the number of VPNs or BDs. However, the number of labels can be
between a label and a VPN or BD is made by provisioning, so that all greatly reduced if the association between a label and a VPN or BD is
ingress routers assign the same label to a particular VPN or BD. New made by provisioning, so that all ingress routers assign the same
procedures are needed in order to take advantage of such provisioned label to a particular VPN or BD. New procedures are needed in order
labels. These new procedures also apply to Multipoint-to-Multipoint to take advantage of such provisioned labels. These new procedures
(MP2MP) tunnels. This document updates RFCs 6514, 7432 and 7582 by also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This
specifying the necessary procedures. document updates RFCs 6514, 7432, and 7582 by specifying the
necessary procedures.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 6 April 2024. 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/rfc9573.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language
2.1. Problem Description . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology
2.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . 6 2. Problem Description
2.2.1. MP2MP Tunnels . . . . . . . . . . . . . . . . . . . . 8 3. Proposed Solutions
2.2.2. Segmented Tunnels . . . . . . . . . . . . . . . . . . 8 3.1. MP2MP Tunnels
2.2.3. Summary of Label Allocation Methods . . . . . . . . . 10 3.2. Segmented Tunnels
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Summary of Label Allocation Methods
3.1. Context-Specific Label Space ID Extended Community . . . 11 4. Specifications
3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Context-Specific Label Space ID Extended Community
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.2. Procedures
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Contributors
Authors' Addresses
1. Terminology 1. Introduction
A Multicast VPN (MVPN) can use Point-to-Multipoint (P2MP) tunnels
(set up by RSVP-TE, Multipoint LDP (mLDP), or PIM) to transport
customer multicast traffic across a service provider's backbone
network. Often, a given P2MP tunnel carries the traffic of only a
single VPN. However, there are procedures defined that allow a
single P2MP tunnel to carry traffic of multiple VPNs. In this case,
the P2MP tunnel is called an "aggregate tunnel". The Provider Edge
(PE) router that is the ingress node of an aggregate P2MP tunnel
allocates an "upstream-assigned MPLS label" [RFC5331] for each VPN,
and each packet sent on the P2MP tunnel carries the upstream-assigned
MPLS label that the ingress PE has bound to the packet's VPN.
Similarly, an EVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or
PIM) to transport Broadcast, Unknown Unicast, or Multicast (BUM)
traffic across the provider network. Often, a P2MP tunnel carries
the traffic of only a single Broadcast Domain (BD). However, there
are procedures defined that allow a single P2MP tunnel to be an
aggregate tunnel that carries traffic of multiple BDs. The
procedures are analogous to the MVPN procedures -- the PE router that
is the ingress node of an aggregate P2MP tunnel allocates an
upstream-assigned MPLS label for each BD, and each packet sent on the
P2MP tunnel carries the upstream-assigned MPLS label that the ingress
PE has bound to the packet's BD.
An MVPN or EVPN can also use Bit Index Explicit Replication (BIER)
[RFC8279] to transmit VPN multicast traffic [RFC8556] or EVPN BUM
traffic [BIER-EVPN]. Although BIER does not explicitly set up P2MP
tunnels, from the perspective of an MVPN/EVPN, the use of BIER
transport is very similar to the use of aggregate P2MP tunnels. When
BIER is used, the PE transmitting a packet (the "Bit-Forwarding
Ingress Router" (BFIR) [RFC8279]) must allocate an upstream-assigned
MPLS label for each VPN or BD, and the packets transmitted using BIER
transport always carry the label that identifies their VPN or BD.
(See [RFC8556] and [BIER-EVPN] for details.) In the remainder of
this document, we will use the term "aggregate tunnels" to include
both P2MP tunnels and BIER transport.
When an egress PE receives a packet from an aggregate tunnel, it must
look at the upstream-assigned label carried by the packet and must
interpret that label in the context of the ingress PE. Essentially,
for each ingress PE, the egress PE has a context-specific label space
[RFC5331] that matches the default label space from which the ingress
PE assigns the upstream-assigned labels. When an egress PE looks up
the upstream-assigned label carried by a given packet, it looks it up
in the context-specific label space for the ingress PE of the packet.
How an egress PE identifies the ingress PE of a given packet depends
on the tunnel type.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology
Familiarity with MVPN/EVPN protocols and procedures is assumed. Some Familiarity with MVPN/EVPN protocols and procedures is assumed. Some
terminologies are listed below for convenience. terms are listed below for convenience.
* VPN: Virtual Private Network. In this document, it is VPN: Virtual Private Network. In this document, "VPN" specifically
specifically IP VPN [RFC4364]. refers to an IP VPN [RFC4364].
* BUM [RFC7432]: Broadcast, Unknown unicast, or Multicast (traffic). BUM [RFC7432]: Broadcast, Unknown Unicast, or Multicast (traffic).
* BD [RFC7432]: Broadcast Domain. BD [RFC7432]: Broadcast Domain.
* EC [RFC4360]: Extended Community. EC [RFC4360]: Extended Community.
* PMSI [RFC6513]: Provider Multicast Service Interface - a pseudo PMSI [RFC6513]: Provider Multicast Service Interface. A pseudo-
overlay interface for PEs to send certain overlay/customer overlay interface for PEs to send certain overlay/customer
multicast traffic via underlay/provider tunnels. It includes multicast traffic via underlay/provider tunnels. It includes
I/S-PMSI (often referred to as x-PMSI) for Inclusive/Selective Inclusive/Selective PMSIs (I/S-PMSIs) (often referred to as
PMSI. A PMSI is instantiated by the underlay/provider tunnel. x-PMSIs). A PMSI is instantiated by the underlay/provider tunnel.
* Inclusive PMSI: A PMSI that enables traffic to be sent to all PEs Inclusive PMSI (I-PMSI): A PMSI that enables traffic to be sent to
of a VPN/BD. The underlay/provider tunnel that instantiates the all PEs of a VPN/BD. The underlay/provider tunnel that
Inclusive PMSI is referred to as an inclusive tunnel. instantiates the I-PMSI is referred to as an inclusive tunnel.
* Selective PMSI: A PMSI that enables traffic to be sent to a subset Selective PMSI (S-PMSI): A PMSI that enables traffic to be sent to a
of PEs of a VPN/BD. The underlay/provider tunnel that subset of PEs of a VPN/BD. The underlay/provider tunnel that
instantiates the Selective PMSI is referred to as a selective instantiates the S-PMSI is referred to as a selective tunnel.
tunnel.
* Aggregate Tunnel: a tunnel that instantiates x-PMSIs of multiple Aggregate Tunnel: A tunnel that instantiates x-PMSIs of multiple
MVPNs or EVPN BDs. MVPNs or EVPN BDs.
* IMET [RFC7432]: Inclusive Multicast Ethernet Tag route. An EVPN IMET [RFC7432]: Inclusive Multicast Ethernet Tag. An EVPN-specific
specific name for I-PMSI A-D route. name for an I-PMSI Auto-Discovery (A-D) route.
* PTA [RFC6514]: PMSI Tunnel Attribute. A BGP attribute that may be PTA [RFC6514]: PMSI Tunnel Attribute. A BGP attribute that may be
attached to an BGP-MVPN/EVPN x-PMXI A-D routes. attached to a BGP-MVPN/EVPN x-PMSI A-D route.
* RBR: Regional Border Routers. Border routers between segmentation ASBR: Autonomous System Border Router.
regions that participate in segmentation procedures.
* (C-S,C-G): A Customer/overlay <S,G> multicast flow. RBR: Regional Border Router. A border router between segmentation
regions that participates in segmentation procedures.
* (C-*,C-G): Customer/overlay <*,G> multicast flows. (C-S,C-G): A Customer/overlay <S,G> multicast flow.
* (C-*,C-*): All Customer/overlay multicast flows. (C-*,C-G): Customer/overlay <*,G> multicast flows.
* ESI [RFC7432]: Ethernet Segment Identifier. (C-*,C-*): All Customer/overlay multicast flows.
* ESI Label[RFC7432]: A label that identifies an Ethernet Segment ES: Ethernet Segment.
* SRGB [RFC8402]: Segment Routing (SR) Global Block, the set of ESI [RFC7432]: ES Identifier.
global segments in the SR domain. In SR-MPLS [RFC8660], SRGB is a
local property of a node and identifies the set of local labels
reserved for global segments.
* DCB: Domain-wide Common Block, a common block of labels reserved ESI Label [RFC7432]: A label that identifies an ES.
on all nodes in a domain.
* Context-specific Label Space [RFC5331]: A router may maintain SRGB [RFC8402]: Segment Routing (SR) Global Block. The set of
global segments in the SR domain. In SR-MPLS [RFC8660], an SRGB
is a local property of a node and identifies the set of local
labels reserved for global segments.
DCB: Domain-wide Common Block. A common block of labels reserved on
all nodes in a domain.
Context-Specific Label Space [RFC5331]: A router may maintain
additional label spaces besides its default label space. When the additional label spaces besides its default label space. When the
label at the top of the stack is not from the default label space, label at the top of the stack is not from the default label space,
there must be some context in the packet that identifies which one there must be some context in the packet that identifies which one
of those additional label spaces is to be used to look up the of those additional label spaces is to be used to look up the
label, hence those label spaces are referred to as context- label; hence, those label spaces are referred to as context-
specific label spaces. specific label spaces.
* Upstream-assigned [RFC5331]: When the label at the top of the Upstream Assigned [RFC5331]: When the label at the top of the label
label stack is not assigned by the router receiving the traffic stack is not assigned by the router receiving the traffic from its
from its default label space, the label is referred to as default label space, the label is referred to as upstream
upstream-assigned. Otherwise, it is downstream-assigned. An assigned. Otherwise, it is downstream assigned. An upstream-
upstream-assigned label must be looked up in a context-specific assigned label must be looked up in a context-specific label space
label space specific for the assigner. specific for the assigner.
2. Introduction
MVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) to
transport customer multicast traffic across a service provider's
backbone network. Often, a given P2MP tunnel carries the traffic of
only a single VPN. There are however procedures defined that allow a
single P2MP tunnel to carry traffic of multiple VPNs. In this case,
the P2MP tunnel is called an "aggregate tunnel". The PE router that
is the ingress node of an aggregate P2MP tunnel allocates an
"upstream-assigned MPLS label" [RFC5331] for each VPN, and each
packet sent on the P2MP tunnel carries the upstream-assigned MPLS
label that the ingress PE has bound to the packet's VPN.
Similarly, EVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or
PIM) to transport BUM traffic (Broadcast traffic, Unicast traffic
with an Unknown address, or Multicast traffic), across the provider
network. Often a P2MP tunnel carries the traffic of only a single
BD. However, there are procedures defined that allow a single P2MP
tunnel to be an "aggregate tunnel" that carries traffic of multiple
BDs. The procedures are analogous to the MVPN procedures -- the PE
router that is the ingress node of an aggregate P2MP tunnel allocates
an upstream-assigned MPLS label for each BD, and each packet sent on
the P2MP tunnel carries the upstream-assigned MPLS label that the
ingress PE has bound to the packet's BD.
MVPN and EVPN can also use BIER [RFC8279] to transmit VPN multicast
traffic or EVPN BUM traffic [RFC8556] [I-D.ietf-bier-evpn]. Although
BIER does not explicitly set up P2MP tunnels, from the perspective of
MVPN/EVPN, the use of BIER transport is very similar to the use of
aggregate P2MP tunnels. When BIER is used, the PE transmitting a
packet (the "BFIR" [RFC8279]) must allocate an upstream-assigned MPLS
label for each VPN or BD, and the packets transmitted using BIER
transport always carry the label that identifies their VPN or BD.
(See [RFC8556] and [I-D.ietf-bier-evpn] for the details.) In the
remainder of this document, we will use the term "aggregate tunnels"
to include both P2MP tunnels and BIER transport.
When an egress PE receives a packet from an aggregate tunnel, it must
look at the upstream-assigned label carried by the packet, and must
interpret that label in the context of the ingress PE. Essentially,
for each ingress PE, the egress PE has a context-specific label space
[RFC5331] that matches the default label space from which the ingress
PE assigns the upstream-assigned labels. When an egress PE looks up
the upstream-assigned label carried by a given packet, it looks it up
in the context-specific label space for the ingress PE of the packet.
How an egress PE identifies the ingress PE of a given packet depends
on the tunnel type.
2.1. Problem Description 2. Problem Description
Note that the upstream-assigned label procedures may require a very Note that the upstream-assigned label procedures may require a very
large number of labels. Suppose an MVPN or EVPN deployment has 1001 large number of labels. Suppose that an MVPN or EVPN deployment has
PEs, each hosting 1000 VPN/BDs. Each ingress PE has to assign 1000 1001 PEs, each hosting 1000 VPNs/BDs. Each ingress PE has to assign
labels, and each egress PE has to be prepared to interpret 1000 1000 labels, and each egress PE has to be prepared to interpret 1000
labels from each of the ingress PEs. Since each ingress PE allocates labels from each of the ingress PEs. Since each ingress PE allocates
labels from its own label space and does not coordinate label labels from its own label space and does not coordinate label
assignments with others, each egress PE must be prepared to interpret assignments with others, each egress PE must be prepared to interpret
1,000,000 upstream-assigned labels (across 1000 context-specific 1,000,000 upstream-assigned labels (across 1000 context-specific
label spaces - one for each ingress PE). This is an evident scaling label spaces -- one for each ingress PE). This is an evident scaling
problem. problem.
So far, few if any MVPN/EVPN deployments use aggregate tunnels, so So far, few if any MVPN/EVPN deployments use aggregate tunnels, so
this problem has not surfaced. However, the use of aggregate tunnels this problem has not surfaced. However, the use of aggregate tunnels
is likely to increase due to the following two factors: is likely to increase due to the following two factors:
* In EVPN, a single customer ("tenant") may have a large number of * In an EVPN, a single customer ("tenant") may have a large number
BDs, and the use of aggregate RSVP-TE or mLDP P2MP tunnels may of BDs, and the use of aggregate RSVP-TE or mLDP P2MP tunnels may
become important, since each tunnel creates state at the become important, since each tunnel creates state at the
intermediate nodes. intermediate nodes.
* The use of BIER as transport for MVPN/EVPN is becoming more and * The use of BIER as the transport for an MVPN/EVPN is becoming more
more attractive and feasible. and more attractive and feasible.
A similar problem also exists with EVPN ESI labels used for multi- A similar problem also exists with EVPN ESI labels used for
homing. A PE attached to a multi-homed Ethernet Segment (ES) multihoming. A PE attached to a multihomed ES advertises an ESI
advertises an ESI label in its Ethernet A-D per Ethernet Segment label in its Ethernet A-D per ES route. The PE imposes the label
Route. The PE imposes the label when it sends frames received from when it sends frames received from the ES to other PEs via a P2MP/
the ES to other PEs via a P2MP/BIER tunnel. A receiving PE that is BIER tunnel. A receiving PE that is attached to the source ES will
attached to the source ES will know from the ESI label that the know from the ESI label that the packet originated on the source ES
packet originated on the source ES, and thus will not transmit the and thus will not transmit the packet on its local Attachment Circuit
packet on its local attachment circuit to that ES. From the to that ES. From the receiving PE's point of view, the ESI label is
receiving PE's point of view, the ESI label is (upstream-)assigned (upstream) assigned from the source PE's label space, so the
from the source PE's label space, so the receiving PE needs to receiving PE needs to maintain context-specific label tables, one for
maintain context-specific label tables, one for each source PE, just each source PE, just like the VPN/BD label case above. If there are
like the VRF/BD label case above. If there are 1,001 PEs, each 1001 PEs, each attached to 1000 ESs, this can require each PE to
attached to 1,000 ESes, this can require each PE to understand understand 1,000,000 ESI labels. Notice that the issue exists even
1,000,000 ESI labels. Notice that the issue exists even when no P2MP when no P2MP tunnel aggregation (i.e., one tunnel used for multiple
tunnel aggregation (i.e. one tunnel used for multiple BDs) is used. BDs) is used.
2.2. Proposed Solution 3. Proposed Solutions
The number of labels could be greatly reduced if a central entity in The number of labels could be greatly reduced if a central entity in
the provider network assigned a label to each VPN, BD, or ES, and if the provider network assigned a label to each VPN, BD, or ES and if
all PEs used that same label to represent a given VPN , BD, or ES. all PEs used that same label to represent a given VPN, BD, or ES.
Then the number of labels needed would just be the sum of the number Then, the number of labels needed would just be the sum of the number
of VPNs, BD, and/or ESes. of VPNs, BDs, and/or ESs.
One method of achieving this is to reserve a portion of the default One method of achieving this is to reserve a portion of the default
label space for assignment by a central entity. We refer to this label space for assignment by a central entity. We refer to this
reserved portion as the "Domain-wide Common Block" (DCB) of labels. reserved portion as the DCB of labels. This is analogous to the
This is analogous to the identical "Segment Routing Global Block" concept of using identical SRGBs on all nodes, as described in
(SRGB) on all nodes that is described in [RFC8402]. A PE that is [RFC8402]. A PE that is attached (via L3VPN Virtual Routing and
attached (via L3VPN VRF interfaces or EVPN Access Circuits) would Forwarding (VRF) interfaces or EVPN Attachment Circuits) would know
know by provisioning which label from the DCB corresponds to which of by provisioning which label from the DCB corresponds to which of its
its locally attached VPNs, BDs, or ESes. locally attached VPNs, BDs, or ESs.
For example, all PEs could reserve a DCB [1000, 2000] and they are For example, all PEs could reserve a DCB [1000~2000], and they would
all provisioned that label 1000 maps to VPN 0, 1001 to VPN 1, and so all be provisioned so that label 1000 maps to VPN 0, label 1001 maps
forth. Now only 1000 labels instead of 1,000,000 labels are needed to VPN 1, and so forth. Now, only 1000 labels instead of 1,000,000
for 1000 VPNs. labels are needed for 1000 VPNs.
The definition of "domain" is loose - it simply includes all the In this document, "domain" is defined loosely; it simply includes all
routers that share the same DCB. In this document, it only needs to the routers that share the same DCB, and it only needs to include all
include all PEs of an MVPN/EVPN network. PEs of an MVPN/EVPN.
The "domain" could also include all routers in the provider network, The "domain" could also include all routers in the provider network,
making it not much different from a common SRGB across all the making it not much different from a common SRGB across all the
routers. However, that is not necessary as the labels used by PEs routers. However, that is not necessary, as the labels used by PEs
for the purposes defined in this document will only rise to the top for the purposes defined in this document will only rise to the top
of the label stack when traffic arrives at the PEs. Therefore, it is of the label stack when traffic arrives at the PEs. Therefore, it is
better to not include internal P routers in the "domain". That way better to not include internal P routers in the "domain". That way,
they do not have to set aside the same DCB used for the purposes in they do not have to set aside the same DCB used for the purposes
this document. defined in this document.
In some deployments, it may be impractical to allocate a DCB that is In some deployments, it may be impractical to allocate a DCB that is
large enough to contain labels for all the VPNs/BDs/ESes. In this large enough to contain labels for all the VPNs/BDs/ESs. In this
case, it may be necessary to allocate those labels from one or a few case, it may be necessary to allocate those labels from one or a few
separate context-specific label spaces independent of each PE. For context-specific label spaces that are independent of each PE. For
example, if it is too difficult to have a DCB of 10,000 labels across example, if it is too difficult to have a DCB of 10,000 labels across
all PEs for all the VPNs/BDs/ESes that need to be supported, a all PEs for all the VPNs/BDs/ESs that need to be supported, a
separate context-specific label space can be dedicated to those separate context-specific label space can be dedicated to those
10,000 labels. Each separate context-specific label space is 10,000 labels. Each separate context-specific label space is
identified in the forwarding plane by a label from the DCB (which identified in the forwarding plane by a label from the DCB (which
does not need to be large). Each PE is provisioned with the label- does not need to be large). Each PE is provisioned with the label-
space-identifying DCB label and the common VPN/BD/ES labels allocated space-identifying DCB label and the common VPN/BD/ES labels allocated
from that context-specific label space. When sending traffic, an from that context-specific label space. When sending traffic, an
ingress PE imposes all necessary service labels (for the VPN/BD/ES) ingress PE imposes all necessary service labels (for the VPN/BD/ES)
first, then imposes the label-space-identifying DCB label. From the first, then imposes the label-space-identifying DCB label. From the
label-space-identifying DCB label an egress PE can determine the label-space-identifying DCB label, an egress PE can determine the
label space where the inner VPN/BD/ES label is looked up. label space where the inner VPN/BD/ES label is looked up.
The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes
that certain MPLS labels are allocated from a context-specific label that certain MPLS labels are allocated from a context-specific label
space for a particular ingress PE. In this document, we augment the space for a particular ingress PE. In this document, we augment the
signaling procedures so that it is possible to signal that a signaling procedures so that it is possible to signal that a
particular label is from the DCB, rather than from a context-specific particular label is from the DCB, rather than from a context-specific
label space for an ingress PE. We also augment the signaling so that label space for an ingress PE. We also augment the signaling so that
it is possible to indicate that a particular label is from an it is possible to indicate that a particular label is from an
identified context-specific label space that is not for an ingress identified context-specific label space that is not for an ingress
PE. PE.
Notice that, the VPN/BD/ES-identifying labels from the DCB or from Notice that the VPN/BD/ES-identifying labels from the DCB or from
those few context-specific label spaces are very similar to VNIs in those few context-specific label spaces are very similar to Virtual
VXLAN. Allocating a label from the DCB or from a context-specific eXtensible Local Area Network (VXLAN) Network Identifiers (VNIs) in
label spaces and communicating them to all PEs is not different from VXLANs. Allocating a label from the DCB or from a context-specific
allocating VNIs, and is feasible especially with controllers. label space and communicating the label to all PEs is not different
from allocating VNIs and is especially feasible with controllers.
2.2.1. MP2MP Tunnels 3.1. MP2MP Tunnels
MP2MP tunnels present the same problem (Section 2.1) that can be Multipoint-to-Multipoint (MP2MP) tunnels present the same problem
solved the same way (Section 2.2), with the following additional (Section 2) that can be solved the same way (Section 3), with the
requirement. following additional requirement.
Per RFC 7582 ("MVPN: Using Bidirectional P-tunnels"), when MP2MP Per [RFC7582] ("Multicast Virtual Private Network (MVPN): Using
tunnels are used for MVPN, the root of the MP2MP tunnel may need to Bidirectional P-Tunnels"), when MP2MP tunnels are used for an MVPN,
allocate and advertise "PE Distinguisher Labels" (section 4 of the root of the MP2MP tunnel is required to allocate and advertise
[RFC6513]. These labels are assigned from the label space used by "PE Distinguisher Labels" (Section 4 of [RFC6513]). These labels are
the root node for its upstream-assigned labels. assigned from the label space used by the root node for its upstream-
assigned labels.
It is REQUIRED by this document that the PE Distinguisher labels It is REQUIRED by this document that the PE Distinguisher Labels
allocated by a particular node come from the same label space that allocated by a particular node come from the same label space that
the node uses to allocate its VPN-identifying labels. the node uses to allocate its VPN-identifying labels.
2.2.2. Segmented Tunnels 3.2. Segmented Tunnels
There are some additional issues to be considered when MVPN or EVPN There are some additional issues to be considered when an MVPN or
is using "tunnel segmentation" (see [RFC6514], [RFC7524], and EVPN is using "tunnel segmentation" (see [RFC6514], [RFC7524], and
[I-D.ietf-bess-evpn-bum-procedure-updates] Sections 5 and 6). Sections 5 and 6 of [RFC9572]).
2.2.2.1. Selective Tunnels 3.2.1. Selective Tunnels
For "selective tunnels" that instantiate S-PMSIs (see [RFC6513] For selective tunnels that instantiate S-PMSIs (see Sections 2.1.1
Sections 2.1.1 and 3.2.1, and and 3.2.1 of [RFC6513] and Section 4 of [RFC9572]), the procedures
[I-D.ietf-bess-evpn-bum-procedure-updates] Section 4), the procedures
outlined above work only if tunnel segmentation is not used. outlined above work only if tunnel segmentation is not used.
A selective tunnel carries one or more particular sets of flows to a A selective tunnel carries one or more particular sets of flows to a
particular subset of the PEs that attach to a given VPN or BD. Each particular subset of the PEs that attach to a given VPN or BD. Each
set of flows is identified by a Selective PMSI A-D route [RFC6514]. set of flows is identified by an S-PMSI A-D route [RFC6514]. The PTA
The PTA of the S-PMSI route identifies the tunnel used to carry the of the S-PMSI route identifies the tunnel used to carry the
corresponding set of flows. Multiple S-PMSI routes can identify the corresponding set of flows. Multiple S-PMSI routes can identify the
same tunnel. same tunnel.
When tunnel segmentation is applied to an S-PMSI, certain nodes are When tunnel segmentation is applied to an S-PMSI, certain nodes are
"segmentation points". A segmentation point is a node at the "segmentation points". A segmentation point is a node at the
boundary between two "segmentation regions". Let's call these boundary between two segmentation regions. Let's call these "region
"region A" and "region B". A segmentation point is an egress node A" and "region B". A segmentation point is an egress node for one or
for one or more selective tunnels in region A, and an ingress node more selective tunnels in region A and an ingress node for one or
for one or more selective tunnels in region B. A given segmentation more selective tunnels in region B. A given segmentation point must
point must be able to receive traffic on a selective tunnel from be able to receive traffic on a selective tunnel from region A and
region A, and label switch the traffic to the proper selective tunnel label-switch the traffic to the proper selective tunnel in region B.
in region B.
Suppose one selective tunnel (call it T1) in region A is carrying two Suppose that one selective tunnel (call it "T1") in region A is
flows, Flow-1 and Flow-2, identified by S-PMSI route Route-1 and carrying two flows, Flow-1 and Flow-2, identified by S-PMSI routes
Route-2, respectively. However, it is possible that, in region B, Route-1 and Route-2, respectively. However, it is possible that in
Flow-1 is not carried by the same selective tunnel that carries Flow- region B, Flow-1 is not carried by the same selective tunnel that
2. Let's suppose that in region B, Flow-1 is carried by tunnel T2 carries Flow-2. Let's suppose that in region B, Flow-1 is carried by
and Flow-2 by tunnel T3. Then, when the segmentation point receives tunnel T2 and Flow-2 by tunnel T3. Then, when the segmentation point
traffic from T1, it must be able to label switch Flow-1 from T1 to receives traffic from T1, it must be able to label-switch Flow-1 from
T2, while also label switching Flow-2 from T1 to T3. This implies T1 to T2, while also label-switching Flow-2 from T1 to T3. This
that Route-1 and Route-2 must signal different labels in the PTA. implies that Route-1 and Route-2 must signal different labels in the
For comparison, when segmentation is not used, they can all use the PTA. For comparison, when segmentation is not used, they can all use
common per-VPN/BD DCB label. the common per-VPN/BD DCB label.
In this case, it is not practical to have a central entity assign In this case, it is not practical to have a central entity assign
domain-wide unique labels to individual S-PMSI routes. To address domain-wide unique labels to individual S-PMSI routes. To address
this problem, all PEs can be assigned disjoint label blocks in those this problem, all PEs can be assigned their own disjoint label blocks
few context-specific label spaces, and each will independently in those few context-specific label spaces; each PE will
allocate labels for segmented S-PMSI from its assigned label block independently allocate labels for a segmented S-PMSI from its own
that is different from any other PE's. For example, PE1 allocates assigned label block. For example, PE1 allocates from label block
from label block [101~200], PE2 allocates from label block [201~300], [101~200], PE2 allocates from label block [201~300], and so on.
and so on.
Allocating from disjoint label blocks can be used for VPN/BD/ES Allocating from disjoint label blocks can be used for VPN/BD/ES
labels as well, though it does not address the original scaling labels as well, though it does not address the original scaling
issue, because there would be one million labels allocated from those issue, because there would be 1,000,000 labels allocated from those
few context label spaces in the original example, instead of just one few context-specific label spaces in the original example, instead of
thousand common labels. just 1000 common labels.
2.2.2.2. Per-PE/Region Tunnels 3.2.2. Per-PE/Region Tunnels
Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN IMET) Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN IMET)
or per-AS/region (MVPN Inter-AS I-PMSI or EVPN per-Region I-PMSI) or per-AS/region (MVPN Inter-AS I-PMSI or EVPN per-region I-PMSI)
tunnels ([RFC6514] [RFC7432] tunnels [RFC6514] [RFC7432] [RFC9572], labels need to be allocated
[I-D.ietf-bess-evpn-bum-procedure-updates]), labels need to be per PMSI route. In the case of a per-PE PMSI route, the labels
allocated per PMSI route. In case of per-PE PMSI route, the labels
should be allocated from the label block allocated to the advertising should be allocated from the label block allocated to the advertising
PE. In case of per-AS/region PMSI route, different ASBR/RBRs PE. In the case of a per-AS/region PMSI route, different ASBRs/RBRs
(Regional Border Routers) attached to the same source AS/region will attached to the same source AS/region will advertise the same PMSI
advertise the same PMSI route. The same label could be used when the route. The same label could be used when the same route is
same route is advertised by different ASBRs/RBRs, though that advertised by different ASBRs/RBRs, though that requires
requires coordination and a simpler way is for each ASBR/RBR to coordination; a simpler way is for each ASBR/RBR to allocate a label
allocate a label from the label block allocated to itself (see from the label block allocated to itself (see Section 3.2.1).
Section 2.2.2.1).
In the rest of the document, we call the label allocated for a In the rest of this document, we call the label allocated for a
particular PMSI a (per-)PMSI label, just like we have (per-)VPN/BD/ES particular PMSI a "(per-)PMSI label", just like we have (per-)VPN/BD/
labels. Notice that using per-PMSI label in case of per-PE PMSI ES labels. Notice that using a per-PMSI label in the case of a per-
still has the original scaling issue associated with the upstream- PE PMSI still has the original scaling issue associated with the
assigned label, so per-region PMSIs is preferred. Within each AS/ upstream-assigned label, so per-region PMSIs are preferred. Within
region, per-PE PMSIs are still used though they do not go across each AS/region, per-PE PMSIs are still used, though they do not go
border and per-VPN/BD labels can still be used. across borders and per-VPN/BD labels can still be used.
Note that, when a segmentation point re-advertises a PMSI route to Note that when a segmentation point re-advertises a PMSI route to the
the next segment, it does not need to re-advertise a new label unless next segment, it does not need to re-advertise a new label unless the
the upstream or downstream segment uses Ingress Replication. upstream or downstream segment uses ingress replication.
2.2.2.3. Alternative to the per-PMSI Label Allocation 3.2.3. Alternative to Per-PMSI Label Allocation
The per-PMSI label allocation in case of segmentation, whether for Per-PMSI label allocation in the case of segmentation, whether for
S-PMSI or for per-PE/Region I-PMSI, is for the segmentation points to S-PMSIs or per-PE/region I-PMSIs, is applied so that segmentation
be able to label switch traffic without having to do IP or MAC lookup points are able to label-switch traffic without having to do IP or
in VRFs (the segmentation points typically do not have those VRFs at Media Access Control (MAC) lookups in VRFs (the segmentation points
all). If the label scaling becomes a concern, alternatively the typically do not have those VRFs at all). Alternatively, if the
segmentation points could use (C-S,C-G) lookup in VRFs for flows label scaling becomes a concern, the segmentation points could use
identified by the S-PMSIs. This allows the S-PMSIs for the same VPN/ (C-S,C-G) lookups in VRFs for flows identified by the S-PMSIs. This
BD to share a VPN/BD-identifying label that leads to look up in the allows the S-PMSIs for the same VPN/BD to share a VPN/BD-identifying
VRFs. That label needs to be different from the label used in the label that leads to lookups in the VRFs. That label needs to be
per-PE/region I-PMSIs though, so that the segmentation points can different from the label used in the per-PE/region I-PMSIs though, so
label switch other traffic (not identified by those S-PMSIs). that the segmentation points can label-switch other traffic (not
However, this moves the scaling problem from the number of labels to identified by those S-PMSIs). However, this moves the scaling
the number of (C-S/*,C-G) routes in VRFs on the segmentation points. problem from the number of labels to the number of (C-S/*,C-G) routes
in VRFs on the segmentation points.
2.2.3. Summary of Label Allocation Methods 3.3. Summary of Label Allocation Methods
In summary, labels can be allocated and advertised in the following In summary, labels can be allocated and advertised in the following
ways: ways:
1. A central entity allocates per-VPN/BD/ES labels from the DCB. 1. A central entity allocates per-VPN/BD/ES labels from the DCB.
PEs advertise the labels with an indication that they are from PEs advertise the labels with an indication that they are from
the DCB. the DCB.
2. A central entity allocates per-VPN/BD/ES labels from a few common 2. A central entity allocates per-VPN/BD/ES labels from a few common
context-specific label spaces, and allocate labels from the DCB context-specific label spaces and allocates labels from the DCB
to identify those context-specific label spaces. PEs advertise to identify those context-specific label spaces. PEs advertise
the VPN/BD labels along with the context-identifying labels. the VPN/BD labels along with the context-identifying labels.
3. A central entity assigns disjoint label blocks from a few 3. A central entity assigns disjoint label blocks from a few
context-specific label spaces to each PE, and allocates labels context-specific label spaces to each PE and allocates labels
from the DCB to identify those context-specific label spaces. A from the DCB to identify those context-specific label spaces. A
PE independently allocates a label for a segmented S-PMSI from PE independently allocates a label for a segmented S-PMSI from
its assigned label block, and advertises the label along with the its assigned label block and advertises the label along with the
context-identifying label. context-identifying label.
Option 1 is simplest, but it requires that all the PEs set aside a Option 1 is simplest, but it requires that all the PEs set aside a
common label block for the DCB that is large enough for all the common label block for the DCB that is large enough for all the
VPNs/BDs/ESes combined. Option 3 is needed only for segmented VPNs/BDs/ESs combined. Option 3 is needed only for segmented
selective tunnels that are set up dynamically. Multiple options selective tunnels that are set up dynamically. Multiple options
could be used in any combination depending on the deployment could be used in any combination, depending on the deployment
situation. situation.
3. Specification 4. Specifications
3.1. Context-Specific Label Space ID Extended Community 4.1. Context-Specific Label Space ID Extended Community
Context-Specific Label Space ID Extended Community (EC) is a new The Context-Specific Label Space ID Extended Community (EC) is a new
Transitive Opaque EC with the following structure: Transitive Opaque EC with the following structure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 or 0x43 | 8 | ID-Type | | 0x03 or 0x43 | 8 | ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID-Value | | ID-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* ID-Type: A 2-octet field that specifies the type of Label Space ID-Type: A 2-octet field that specifies the type of Label Space ID.
ID. In this document, the ID-Type is 0, indicating that the ID- In this document, the ID-Type is 0, indicating that the ID-Value
Value field is a label. field is a label.
* ID-Value: A 4-octet field that specifies the value of Label Space ID-Value: A 4-octet field that specifies the value of the Label
ID. When it is a label (with ID-Type 0), the most significant Space ID. When it is a label (with ID-Type 0), the most
20-bit is set to the label value. significant 20-bit portion is set to the label value.
This document introduces a DCB flag (Bit 47 as assigned by IANA) in This document introduces a DCB-flag (Bit 47 as assigned by IANA) in
the "Additional PMSI Tunnel Attribute Flags" BGP Extended Community the "Additional PMSI Tunnel Attribute Flags" BGP Extended Community
[RFC7902]. [RFC7902].
In the remainder of the document, when we say a BGP-MVPN/EVPN A-D In the remainder of this document, when we say that a BGP-MVPN/EVPN
route "carries DCB-flag" or "has DCB-flag attached" we mean the A-D route carries a DCB-flag or has a DCB-flag attached to it, we
following: mean the following:
* The route carries a PMSI Tunnel Attribute (PTA) and its Flags * The route carries a PTA and its Flags field has the Extension bit
field has the Extension bit set, AND, set, AND
* The route carries an "Additional PMSI Tunnel Attribute Flags" EC * The route carries an "Additional PMSI Tunnel Attribute Flags" EC
and its DCB flag is set and its DCB-flag is set.
3.2. Procedures 4.2. Procedures
The protocol and procedures specified in this section MAY be used The protocol and procedures specified in this section MAY be used
when BIER, or P2MP/MP2MP tunnel aggregation is used for MVPN/EVPN, or when BIER or P2MP/MP2MP tunnel aggregation is used for an MVPN/EVPN
BIER/P2MP/MP2MP tunnels are used with EVPN multi-homing. When these or when BIER/P2MP/MP2MP tunnels are used with EVPN multihoming. When
procedures are used, all PE routers and segmentation points MUST these procedures are used, all PE routers and segmentation points
support the procedures. It is outside the scope of this document how MUST support the procedures. How to ensure this behavior is outside
that is ensured. the scope of this document.
By means outside the scope of this document, each VPN/BD/ES is Via methods outside the scope of this document, each VPN/BD/ES is
assigned a label from the DCB or one of those few context-specific assigned a label from the DCB or one of those few context-specific
label spaces, and every PE that is part of the VPN/BD/ES is aware of label spaces, and every PE that is part of the VPN/BD/ES is aware of
the assignment. The ES label and the BD label MUST be assigned from the assignment. The ES label and the BD label MUST be assigned from
the same label space. If PE Distinguisher labels are used [RFC7582], the same label space. If PE Distinguisher Labels are used [RFC7582],
they MUST be allocated from the same label space as well. they MUST be allocated from the same label space as well.
In case of tunnel segmentation, each PE is also assigned a disjoint In the case of tunnel segmentation, each PE is also assigned a
label block from one of those few context-specific label spaces and disjoint label block from one of those few context-specific label
it allocates labels for its segmented PMSI routes from its assigned spaces, and it allocates labels for its segmented PMSI routes from
label block. its assigned label block.
When a PE originates/re-advertises an x-PMSI/IMET route, the route When a PE originates/re-advertises an x-PMSI/IMET route, the route
MUST carry a DCB-flag if and only if the label in its PTA is assigned MUST carry a DCB-flag if and only if the label in its PTA is assigned
from the DCB. from the DCB.
If the VPN/BD/ES/PMSI label is assigned from one of those few If the VPN/BD/ES/PMSI label is assigned from one of those few
context-specific label spaces, a Context-Specific Label Space ID context-specific label spaces, a Context-Specific Label Space ID EC
Extended Community MUST be attached to the route. The ID-Type in the MUST be attached to the route. The ID-Type in the EC is set to 0,
EC is set to 0 and the ID-Value is set to a label allocated from the and the ID-Value is set to a label allocated from the DCB and
DCB and identifies the context-specific label space. When an ingress identifies the context-specific label space. When an ingress PE
PE sends traffic, it imposes the DCB label that identifies the sends traffic, it imposes the DCB label that identifies the context-
context-specific label space after it imposes the label (that is specific label space after it imposes the label (that is advertised
advertised in the Label field of the PTA in the x-PMSI/IMET route) in the Label field of the PTA in the x-PMSI/IMET route) for the VPN/
for the VPN/BD and/or the label (that is advertised in the ESI Label BD and/or the label (that is advertised in the ESI Label EC) for the
EC) for the ESI, and then imposes the encapsulation for the transport ESI, and then imposes the encapsulation for the transport tunnel.
tunnel.
When a PE receives an x-PMSI/IMET route with the Context-Specific When a PE receives an x-PMSI/IMET route with the Context-Specific
Label Space ID EC, it MUST place an entry in its default MPLS Label Space ID EC, it MUST place an entry in its default MPLS
forwarding table to map the label in the EC to a corresponding forwarding table to map the label in the EC to a corresponding
context-specific label table. That table is used for the next label context-specific label table. That table is used for the next label
lookup for incoming data traffic with the label signaled in the EC. lookup for incoming data traffic with the label signaled in the EC.
Then, the receiving PE MUST place an entry for the label in the PTA Then, the receiving PE MUST place an entry for the label that is in
or ESI Label EC into either the default MPLS forwarding table (if the the PTA or ESI Label EC in either the default MPLS forwarding table
route carries the DCB-flag) or the context-specific label table (if (if the route carries the DCB-flag) or the context-specific label
the Context-Specific Label Space ID EC is present) according to the table (if the Context-Specific Label Space ID EC is present)
x-PMSI/IMET route. according to the x-PMSI/IMET route.
An x-PMSI/IMET route MUST NOT both carry the DCB-flag and the An x-PMSI/IMET route MUST NOT carry both the DCB-flag and the
Context-Specific Label Space ID EC. A received route with both the Context-Specific Label Space ID EC. A received route with both the
DCB-flag set and the Context Label Space ID EC attached MUST be DCB-flag set and the Context-Specific Label Space ID EC attached MUST
treated as withdrawn. If neither the DCB-flag nor the Context- be treated as withdrawn. If neither the DCB-flag nor the Context-
Specific Label Space ID EC is attached, the label in the PTA or ESI Specific Label Space ID EC is attached, the label in the PTA or ESI
Label EC MUST be treated as the upstream-assigned from the label Label EC MUST be treated as the upstream-assigned label from the
space of the source PE, and procedures in [RFC6514][RFC7432] MUST be label space of the source PE, and procedures provided in [RFC6514]
followed. and [RFC7432] MUST be followed.
If a PE originates two x-PMSI/IMET routes with the same tunnel, it If a PE originates two x-PMSI/IMET routes with the same tunnel, it
MUST ensure one of the following so that the PE receiving the routes MUST ensure that one of the following scenarios applies, so that the
can correctly interpret the label that follows the tunnel PE receiving the routes can correctly interpret the label that
encapsulation of data packets arriving via the tunnel. follows the tunnel encapsulation of data packets arriving via the
tunnel:
* They MUST all have the DCB-flag, or, * They MUST all have the DCB-flag,
* They MUST all carry the Context-Specific Label Space ID EC, or, * They MUST all carry the Context-Specific Label Space ID EC,
* None of them has the DCB-flag, or, * None of them have the DCB-flag, or
* None of them carry the Context-Specific Label Space ID EC. * None of them carry the Context-Specific Label Space ID EC.
Otherwise, a receiving PE MUST treat the routes as if they were Otherwise, a receiving PE MUST treat the routes as if they were
withdrawn. withdrawn.
4. Security Considerations 5. Security Considerations
This document allows three methods (Section 2.2.3) of label This document allows three methods (Section 3.3) of label allocation
allocation for MVPN [RFC6514] or EVPN [RFC7432] PEs and specifies for MVPN PEs [RFC6514] or EVPN PEs [RFC7432] and specifies
corresponding signaling and procedures. The first method is the corresponding signaling and procedures. The first method (Option 1)
equivalent of using common SRGBs [RFC8402] from the regular per is the equivalent of using common SRGBs [RFC8402] from the regular
platform label space. The second one is the equivalent of using per-platform label space. The second method (Option 2) is the
common SRGBs from a third party label space [RFC5331]. The third equivalent of using common SRGBs from a third-party label space
method is a variation of the second, in that the third party label [RFC5331]. The third method (Option 3) is a variation of the second
space is divided into disjoint blocks for use by different PEs, who in that the third-party label space is divided into disjoint blocks
will use labels from their respective block to send traffic. In all for use by different PEs, where each PE will use labels from its
cases, a receiving PE is able to identify one of a few label respective block to send traffic. In all cases, a receiving PE is
forwarding tables to forward incoming labeled traffic. able to identify one of the few label forwarding tables to forward
incoming labeled traffic.
None of the [RFC6514], [RFC7432], [RFC8402] and [RFC5331] [RFC6514], [RFC7432], [RFC8402], and [RFC5331] do not list any
specifications lists any security concerns related to label security concerns related to label allocation methods, and this
allocation methods, and this document does not introduce new security document does not introduce any new security concerns in this regard.
concerns either.
5. IANA Considerations 6. IANA Considerations
IANA has made the following assignments: IANA has made the following assignments:
* Bit 47 (DCB) from the "Additional PMSI Tunnel Attribute Flags" * Bit 47 (DCB) in the "Additional PMSI Tunnel Attribute Flags"
registry registry:
Bit Flag Name Reference
-------- ---------------------- -------------
47 DCB (temporary) This document
* Sub-type 0x08 for "Context-Specific Label Space ID Extended
Community" from the "Transitive Opaque Extended Community Sub-
Types" registry
Sub-Type Value Name Reference
-------------- ---------------------- -------------
0x08 Context-Specific Label Space ID This document
Extended Community
IANA is requested to create a "Context-Specific Label Space ID Type" +==========+======+===========+
registry in the "Border Gateway Protocol (BGP) Extended Communities" | Bit Flag | Name | Reference |
group. The registration procedure is First Come First Served. The +==========+======+===========+
initial assignment is as follows: | 47 | DCB | RFC 9573 |
+----------+------+-----------+
ID Type Name Reference Table 1
------- ---------------------- -------------
0 MPLS Label This document
1-254 unassigned
255 reserved
6. Acknowledgements * Sub-type 0x08 for "Context-Specific Label Space ID Extended
Community" in the "Transitive Opaque Extended Community Sub-Types"
registry:
The authors thank Stephane Litkowski, Ali Sajassi and Jingrong Xie +================+=============================+===========+
for their review of, comments on and suggestions for this document. | Sub-Type Value | Name | Reference |
+================+=============================+===========+
| 0x08 | Context-Specific Label | RFC 9573 |
| | Space ID Extended Community | |
+----------------+-----------------------------+-----------+
7. Contributors Table 2
The following also contributed to this document. IANA has created the "Context-Specific Label Space ID Type" registry
within the "Border Gateway Protocol (BGP) Extended Communities" group
of registries. The registration procedure is First Come First Served
[RFC8126]. The initial assignment is as follows:
Selvakumar Sivaraj +============+============+===========+
Juniper Networks | Type Value | Name | Reference |
+============+============+===========+
| 0 | MPLS Label | RFC 9573 |
+------------+------------+-----------+
| 1-254 | Unassigned | |
+------------+------------+-----------+
| 255 | Reserved | |
+------------+------------+-----------+
Email: ssivaraj@juniper.net Table 3
8. References 7. References
8.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>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>. February 2006, <https://www.rfc-editor.org/info/rfc4360>.
skipping to change at page 15, line 48 skipping to change at line 712
[RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for
P-Multicast Service Interface Tunnel Attribute Flags", P-Multicast Service Interface Tunnel Attribute Flags",
RFC 7902, DOI 10.17487/RFC7902, June 2016, RFC 7902, DOI 10.17487/RFC7902, June 2016,
<https://www.rfc-editor.org/info/rfc7902>. <https://www.rfc-editor.org/info/rfc7902>.
[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>.
8.2. Informative References 7.2. Informative References
[I-D.ietf-bess-evpn-bum-procedure-updates]
Zhang, Z. J., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates on EVPN BUM Procedures", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-bum-
procedure-updates-14, 18 November 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-bum-procedure-updates-14>.
[I-D.ietf-bier-evpn] [BIER-EVPN]
Zhang, Z., Przygienda, A., Sajassi, A., and J. Rabadan, Zhang, Z., Przygienda, A., Sajassi, A., and J. Rabadan,
"EVPN BUM Using BIER", Work in Progress, Internet-Draft, "EVPN BUM Using BIER", Work in Progress, Internet-Draft,
draft-ietf-bier-evpn-10, 4 October 2023, draft-ietf-bier-evpn-14, 2 January 2024,
<https://datatracker.ietf.org/api/v1/doc/document/draft- <https://datatracker.ietf.org/doc/html/draft-ietf-bier-
ietf-bier-evpn/>. evpn-14>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008, RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>. <https://www.rfc-editor.org/info/rfc5331>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
skipping to change at page 16, line 47 skipping to change at line 757
and A. Dolganow, "Multicast VPN Using Bit Index Explicit and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>. 2019, <https://www.rfc-editor.org/info/rfc8556>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660, Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019, DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>. <https://www.rfc-editor.org/info/rfc8660>.
[RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or
Multicast (BUM) Procedures", RFC 9572,
DOI 10.17487/RFC9572, April 2024,
<https://www.rfc-editor.org/info/rfc9572>.
Acknowledgements
The authors thank Stephane Litkowski, Ali Sajassi, and Jingrong Xie
for their reviews of, comments on, and suggestions for this document.
Contributors
The following individual also contributed to this document:
Selvakumar Sivaraj
Juniper Networks
Email: ssivaraj@juniper.net
Authors' Addresses Authors' Addresses
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
Email: zzhang@juniper.net Email: zzhang@juniper.net
Eric Rosen Eric Rosen
Individual Individual
Email: erosen52@gmail.com Email: erosen52@gmail.com
Wen Lin Wen Lin
Juniper Networks Juniper Networks
Email: wlin@juniper.net Email: wlin@juniper.net
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
 End of changes. 124 change blocks. 
435 lines changed or deleted 466 lines changed or added

This html diff was produced by rfcdiff 1.48.