rfc9573xml2.original.xml   rfc9573.xml 
<?xml version="1.1" encoding="US-ASCII"?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bess-mvpn-ev
<?rfc tocdepth="3"?> pn-aggregation-label-14" number="9573" ipr="pre5378Trust200902" submissionType="
<?rfc tocindent="yes"?> IETF" category="std" consensus="true" updates="6514, 7432, 7582" obsoletes="" xm
<?rfc symrefs="yes"?> l:lang="en" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" versio
<?rfc sortrefs="yes"?> n="3">
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?> <!-- xml2rfc v2v3 conversion 3.18.1 -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" updates="7432, 6514, 7582" docName="draft-ietf-bess-mvpn-evp
n-aggregation-label-14" ipr="trust200902">
<front> <front>
<title abbrev="mvpn-evpn-aggregation-label">MVPN/EVPN Tunnel Aggregation wit h Common Labels</title> <title abbrev="MVPN/EVPN Aggregation Labels">MVPN/EVPN Tunnel Aggregation wi th Common Labels</title>
<seriesInfo name="RFC" value="9573"/>
<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>zzhang@juniper.net</email> <email>zzhang@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Eric Rosen" initials="E." surname="Rosen"> <author fullname="Eric Rosen" initials="E." surname="Rosen">
<organization>Individual</organization> <organization>Individual</organization>
<address> <address>
<email>erosen52@gmail.com</email> <email>erosen52@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Wen Lin" initials="W." surname="Lin"> <author fullname="Wen Lin" initials="W." surname="Lin">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>wlin@juniper.net</email> <email>wlin@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Zhenbin Li" initials="Z." surname="Li"> <author fullname="Zhenbin Li" initials="Z." surname="Li">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<email>lizhenbin@huawei.com</email> <email>lizhenbin@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="IJsbrand Wijnands" initials="IJ." surname="Wijnands">
<author fullname="IJsbrand Wijnands" initials="I." surname="Wijnands">
<organization>Individual</organization> <organization>Individual</organization>
<address> <address>
<email>ice@braindump.be</email> <email>ice@braindump.be</email>
</address> </address>
</author> </author>
<date year="2024" month="May" />
<area>rtg</area>
<workgroup>bess</workgroup>
<date year="2023"/> <keyword>DCB</keyword>
<keyword>Tunnel Aggregation</keyword>
<workgroup>BESS</workgroup>
<abstract> <abstract>
<t> <t>
The MVPN specifications allow a single Point-to-Multipoint (P2MP) The Multicast VPN (MVPN) specifications allow a single Point-to-Multipo
tunnel to carry traffic of multiple IP VPNs (abbreviated as VPNs). int (P2MP)
tunnel to carry traffic of multiple IP VPNs (referred to as VPNs in thi
s document).
The EVPN specifications The EVPN specifications
allow a single P2MP tunnel to carry traffic of multiple Broadcast allow a single P2MP tunnel to carry traffic of multiple Broadcast
Domains (BDs). These features require the ingress router of the P2MP Domains (BDs). These features require the ingress router of the P2MP
tunnel to allocate an upstream-assigned MPLS label for each VPN or for tunnel to allocate an upstream-assigned MPLS label for each VPN or for
each BD. A packet sent on a P2MP tunnel then carries the label that is each BD. A packet sent on a P2MP tunnel then carries the label that is
mapped to its VPN or BD (in some cases, a distinct upstream-assigned mapped to its VPN or BD (in some cases, a distinct upstream-assigned
label is needed for each flow.) Since each ingress router allocates lab els label is needed for each flow.) Since each ingress router allocates lab els
independently, with no coordination among the ingress routers, the independently, with no coordination among the ingress routers, the
egress routers may need to keep track of a large number of labels. The egress routers may need to keep track of a large number of labels. The
number of labels may need to be as large (or larger) than the product number of labels may need to be as large as, or larger than, the produc t
of the number of ingress routers times the number of VPNs or BDs. of the number of ingress routers times the number of VPNs or BDs.
However, the number of labels can be greatly reduced if the association However, the number of labels can be greatly reduced if the association
between a label and a VPN or BD is made by provisioning, so that all between a label and a VPN or BD is made by provisioning, so that all
ingress routers assign the same label to a particular VPN or BD. ingress routers assign the same label to a particular VPN or BD.
New procedures are needed in order to take advantage of such New procedures are needed in order to take advantage of such
provisioned labels. These new procedures also apply to provisioned labels. These new procedures also apply to
Multipoint-to-Multipoint (MP2MP) tunnels. Multipoint-to-Multipoint (MP2MP) tunnels.
This document updates RFCs 6514, 7432 and 7582 by This document updates RFCs 6514, 7432, and 7582 by
specifying the necessary procedures. specifying the necessary procedures.
</t> </t>
</abstract> </abstract>
<note title="Requirements Language">
<t> 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 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.
</t>
</note>
</front> </front>
<middle> <middle>
<section title="Terminology"> <section numbered="true" toc="default">
<t>Familiarity with MVPN/EVPN protocols and procedures is assumed. <name>Introduction</name>
Some terminologies are listed below for convenience. <t>
<list style="symbols"> A Multicast VPN (MVPN) can use Point-to-Multipoint (P2MP) tunnels (set up b
<t>VPN: Virtual Private Network. In this document, it is specifi y RSVP-TE, Multipoint LDP (mLDP), or PIM) to
cally IP VPN <xref target="RFC4364"/>.
</t>
<t>BUM <xref target="RFC7432"/>: Broadcast, Unknown unicast, or Multicast (t
raffic).
</t>
<t>BD <xref target="RFC7432"/>: Broadcast Domain.
</t>
<t>EC <xref target="RFC4360"/>: Extended Community.
</t>
<t>PMSI <xref target="RFC6513"/>: Provider Multicast Service Interface -
a pseudo overlay interface for PEs to send certain overlay/customer multic
ast traffic via underlay/provider
tunnels. It includes <br/>I/S-PMSI (often referred to as x-PMSI) for
Inclusive/Selective PMSI. A PMSI is instantiated by the underlay/provider
tunnel.
</t>
<t>Inclusive PMSI: A PMSI that enables traffic to be sent to all PEs of a VP
N/BD.
The underlay/provider tunnel that instantiates the Inclusive PMSI is referre
d to as an inclusive tunnel.
</t>
<t>Selective PMSI: A PMSI that enables traffic to be sent to a subset of PEs
of a VPN/BD.
The underlay/provider tunnel that instantiates the Selective PMSI is referre
d to as a selective tunnel.
</t>
<t>Aggregate Tunnel: a tunnel that instantiates x-PMSIs of multiple MVPNs or
EVPN BDs.
</t>
<t>IMET <xref target="RFC7432"/>: Inclusive Multicast Ethernet Tag route. An
EVPN specific name
for I-PMSI A-D route.
</t>
<t>PTA <xref target="RFC6514"/>: PMSI Tunnel Attribute. A BGP attribute that
may be attached to
an BGP-MVPN/EVPN x-PMXI A-D routes.
</t>
<t>RBR: Regional Border Routers. Border routers between segmentation regions
that participate
in segmentation procedures.
</t>
<t>(C-S,C-G): A Customer/overlay &lt;S,G&gt; multicast flow.
</t>
<t>(C-*,C-G): Customer/overlay &lt;*,G&gt; multicast flows.
</t>
<t>(C-*,C-*): All Customer/overlay multicast flows.
</t>
<t>ESI <xref target="RFC7432"/>: Ethernet Segment Identifier.
</t>
<t>ESI Label<xref target="RFC7432"/>: A label that identifies an Ethernet Se
gment
</t>
<t>SRGB <xref target="RFC8402"/>: Segment Routing (SR) Global Block, the set
of global segments in the SR domain.
In SR-MPLS <xref target="RFC8660"/>, SRGB is a local property of a node and
identifies the set of local labels reserved for global segments.
</t>
<t>DCB: Domain-wide Common Block, a common block of labels reserved on all n
odes in a domain.
</t>
<t>Context-specific Label Space [RFC5331]: A router may maintain additional
label spaces besides
its default label space.
When the 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 of those additional label sp
aces is to be used
to look up the label, hence those label spaces are referred to as context-sp
ecific label spaces.
</t>
<t>Upstream-assigned [RFC5331]: When the label at the top of the label stack
is not assigned by
the router receiving the traffic from its default label space, the label is
referred to as upstream-assigned. Otherwise, it is
downstream-assigned. An upstream-assigned label must be looked up in a conte
xt-specific label
space specific for the assigner.
</t>
</list>
</t>
</section>
<section title="Introduction">
<t>
MVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) to
transport customer multicast traffic across a service provider's transport customer multicast traffic across a service provider's
backbone network. Often, a given P2MP tunnel carries the traffic of backbone network. Often, a given P2MP tunnel carries the traffic of
only a single VPN. There are however procedures defined that allow a only a single VPN. However, there are procedures defined that allow a
single P2MP tunnel to carry traffic of multiple VPNs. In this case, 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 P2MP tunnel is called an "aggregate tunnel". The Provider Edge (PE) ro uter that is
the ingress node of an aggregate P2MP tunnel allocates an the ingress node of an aggregate P2MP tunnel allocates an
"upstream-assigned MPLS label" [RFC5331] for each VPN, and each packet "upstream-assigned MPLS label" <xref target="RFC5331" format="default"/> fo r each VPN, and each packet
sent on the P2MP tunnel carries the upstream-assigned MPLS label that sent on the P2MP tunnel carries the upstream-assigned MPLS label that
the ingress PE has bound to the packet's VPN. the ingress PE has bound to the packet's VPN.
</t> </t>
<t> <t>
Similarly, EVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) Similarly, an EVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM)
to transport BUM traffic (Broadcast traffic, Unicast traffic with an to transport Broadcast, Unknown Unicast, or Multicast (BUM) traffic across
Unknown address, or Multicast traffic), across the provider network. the provider network.
Often a P2MP tunnel carries the traffic of only a single BD. However, 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 there are procedures defined that allow a single P2MP tunnel to be an
"aggregate tunnel" that carries traffic of multiple BDs. The procedures aggregate tunnel that carries traffic of multiple BDs. The procedures
are analogous to the MVPN procedures -- the PE router that is the are analogous to the MVPN procedures -- the PE router that is the
ingress node of an aggregate P2MP tunnel allocates an upstream-assigned 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 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 the upstream-assigned MPLS label that the ingress PE has bound to the
packet's BD. packet's BD.
</t> </t>
<t> <t>
MVPN and EVPN can also use BIER [RFC8279] to transmit VPN multicast An MVPN or EVPN can also use Bit Index Explicit Replication (BIER) <xref ta
traffic or EVPN BUM traffic [RFC8556] rget="RFC8279" format="default"/> to transmit VPN multicast
<xref target="I-D.ietf-bier-evpn"/>. traffic <xref target="RFC8556" format="default"/> or EVPN BUM traffic
<xref target="I-D.ietf-bier-evpn" format="default"/>.
Although BIER does not explicitly set up P2MP Although BIER does not explicitly set up P2MP
tunnels, from the perspective of MVPN/EVPN, the use of BIER transport 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 is very similar to the use of aggregate P2MP tunnels. When BIER is
used, the PE transmitting a packet (the "BFIR" [RFC8279]) must used, the PE transmitting a packet (the "Bit-Forwarding Ingress Router" (BF IR) <xref target="RFC8279" format="default"/>) must
allocate an upstream-assigned MPLS label for each VPN or BD, and the allocate an upstream-assigned MPLS label for each VPN or BD, and the
packets transmitted using BIER transport always carry the label that packets transmitted using BIER transport always carry the label that
identifies their VPN or BD. (See [RFC8556] and <xref target="I-D.ietf-bier- evpn"/> for the identifies their VPN or BD. (See <xref target="RFC8556" format="default"/> and <xref target="I-D.ietf-bier-evpn" format="default"/> for
details.) In the remainder of this document, we will use the term details.) In the remainder of this document, we will use the term
"aggregate tunnels" to include both P2MP tunnels and BIER transport. "aggregate tunnels" to include both P2MP tunnels and BIER transport.
</t> </t>
<t> <t>
When an egress PE receives a packet from an aggregate tunnel, it must 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 look at the upstream-assigned label carried by the packet and must
interpret that label in the context of the ingress PE. Essentially, interpret that label in the context of the ingress PE. Essentially,
for each ingress PE, the egress PE has a context-specific label space for each ingress PE, the egress PE has a context-specific label space
[RFC5331] that matches the default label space from which <xref target="RFC5331" format="default"/> that matches the default label sp ace from which
the ingress PE assigns the upstream-assigned labels. the ingress PE assigns the upstream-assigned labels.
When an egress PE looks up When an egress PE looks up
the upstream-assigned label carried by a given packet, it looks it 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. 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 How an egress PE identifies the ingress PE of a given packet depends on the
tunnel type. tunnel type.
</t> </t>
<section title="Problem Description" anchor="problem">
<t> <section>
<name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>Familiarity with MVPN/EVPN protocols and procedures is assumed.
Some terms are listed below for convenience.
</t>
<dl spacing="normal">
<dt>VPN:</dt>
<dd>Virtual Private Network. In this document, "VPN" specifically refer
s to an IP
VPN <xref target="RFC4364" format="default"/>.
</dd>
<dt>BUM <xref target="RFC7432" format="default"/>:</dt><dd>Broadcast, U
nknown Unicast, or Multicast (traffic).</dd>
<dt>BD <xref target="RFC7432" format="default"/>:</dt><dd>Broadcast Do
main.</dd>
<dt>EC <xref target="RFC4360" format="default"/>:</dt><dd>Extended Com
munity.
</dd>
<dt>PMSI <xref target="RFC6513" format="default"/>:</dt>
<dd>Provider Multicast Service Interface. A pseudo-overlay interface
for PEs to send certain overlay/customer multicast traffic via
underlay/provider tunnels. It includes <br/>Inclusive/Selective PMSIs (I
/S-PMSIs) (often referred
to as x-PMSIs). A PMSI is instantiated by
the underlay/provider tunnel.
</dd>
<dt>Inclusive PMSI (I-PMSI):</dt>
<dd>A PMSI that enables traffic to be sent to all PEs of a VPN/BD.
The underlay/provider tunnel that instantiates the I-PMSI is
referred to as an inclusive tunnel.
</dd>
<dt>Selective PMSI (S-PMSI):</dt>
<dd>A PMSI that enables traffic to be sent to a subset of PEs of a
VPN/BD. The underlay/provider tunnel that instantiates the
S-PMSI is referred to as a selective tunnel.
</dd>
<dt>Aggregate Tunnel:</dt>
<dd>A tunnel that instantiates x-PMSIs of multiple MVPNs or EVPN
BDs.
</dd>
<dt>IMET <xref target="RFC7432" format="default"/>:</dt>
<dd>Inclusive Multicast Ethernet Tag. &nbsp;An EVPN-specific name
for an I-PMSI Auto-Discovery (A-D) route.
</dd>
<dt>PTA <xref target="RFC6514" format="default"/>:</dt>
<dd>PMSI Tunnel Attribute. A BGP attribute that may be attached to
a BGP-MVPN/EVPN x-PMSI A-D route.
</dd>
<dt>ASBR:</dt>
<dd>Autonomous System Border Router.</dd>
<dt>RBR:</dt>
<dd>Regional Border Router. A border router between segmentation
regions that participates in segmentation procedures.
</dd>
<dt>(C-S,C-G):</dt>
<dd>A Customer/overlay &lt;S,G&gt; multicast flow.
</dd>
<dt>(C-*,C-G):</dt>
<dd>Customer/overlay &lt;*,G&gt; multicast flows.
</dd>
<dt>(C-*,C-*):</dt>
<dd>All Customer/overlay multicast flows.
</dd>
<dt>ES:</dt>
<dd>Ethernet Segment.</dd>
<dt>ESI <xref target="RFC7432" format="default"/>:</dt>
<dd>ES Identifier.
</dd>
<dt>ESI Label <xref target="RFC7432" format="default"/>:</dt>
<dd>A label that identifies an ES.
</dd>
<dt>SRGB <xref target="RFC8402" format="default"/>:</dt>
<dd>Segment Routing (SR) Global Block. The set of global segments in
the SR domain. In SR-MPLS <xref target="RFC8660"
format="default"/>, an SRGB is a local property of a node and
identifies the set of local labels reserved for global segments.
</dd>
<dt>DCB:</dt>
<dd>Domain-wide Common Block. A common block of labels reserved on all
nodes in a domain.
</dd>
<dt>Context-Specific Label Space <xref target="RFC5331" format="defaul
t"/>:</dt>
<dd>A router may maintain additional label spaces besides its
default label space. When the 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 of those additional label spaces is
to be used to look up the label; hence, those label spaces are
referred to as context-specific label spaces.
</dd>
<dt>Upstream Assigned <xref target="RFC5331"
format="default"/>:</dt>
<dd> When the label at the top of the label stack is not assigned by
the router receiving the traffic from its default label space, the
label is referred to as upstream assigned. Otherwise, it is
downstream assigned. An upstream-assigned label must be looked up in
a context-specific label space specific for the assigner.
</dd>
</dl>
</section>
</section>
<section anchor="problem" numbered="true" toc="default">
<name>Problem Description</name>
<t>
Note that the upstream-assigned label procedures may require a very large n umber of labels. Note that the upstream-assigned label procedures may require a very large n umber of labels.
Suppose an MVPN or EVPN deployment has 1001 PEs, each hosting 1000 Suppose that an MVPN or EVPN deployment has 1001 PEs, each hosting 1000
VPN/BDs. Each ingress PE has to assign 1000 labels, and each egress PE VPNs/BDs. Each ingress PE has to assign 1000 labels, and each egress PE
has to be prepared to interpret 1000 labels from each of the ingress has to be prepared to interpret 1000 labels from each of the ingress
PEs. Since each ingress PE allocates labels from its own label PEs. Since each ingress PE allocates labels from its own label
space and does not coordinate label assignments with others, space and does not coordinate label assignments with others,
each egress PE must be prepared to interpret 1,000,000 each egress PE must be prepared to interpret 1,000,000
upstream-assigned labels (across 1000 context-specific label spaces - one f or upstream-assigned labels (across 1000 context-specific label spaces -- one for
each ingress PE). This is an evident scaling problem. each ingress PE). This is an evident scaling problem.
</t> </t>
<t> <t>
So far, few if any MVPN/EVPN deployments use aggregate So far, few if any MVPN/EVPN deployments use aggregate
tunnels, so this problem has not surfaced. However, the use of aggregate tunnels, so this problem has not surfaced. However, the use of aggregate
tunnels is likely to increase due to the following two factors: tunnels is likely to increase due to the following two factors:
<list style="symbols"> </t>
<t> <ul spacing="normal">
In EVPN, a single customer ("tenant") may have a large number of BDs, <li>In an EVPN, a single customer ("tenant") may have a large number o
and the use of aggregate RSVP-TE or mLDP P2MP tunnels may become f
important, since each tunnel creates state at the intermediate nodes. BDs, and the use of aggregate RSVP-TE or mLDP P2MP tunnels may
</t> become important, since each tunnel creates state at the
<t> intermediate nodes.</li>
The use of BIER as transport for MVPN/EVPN is becoming more and more <li>The use of BIER as the transport for an MVPN/EVPN is becoming more
attractive and feasible. and
</t> more attractive and feasible.</li>
</list> </ul>
</t> <t>A similar problem also exists with EVPN ESI labels used for multihoming.
<!--t>Note there are pros and cons with traditional P2MP tunnel aggregation A PE attached to a multihomed ES advertises an ESI label in its Ethernet
(vs. BIER), which are A-D per ES route.
already discussed in Section 2.1.1 of [RFC6513]. This document just
specifies a way to increase label scaling when tunnel aggregation is
used.
</t-->
<t>A similar problem also exists with EVPN ESI labels used for multi-homing.
A PE attached to a multi-homed Ethernet Segment (ES) advertises an ESI
label in its Ethernet A-D per Ethernet Segment Route.
The PE imposes the label The PE imposes the label
when it sends frames received from the ES to other PEs via a P2MP/BIER when it sends frames received from the ES to other PEs via a P2MP/BIER
tunnel. A receiving PE that is attached to the source ES will know from tunnel. A receiving PE that is attached to the source ES will know from
the ESI label that the packet the ESI label that the packet
originated on the source ES, and thus will not transmit the packet on originated on the source ES and thus will not transmit the packet on
its local attachment circuit to that ES. From the receiving its local Attachment Circuit to that ES. From the receiving
PE's point of view, the ESI label is (upstream-)assigned from the source PE's point of view, the ESI label is (upstream) assigned from the source
PE's label space, so the receiving PE needs to maintain context-specific label PE's label space, so the receiving PE needs to maintain context-specific label
tables, one for each source PE, just like the VRF/BD label case tables, one for each source PE, just like the VPN/BD label case
above. If there are 1,001 PEs, each attached to 1,000 ESes, this can above. If there are 1001 PEs, each attached to 1000 ESs, this can
require each PE to understand 1,000,000 ESI labels. Notice that the require each PE to understand 1,000,000 ESI labels. Notice that the
issue exists even when no P2MP tunnel aggregation (i.e. one tunnel used issue exists even when no P2MP tunnel aggregation (i.e., one tunnel used
for multiple BDs) is used. for multiple BDs) is used.
</t> </t>
</section> </section>
<section title="Proposed Solution" anchor="solution"> <section anchor="solution" numbered="true" toc="default">
<t> <name>Proposed Solutions</name>
<t>
The number of labels could be greatly reduced if a central entity The number of labels could be greatly reduced if a central entity
in the provider network in the provider network
assigned a label to each VPN, BD, or ES, and if all PEs used that same 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. Then the number of label to represent a given VPN, BD, or ES. Then, the number of
labels needed would just be the sum of the number of VPNs, labels needed would just be the sum of the number of VPNs,
BD, and/or ESes. BDs, and/or ESs.
</t> </t>
<t> <t>
One method of achieving this is to reserve a portion of the default label s pace One method of achieving this is to reserve a portion of the default label s pace
for assignment by a central entity. We refer to this reserved for assignment by a central entity. We refer to this reserved
portion as the "Domain-wide Common Block" (DCB) of labels. This is portion as the DCB of labels. This is analogous to the concept of using id
analogous to the identical "Segment Routing Global Block" (SRGB) entical SRGBs
on all nodes that is described in [RFC8402]. on all nodes, as described in <xref target="RFC8402"/>.
A PE that is attached (via L3VPN VRF A PE that is attached (via L3VPN Virtual Routing and Forwarding (VRF)
interfaces or EVPN Access Circuits) would know by provisioning which interfaces or EVPN Attachment Circuits) would know by provisioning which
label from the DCB corresponds to which of its locally attached VPNs, label from the DCB corresponds to which of its locally attached VPNs,
BDs, or ESes. BDs, or ESs.
</t> </t>
<t>For example, all PEs could reserve a DCB [1000, 2000] and they are <t>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 all be provisioned so that label 1000 maps to VPN 0, label 1001 maps to VPN
so forth. Now only 1000 labels instead of 1,000,000 labels 1,
and so forth. Now, only 1000 labels instead of 1,000,000 labels
are needed for 1000 VPNs. are needed for 1000 VPNs.
</t> </t>
<t>The definition of "domain" is loose - it simply includes <t>In this document, "domain" is defined loosely; it simply includes
all the routers that share the same DCB. In this document, it only needs all the routers that share the same DCB, and it only needs to
to include all PEs of an MVPN/EVPN network<!--, or in case of tunnel include all PEs of an MVPN/EVPN.
segmentation <xref target="RFC6514"/> it may only need to include all PEs </t>
and border nodes of a segmentation region (see more details in <xref target <t>
="seg"/>)-->.
</t>
<t>
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 routers. making it not much different from a common SRGB across all the routers.
However, that is not necessary as the labels used by PEs for the However, that is not necessary, as the labels used by PEs for the
purposes defined in purposes defined in
this document will only rise to the top of the label stack when traffic this document will only rise to the top of the label stack when traffic
arrives at the PEs. Therefore, it is better to not include internal P routers arrives at the PEs. Therefore, it is better to not include internal P routers
in the "domain". That way they do not have to set aside the same DCB used for in the "domain". That way, they do not have to set aside the same DCB used fo
the purposes in this document. r
</t> the purposes defined in this document.
<t> </t>
<t>
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<!--'s default context-specific label spaces that are independent of each PE. For example,
label space (that the DCB belongs to)-->. For example, if it is too difficu if it is too difficult
lt to have a DCB of 10,000 labels across all PEs for all the VPNs/BDs/ESs
to have a DCB of 10,000 labels across all PEs for all the VPNs/BDs/ESes
that need to be supported, a separate context-specific label space can be that need to be supported, a separate context-specific label space can be
dedicated to those 10,000 labels. Each separate context-specific label spa ce is dedicated to those 10,000 labels. Each separate context-specific label spa ce is
identified in the forwarding plane by a label from the DCB (which does not 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-space-identifying DCB need to be large). Each PE is provisioned with the label-space-identifying DCB
label and the common VPN/BD/ES labels allocated from that context-specific label space. label and the common VPN/BD/ES labels allocated from that context-specific label space.
When sending traffic, an ingress PE imposes all necessary service When sending traffic, an ingress PE imposes all necessary service
labels (for the VPN/BD/ES) first, then imposes the label-space-identifying labels (for the VPN/BD/ES) first, then imposes the label-space-identifying
DCB label. From the label-space-identifying DCB label an egress PE can DCB label. From the label-space-identifying DCB label, an egress PE can
determine the label space where the inner VPN/BD/ES label is looked up. determine the label space where the inner VPN/BD/ES label is looked up.
</t> </t>
<t> <t>
The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes that The MVPN/EVPN signaling defined in <xref target="RFC6514"/> and <xref target=
"RFC7432"/> assumes that
certain MPLS labels are allocated from a context-specific label space for a certain MPLS labels are allocated from a context-specific label space for a
particular ingress PE. In this document, we augment the signaling particular ingress PE. In this document, we augment the signaling
procedures so that it is possible to signal that a particular label is procedures so that it is possible to signal that a particular label is
from the DCB, rather than from a context-specific label space for an ingress PE. We from the DCB, rather than from a context-specific label space for an ingress PE. We
also augment the signaling so that it is possible to indicate that a also augment the signaling so that it is possible to indicate that a
particular label is from an identified context-specific label space that is particular label is from an identified context-specific label space that is
not for an ingress PE. not for an ingress PE.
</t> </t>
<t>Notice that, the VPN/BD/ES-identifying labels from the DCB or from <t>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 VXLAN those few context-specific label spaces are very similar to Virtual eXten
. sible Local Area Network (VXLAN) Network Identifiers (VNIs) in VXLANs.
Allocating a label from the DCB or from a context-specific label spaces Allocating a label from the DCB or from a context-specific label space
and communicating them to all PEs is not different from and communicating the label to all PEs is not different from
allocating VNIs, and is feasible especially with controllers. allocating VNIs and is especially feasible with controllers.
</t> </t>
<section title="MP2MP Tunnels"> <section numbered="true" toc="default">
<t>MP2MP tunnels present the same problem (<xref target="problem"/>) <name>MP2MP Tunnels</name>
that can be solved the same way (<xref target="solution"/>), with <t>Multipoint-to-Multipoint (MP2MP) tunnels present the same problem (
<xref target="problem" format="default"/>)
that can be solved the same way (<xref target="solution" format="default"/
>), with
the following additional requirement. the following additional requirement.
</t> </t>
<t> <t>
Per RFC 7582 ("MVPN: Using Bidirectional P-tunnels"), when MP2MP Per <xref target="RFC7582"/> ("Multicast Virtual Private Network (MVPN): Usi
tunnels are used for MVPN, the root of the MP2MP tunnel may ng Bidirectional P-Tunnels"), when MP2MP
need to allocate and advertise "PE Distinguisher Labels" (section 4 tunnels are used for an MVPN, the root of the MP2MP tunnel is required to
of <xref target="RFC6513"/>. These labels are assigned allocate and advertise "PE Distinguisher Labels" (<xref target="RFC6513" sec
tionFormat="of" section="4"/>). These labels are assigned
from the label space used by the root node for its upstream-assigned labels. from the label space used by the root node for its upstream-assigned labels.
</t> </t>
<t> <t>
It is REQUIRED by this document that the PE Distinguisher It is <bcp14>REQUIRED</bcp14> by this document that the PE Distinguisher
labels allocated by a particular node come from the same label space Labels allocated by a particular node come from the same label space
that the node uses to allocate its VPN-identifying labels. that the node uses to allocate its VPN-identifying labels.
</t> </t>
</section> </section>
<section title="Segmented Tunnels" anchor="seg"> <section anchor="seg" numbered="true" toc="default">
<t>There are some additional issues to be considered when MVPN or <name>Segmented Tunnels</name>
EVPN is using "tunnel segmentation" (see [RFC6514], [RFC7524], and <t>There are some additional issues to be considered when an MVPN or
<xref target="I-D.ietf-bess-evpn-bum-procedure-updates"/> Sections 5 and 6) EVPN is using "tunnel segmentation" (see <xref target="RFC6514"/>,
. <xref target="RFC7524"/>, and Sections <xref target="RFC9572"
</t> sectionFormat="bare" section="5"/> and <xref target="RFC9572"
<section title="Selective Tunnels" anchor="select"> sectionFormat="bare" section="6"/> of <xref target="RFC9572"/>).
<t>For "selective tunnels" that instantiate S-PMSIs (see [RFC6513] Sections </t>
2.1.1 and 3.2.1, <section anchor="select" numbered="true" toc="default">
and <xref target="I-D.ietf-bess-evpn-bum-procedure-updates"/> <name>Selective Tunnels</name>
Section 4), the procedures outlined above work only <t>For selective tunnels that instantiate S-PMSIs (see Sections
if tunnel segmentation is not used. <xref target="RFC6513" sectionFormat="bare" section="2.1.1"/> and
</t> <xref target="RFC6513" sectionFormat="bare" section="3.2.1"/> of
<t> <xref target="RFC6513"/> and <xref target="RFC9572"
sectionFormat="of" section="4"/>), the procedures outlined above
work only if tunnel segmentation is not used.
</t>
<t>
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 set 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]. of flows is identified by an S-PMSI A-D route <xref target=
The PTA of the S-PMSI route identifies the tunnel "RFC6514"/>. The PTA of the S-PMSI route identifies the tunnel used to
used to carry the corresponding set of flows. Multiple S-PMSI routes carry the corresponding set of flows. Multiple S-PMSI routes can identify
can identify the same tunnel. the same tunnel.
</t> </t>
<t> <t>
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 boundary "segmentation points". A segmentation point is a node at the boundary
between two "segmentation regions". Let's call these "region A" and between two segmentation regions. Let's call these "region A" and
"region B". A segmentation point is an egress node for one or more "region B". A segmentation point is an egress node for one or more
selective tunnels in region A, and an ingress node for one or more selective tunnels in region A and an ingress node for one or more
selective tunnels in region B. A given segmentation point must be able selective tunnels in region B. A given segmentation point must be able
to receive traffic on a selective tunnel from region A, and label to receive traffic on a selective tunnel from region A and label-switch
switch the traffic to the proper selective tunnel in region B. the traffic to the proper selective tunnel in region B.
</t> </t>
<t>Suppose one <t>Suppose that one
selective tunnel (call it T1) in region A is carrying two flows, Flow-1 selective tunnel (call it "T1") in region A is carrying two flows, Flow-1
and Flow-2, identified by S-PMSI route Route-1 and Route-2, respectively. and Flow-2, identified by S-PMSI routes Route-1 and Route-2, respectively.
However, it is possible that, in region B, Flow-1 is not However, it is possible that in region B, Flow-1 is not
carried by the same selective tunnel that carries Flow-2. Let's carried by the same selective tunnel that carries Flow-2. Let's
suppose that in region B, Flow-1 is carried by tunnel T2 and Flow-2 by suppose that in region B, Flow-1 is carried by tunnel T2 and Flow-2 by
tunnel T3. Then, when the segmentation point receives traffic from T1, tunnel T3. Then, when the segmentation point receives traffic from T1,
it must be able to label switch Flow-1 from T1 to T2, while also label it must be able to label-switch Flow-1 from T1 to T2, while also label-swit
switching Flow-2 from T1 to T3. This implies that Route-1 and Route-2 ching Flow-2 from T1 to T3. This implies that Route-1 and Route-2
must signal different labels in the PTA. For comparison, when must signal different labels in the PTA. For comparison, when
segmentation is not used, they can all use the common per-VPN/BD DCB segmentation is not used, they can all use the common per-VPN/BD DCB
label. label.
</t> </t>
<t>In this case, it is not practical to have a central entity <t>In this case, it is not practical to have a central entity
assign domain-wide unique labels to individual S-PMSI routes. assign domain-wide unique labels to individual S-PMSI routes.
To address this problem, all PEs can be assigned To address this problem, all PEs can be assigned their own
disjoint label blocks in those few context-specific label spaces, and eac disjoint label blocks in those few context-specific label spaces; each PE
h will will
independently allocate labels for segmented S-PMSI from its independently allocate labels for a segmented S-PMSI from its own
assigned label block that is different from any other PE's. For example, assigned label block. For example,
PE1 allocates from label block [101~200], PE2 allocates from label block PE1 allocates from label block [101~200], PE2 allocates from label block
[201~300], and so on. [201~300], and so on.
</t> </t>
<t>Allocating from disjoint label blocks can be used for VPN/BD/ES labels <t>Allocating from disjoint label blocks can be used for VPN/BD/ES l
abels
as well, though it does not address the original scaling issue, because as well, though it does not address the original scaling issue, because
there would be one million labels allocated from those few context there would be 1,000,000 labels allocated from those few context-specific
label spaces in the original example, instead of just one thousand label spaces in the original example, instead of just 1000
common labels. common labels.
</t> </t>
</section> </section>
<section title="Per-PE/Region Tunnels"> <section numbered="true" toc="default">
<t>Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN IMET) or <name>Per-PE/Region Tunnels</name>
per-AS/region (MVPN Inter-AS I-PMSI or EVPN per-Region I-PMSI) tunnels <t>Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN
([RFC6514] [RFC7432] <xref target="I-D.ietf-bess-evpn-bum-procedure-updates" IMET) or per-AS/region (MVPN Inter-AS I-PMSI or EVPN per-region
/>), I-PMSI) tunnels <xref target="RFC6514"/> <xref target="RFC7432"/>
labels need to be allocated per PMSI route. In case of per-PE PMSI route, <xref target="RFC9572" format="default"/>, labels need to be
the labels should be allocated from the label block allocated to the allocated per PMSI route. In the case of a per-PE PMSI route, the la
advertising PE. In case of per-AS/region PMSI route, different ASBR/RBRs bels
(Regional Border Routers) should be allocated from the label block allocated to the
attached to the same source AS/region will advertise the same PMSI route. advertising PE. In the case of a per-AS/region PMSI route, different
The same label could be used when the same route is advertised by ASBRs/RBRs attached to the same source
different ASBRs/RBRs, though that requires coordination and a simpler way AS/region will advertise the same PMSI route. The same label
is for each ASBR/RBR to allocate a label from the label block allocated could be used when the same route is advertised by different
to itself (see <xref target="select"/>). ASBRs/RBRs, though that requires coordination; a simpler way is
</t> for each ASBR/RBR to allocate a label from the label block
<t>In the rest of the document, we call the label allocated for a particular allocated to itself (see <xref target="select"
PMSI a (per-)PMSI label, just like we have (per-)VPN/BD/ES labels. Notice format="default"/>).
that using per-PMSI label in case of per-PE PMSI still has the original </t>
<t>In the rest of this document, we call the label allocated for a p
articular
PMSI a "(per-)PMSI label", just like we have (per-)VPN/BD/ES labels. Noti
ce
that using a per-PMSI label in the case of a per-PE PMSI still has the or
iginal
scaling issue associated with the upstream-assigned label, so per-region scaling issue associated with the upstream-assigned label, so per-region
PMSIs is preferred. Within each AS/region, per-PE PMSIs are still PMSIs are preferred. Within each AS/region, per-PE PMSIs are still
used though they do not go across border and per-VPN/BD labels can still used, though they do not go across borders and per-VPN/BD labels can stil
l
be used. be used.
</t> </t>
<t>Note that, when a segmentation point re-advertises a PMSI route to the <t>Note that when a segmentation point re-advertises a PMSI route to
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 upstream or downstream segment uses Ingress Replication. the upstream or downstream segment uses ingress replication.
</t> </t>
</section> </section>
<section title="Alternative to the per-PMSI Label Allocation"> <section numbered="true" toc="default">
<t>The per-PMSI label allocation in case of segmentation, whether for S-PMSI <name>Alternative to Per-PMSI Label Allocation</name>
or for per-PE/Region I-PMSI, is for the segmentation points to be able <t>Per-PMSI label allocation in the case of segmentation, whether fo
to label switch traffic without having to do IP or MAC lookup in VRFs r S-PMSIs
or per-PE/region I-PMSIs, is applied so that segmentation points are able
to label-switch traffic without having to do IP or Media Access Control (
MAC) lookups in VRFs
(the segmentation points typically do not have those VRFs at all). (the segmentation points typically do not have those VRFs at all).
If the label scaling becomes a concern, alternatively the segmentation Alternatively, if the label scaling becomes a concern, the segmentation
points could use (C-S,C-G) lookup in VRFs for flows identified by points could use (C-S,C-G) lookups in VRFs for flows identified by
the S-PMSIs. This allows the S-PMSIs for the same VPN/BD to share the S-PMSIs. This allows the S-PMSIs for the same VPN/BD to share
a VPN/BD-identifying label that leads to look up in the VRFs. a VPN/BD-identifying label that leads to lookups in the VRFs.
That label needs to be different from the That label needs to be different from the
label used in the per-PE/region I-PMSIs though, so that the segmentation label used in the per-PE/region I-PMSIs though, so that the segmentation
points can label switch other traffic (not identified by those S-PMSIs). points can label-switch other traffic (not identified by those S-PMSIs).
However, this moves the scaling problem from the number of labels to However, this moves the scaling problem from the number of labels to
the number of (C-S/*,C-G) routes in VRFs on the segmentation points. the number of (C-S/*,C-G) routes in VRFs on the segmentation points.
</t> </t>
</section> </section>
</section> </section>
<section title="Summary of Label Allocation Methods" anchor="methods"> <section anchor="methods" numbered="true" toc="default">
<t>In summary, labels can be allocated and advertised in the following ways: <name>Summary of Label Allocation Methods</name>
<list style="numbers"> <t>In summary, labels can be allocated and advertised in the following
<t anchor="dcb-assignment">A central entity allocates per-VPN/BD/ES ways:
labels from the DCB. </t>
PEs advertise the labels with an indication that they are from the DCB. <ol spacing="normal" type="1">
</t> <li anchor="dcb-assignment">A central entity allocates
<t anchor="context-space">A central entity allocates per-VPN/BD/ES per-VPN/BD/ES labels from the DCB. PEs advertise the labels with
labels from a few common an indication that they are from the DCB.
context-specific label spaces, and allocate labels from the DCB to identi </li>
fy
those context-specific label spaces. PEs advertise the VPN/BD labels alon <li anchor="context-space">A central entity allocates
g per-VPN/BD/ES labels from a few common context-specific label
with the context-identifying labels. spaces and allocates labels from the DCB to identify those
</t> context-specific label spaces. PEs advertise the VPN/BD labels
<t anchor="context-block">A central entity assigns disjoint along with the context-identifying labels.
label blocks from a few </li>
context-specific label spaces to each PE, and allocates labels from the D
CB to <li anchor="context-block">A central entity assigns disjoint label
identify those context-specific label spaces. A PE independently allocate blocks from a few context-specific label spaces to each PE and
s a label for a segmented S-PMSI from its assigned label block, allocates labels from the DCB to identify those context-specific
and advertises the label along with the context-identifying label. label spaces. A PE independently allocates a label for a segmented
</t> S-PMSI from its assigned label block and advertises the label
</list> along with the context-identifying label.
</t> </li>
<t>Option <xref target="dcb-assignment" format="counter"/> is simplest, </ol>
<t>Option <xref target="dcb-assignment" format="counter"/> is simplest
,
but it requires that all the PEs set aside a common label block for the but it requires that all the PEs set aside a common label block for the
DCB that is large enough for all the VPNs/BDs/ESes combined. DCB that is large enough for all the VPNs/BDs/ESs combined.
Option <xref target="context-block" format="counter"/> is needed only Option <xref target="context-block" format="counter"/> is needed only
for segmented selective tunnels that are set up dynamically. for segmented selective tunnels that are set up dynamically.
Multiple options could be used in any combination depending on the Multiple options could be used in any combination, depending on the
deployment situation. deployment situation.
</t> </t>
</section> </section>
</section> </section>
</section> <section numbered="true" toc="default">
<section title="Specification"> <name>Specifications</name>
<t> <section numbered="true" toc="default">
</t> <name>Context-Specific Label Space ID Extended Community</name>
<section title="Context-Specific Label Space ID Extended Community"> <t>The Context-Specific Label Space ID Extended Community (EC) is a new
<t>Context-Specific Label Space ID Extended Community (EC) is a new Transiti Transitive Opaque EC with the following structure:
ve Opaque EC with the following structure: </t>
<figure> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
]]></artwork>
</figure> <dl spacing="normal">
<list style="symbols"> <dt>ID-Type:</dt>
<t>ID-Type: A 2-octet field that specifies the type of Label Space ID. <dd>A 2-octet field that specifies the type of Label Space
In this document, the ID-Type is 0, indicating that the ID-Value ID. In this document, the ID-Type is 0, indicating that the
field is a label. ID-Value field is a label.</dd>
</t> <dt>ID-Value:</dt>
<t>ID-Value: A 4-octet field that specifies the value of Label Space ID. <dd>A 4-octet field that specifies the value of the Label Space ID.
When it is a label (with ID-Type 0), the most significant 20-bit When it is a label (with ID-Type 0), the most significant 20-bit portion
is set to the label value. is set to the label value.</dd>
</t> </dl>
</list> <t>This document introduces a DCB-flag (Bit 47 as assigned by IANA) in t
</t> he
<t>This document introduces a DCB flag (Bit 47 as assigned by IANA) in the "Additional PMSI Tunnel Attribute Flags" BGP Extended Community <xref tar
"Additional PMSI Tunnel Attribute Flags" BGP Extended Community [RFC7902] get="RFC7902" format="default"/>.
. </t>
</t> <t>In the remainder of this document, when we say that a BGP-MVPN/EVPN A
<t>In the remainder of the document, when we say a BGP-MVPN/EVPN A-D route -D route
"carries DCB-flag" or "has DCB-flag attached" we mean the following: carries a DCB-flag or has a DCB-flag attached to it, we mean the followin
<list style="symbols"> g:
<t>The route carries a PMSI Tunnel Attribute (PTA) and its Flags field has </t>
the Extension bit set, AND, <ul spacing="normal">
</t> <li>The route carries a PTA and its Flags field has
<t>The route carries an "Additional PMSI Tunnel Attribute Flags" EC the Extension bit set, AND</li>
and its DCB flag is set <li>The route carries an "Additional PMSI Tunnel Attribute Flags" EC
</t> and its DCB-flag is set.</li>
</list> </ul>
</t> </section>
</section> <section numbered="true" toc="default">
<section title="Procedures"> <name>Procedures</name>
<t>The protocol and procedures specified in this section MAY be used <t>The protocol and procedures specified in this section <bcp14>MAY</bcp
when BIER, or P2MP/MP2MP tunnel aggregation 14> be used
is used for MVPN/EVPN, or BIER/P2MP/MP2MP tunnels are used with EVPN when BIER or P2MP/MP2MP tunnel aggregation
multi-homing. When these procedures are used, all PE routers and segmenta is used for an MVPN/EVPN or when BIER/P2MP/MP2MP tunnels are used with EV
tion PN
points MUST support the procedures. It is outside the scope of this docum multihoming. When these procedures are used, all PE routers and segmentat
ent ion
how that is ensured. points <bcp14>MUST</bcp14> support the procedures. How to ensure this beh
</t> avior is outside the scope of this document.
<t>By means outside the scope of this document, each VPN/BD/ES is assigned </t>
<t>Via methods outside the scope of this document, each VPN/BD/ES is ass
igned
a label from the DCB or one of those few context-specific label spaces, a nd every a label from the DCB or one of those few context-specific label spaces, a nd every
PE that is part of the VPN/BD/ES is aware of the assignment. The ES label 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 same label space. If PE and the BD label <bcp14>MUST</bcp14> be assigned from the same label spac
Distinguisher labels are used [RFC7582], they MUST be allocated e. If PE
Distinguisher Labels are used <xref target="RFC7582" format="default"/>,
they <bcp14>MUST</bcp14> be allocated
from the same label space as well. from the same label space as well.
</t> </t>
<t>In case of tunnel segmentation, each PE is also assigned a disjoint <t>In the case of tunnel segmentation, each PE is also assigned a disjoi
label block from one of those few context-specific label spaces and it al nt
locates label block from one of those few context-specific label spaces, and it a
llocates
labels for its segmented PMSI routes from its assigned label block. labels for its segmented PMSI routes from its assigned label block.
</t> </t>
<t>When a PE originates/re-advertises an x-PMSI/IMET route, the route MUST <t>When a PE originates/re-advertises an x-PMSI/IMET route, the route <b
cp14>MUST</bcp14>
carry a DCB-flag if and only if the label in its PTA is assigned carry a DCB-flag if and only if the label in its PTA is assigned
from the DCB. from the DCB.
</t> </t>
<t>If the VPN/BD/ES/PMSI label is assigned from one of those few context-spe <t>If the VPN/BD/ES/PMSI label is assigned from one of those few context
cific label -specific label
spaces, a Context-Specific Label Space ID Extended Community MUST be atta spaces, a Context-Specific Label Space ID EC <bcp14>MUST</bcp14> be attac
ched to the hed to the
route. The ID-Type in the EC is set to 0 and the ID-Value is set to route. The ID-Type in the EC is set to 0, and the ID-Value is set to
a label allocated from the DCB and identifies the context-specific label space. a label allocated from the DCB and identifies the context-specific label space.
When an ingress PE sends traffic, it imposes the DCB label When an ingress PE sends traffic, it imposes the DCB label
that identifies the context-specific label space after it imposes the lab el that identifies the context-specific label space after it imposes the lab el
(that is advertised in the Label field of the PTA in the x-PMSI/IMET rout e) (that is advertised in the Label field of the PTA in the x-PMSI/IMET rout e)
for the VPN/BD and/or the label (that is advertised in the ESI Label EC) for the VPN/BD and/or the label (that is advertised in the ESI Label EC)
for the ESI, and then imposes the encapsulation for the transport tunnel. for the ESI, and then imposes the encapsulation for the transport tunnel.
</t> </t>
<t>When a PE receives an x-PMSI/IMET route with the Context-Specific Label <t>When a PE receives an x-PMSI/IMET route with the Context-Specific Lab
Space ID EC, it MUST place an entry in its default MPLS forwarding table el
Space ID EC, it <bcp14>MUST</bcp14> place an entry in its default MPLS fo
rwarding table
to map the label in the EC to a corresponding context-specific to map the label in the EC to a corresponding context-specific
label table. That table is used for the next label lookup for incoming label table. That table is used for the next label lookup for incoming
data traffic with the label signaled in the EC. data traffic with the label signaled in the EC.
</t> </t>
<t>Then, the receiving PE MUST place an entry for the label in the PTA or <t>Then, the receiving PE <bcp14>MUST</bcp14> place an entry for the lab
ESI Label EC into el that is in the PTA or
ESI Label EC in
either the default MPLS forwarding table (if the route carries the either the default MPLS forwarding table (if the route carries the
DCB-flag) or the context-specific label table (if the Context-Specific La bel Space ID EC DCB-flag) or the context-specific label table (if the Context-Specific La bel Space ID EC
is present) according to the x-PMSI/IMET route. is present) according to the x-PMSI/IMET route.
</t> </t>
<t>An x-PMSI/IMET route MUST NOT both carry the DCB-flag and <t>An x-PMSI/IMET route <bcp14>MUST NOT</bcp14> carry both the
the Context-Specific Label Space ID EC. DCB-flag and the Context-Specific Label Space ID EC. A received route
A received route with both the DCB-flag set and the Context with both the DCB-flag set and the Context-Specific Label Space ID EC at
Label Space ID EC attached MUST be treated as withdrawn. tached
If neither the DCB-flag nor the Context-Specific Label Space ID EC is att <bcp14>MUST</bcp14> be treated as withdrawn. If neither the DCB-flag
ached, nor the Context-Specific Label Space ID EC is attached, the label in
the label in the PTA or ESI Label EC MUST be treated as the upstream-assi the PTA or ESI Label EC <bcp14>MUST</bcp14> be treated as the
gned upstream-assigned label from the label space of the source PE, and
from the label space of the source PE, and procedures in [RFC6514][RFC743 procedures provided in <xref target="RFC6514"/> and <xref target="RFC743
2] 2"/>
MUST be followed. <bcp14>MUST</bcp14> be followed.
</t> </t>
<t>If a PE originates two x-PMSI/IMET routes with the same tunnel, <t>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 it <bcp14>MUST</bcp14> ensure that one of the following scenarios applies, s
o that the PE receiving the routes
can correctly interpret the label that follows the tunnel encapsulation can correctly interpret the label that follows the tunnel encapsulation
of data packets arriving via the tunnel. of data packets arriving via the tunnel:
<list style="symbols"> </t>
<t>They MUST all have the DCB-flag, or, <ul spacing="normal">
</t> <li>They <bcp14>MUST</bcp14> all have the DCB-flag,</li>
<t>They MUST all carry the Context-Specific Label Space ID EC, or, <li>They <bcp14>MUST</bcp14> all carry the Context-Specific Label Spac
</t> e ID EC,</li>
<t>None of them has the DCB-flag, or, <li>None of them have the DCB-flag, or</li>
</t> <li>None of them carry the Context-Specific Label Space ID EC.</li>
<t>None of them carry the Context-Specific Label Space ID EC. </ul>
</t> <t>Otherwise, a receiving PE <bcp14>MUST</bcp14> treat the routes as if
</list> they were withdrawn.
</t> </t>
<t>Otherwise, a receiving PE MUST treat the routes as if they were withdrawn </section>
.
</t>
</section>
</section> </section>
<section title="Security Considerations"> <section numbered="true" toc="default">
<t>This document allows three methods (<xref target="methods"/>) of <name>Security Considerations</name>
label allocation for MVPN [RFC6514] or EVPN [RFC7432] PEs and <t>This document allows three methods (<xref target="methods" format="defa
specifies corresponding signaling and procedures. The first method is ult"/>) of
the equivalent of using common SRGBs [RFC8402] from the regular label allocation for MVPN PEs <xref target="RFC6514"/> or EVPN PEs <xref t
per platform label space. The second one is the equivalent of using arget="RFC7432"/> and
common SRGBs from a third party label space [RFC5331]. The third specifies corresponding signaling and procedures. The first method (Option
method is a variation of the second, in that the third party label <xref target="dcb-assignment" format="counter"/>) is
the equivalent of using common SRGBs <xref target="RFC8402"/> from the reg
ular
per-platform label space. The second method (Option <xref target="context-
space" format="counter"/>) is the equivalent of using
common SRGBs from a third-party label space <xref target="RFC5331" format=
"default"/>. The third
method (Option <xref target="context-block" format="counter"/>) is a varia
tion of the second in that the third-party label
space is divided into disjoint blocks for use by different PEs, space is divided into disjoint blocks for use by different PEs,
who will use labels from their respective block to send traffic. where each PE will use labels from its respective block to send traffic.
In all cases, a receiving PE is able to identify one of a few label In all cases, a receiving PE is able to identify one of the few label
forwarding tables to forward incoming labeled traffic. forwarding tables to forward incoming labeled traffic.
</t> </t>
<t>None of the [RFC6514], [RFC7432], [RFC8402] and [RFC5331] <t><xref target="RFC6514"/>, <xref target="RFC7432"/>, <xref
specifications lists any security concerns related to label allocation target="RFC8402"/>, and <xref target="RFC5331" format="default"/>
methods, and this document does not introduce new security concerns do not list any security concerns related to label allocation
either. methods, and this document does not introduce any new security concerns in
this regard.
</t> </t>
</section> </section>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has made the following assignments: <t>IANA has made the following assignments:
<list style="symbols">
<t>Bit 47 (DCB) from the "Additional PMSI Tunnel Attribute Flags" regist
ry
<figure>
<artwork>
Bit Flag Name Reference
-------- ---------------------- -------------
47 DCB (temporary) This document
</artwork>
</figure>
</t>
<t>Sub-type 0x08 for "Context-Specific Label Space ID Extended Community
" from the "Transitive Opaque Extended Community Sub-Types" registry
<figure>
<artwork>
Sub-Type Value Name Reference
-------------- ---------------------- -------------
0x08 Context-Specific Label Space ID This document
Extended Community
</artwork>
</figure>
</t>
</list>
</t> </t>
<t>IANA is requested to create a "Context-Specific Label Space ID Type" <ul spacing="normal">
registry in the "Border Gateway Protocol (BGP) Extended Communities" <li>
group. The registration procedure is First Come First Served. <t>Bit 47 (DCB) in the "Additional PMSI Tunnel Attribute Flags" regist
ry:</t>
<table align="left" anchor="bit-47-iana-table">
<name></name>
<thead>
<tr>
<th>Bit Flag</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>47</td>
<td>DCB</td>
<td>RFC 9573</td>
</tr>
</tbody>
</table>
</li>
<li>
<t>Sub-type 0x08 for "Context-Specific Label Space ID Extended Communi
ty" in the "Transitive Opaque Extended Community Sub-Types" registry:
</t>
<table align="left" anchor="sub-type-iana-table">
<name></name>
<thead>
<tr>
<th>Sub-Type Value</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0x08</td>
<td>Context-Specific Label Space ID Extended Community</td>
<td>RFC 9573</td>
</tr>
</tbody>
</table>
</li>
</ul>
<t>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
<xref target="RFC8126"/>.
The initial assignment is as follows: The initial assignment is as follows:
<figure>
<artwork>
ID Type Name Reference
------- ---------------------- -------------
0 MPLS Label This document
1-254 unassigned
255 reserved
</artwork>
</figure>
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors thank Stephane Litkowski, Ali Sajassi and Jingrong Xie
for their review of, comments on and suggestions for this document.
</t> </t>
</section>
<section title="Contributors">
<t>The following also contributed to this document.
<figure>
<artwork>
Selvakumar Sivaraj
Juniper Networks
Email: ssivaraj@juniper.net <table align="left" anchor="context-iana-table">
</artwork> <name></name>
</figure> <thead>
</t> <tr>
</section> <th>Type Value</th>
</middle> <th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>MPLS Label</td>
<td>RFC 9573</td>
</tr>
<tr>
<td>1-254</td>
<td>Unassigned</td>
<td></td>
</tr>
<tr>
<td>255</td>
<td>Reserved</td>
<td></td>
</tr>
</tbody>
</table>
</section>
</middle>
<back> <back>
<references title="Normative References">
<?rfc include='reference.RFC.2119.xml'?> <displayreference target="I-D.ietf-bier-evpn" to="BIER-EVPN"/>
<?rfc include='reference.RFC.8174.xml'?>
<?rfc include='reference.RFC.6513.xml'?> <references>
<?rfc include='reference.RFC.6514.xml'?> <name>References</name>
<?rfc include='reference.RFC.7432.xml'?> <references>
<?rfc include='reference.RFC.7524.xml'?> <name>Normative References</name>
<?rfc include='reference.RFC.7582.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.7902.xml'?> 119.xml"/>
<?rfc include='reference.RFC.4360.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</references> 174.xml"/>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.5331.xml'?> 513.xml"/>
<?rfc include='reference.RFC.8279.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.8556.xml'?> 514.xml"/>
<?rfc include='reference.RFC.8402.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.RFC.8660.xml'?> 432.xml"/>
<?rfc include='reference.RFC.4364.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.I-D.ietf-bier-evpn.xml'?> 524.xml"/>
<?rfc include='reference.I-D.ietf-bess-evpn-bum-procedure-updates.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
582.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
902.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
360.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
331.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
279.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
556.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
660.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<!-- draft-ietf-bier-evpn (-14 in EDIT as of May 2024)
(long way to fix Zhaohui Zhang's initial.
Have to keep "Przygienda, A." (as opposed to "Przygienda, T." as used in
published RFCs), because this is a draft) -->
<reference anchor="I-D.ietf-bier-evpn">
<front>
<title>EVPN BUM Using BIER</title>
<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
<organization>Juniper Networks</organization>
</author>
<author fullname="Antoni Przygienda" initials="A." surname="Przygienda">
<organization>Juniper Networks</organization>
</author>
<author fullname="Ali Sajassi" initials="A." surname="Sajassi">
<organization>Cisco Systems</organization>
</author>
<author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
<organization>Nokia</organization>
</author>
<date day="2" month="January" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bier-evpn-14"/>
</reference>
<!-- draft-ietf-bess-evpn-bum-procedure-updates (RFC 9572) -->
<reference anchor="RFC9572" target="https://www.rfc-editor.org/info/rfc9572">
<front>
<title>Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures
</title>
<author initials='Z' surname='Zhang' fullname='Zhaohui Zhang'>
<organization />
</author>
<author initials='W' surname='Lin' fullname='Wen Lin'>
<organization />
</author>
<author initials='J' surname='Rabadan' fullname='Jorge Rabadan'>
<organization />
</author>
<author initials='K' surname='Patel' fullname='Keyur Patel'>
<organization />
</author>
<author initials='A' surname='Sajassi' fullname='Ali Sajassi'>
<organization />
</author>
<date year='2024' month='May'/>
</front>
<seriesInfo name="RFC" value="9572"/>
<seriesInfo name="DOI" value="10.17487/RFC9572"/>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors thank <contact fullname="Stephane Litkowski"/>, <contact fu
llname="Ali Sajassi"/>, and <contact fullname="Jingrong Xie"/>
for their reviews of, comments on, and suggestions for this document.
</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>The following individual also contributed to this document:
</t>
<contact fullname="Selvakumar Sivaraj">
<organization>Juniper Networks</organization>
<address>
<email>ssivaraj@juniper.net</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 93 change blocks. 
557 lines changed or deleted 758 lines changed or added

This html diff was produced by rfcdiff 1.48.