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 " "> | ||||
<!ENTITY zwsp "​"> | ||||
<!ENTITY nbhy "‑"> | ||||
<!ENTITY wj "⁠"> | ||||
]> | ]> | |||
<?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="trust200902" submissionType="IETF" c | |||
<?rfc tocindent="yes"?> | ategory="std" consensus="true" updates="6514, 7432, 7582" obsoletes="" xml:lang= | |||
<?rfc symrefs="yes"?> | "en" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" version="3"> | |||
<?rfc sortrefs="yes"?> | ||||
<?rfc strict="no"?> | <!-- xml2rfc v2v3 conversion 3.18.1 --> | |||
<?rfc rfcedstyle="yes"?> | ||||
<?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 | <title abbrev="MVPN/EVPN Aggregation Labels">MVPN/EVPN Tunnel Aggregation wi | |||
h Common Labels</title> | th Common Labels</title> | |||
<!-- [rfced] Running (abbreviated) title (PDF output): We changed | ||||
"mvpn-evpn-aggregation-label" to "MVPN/EVPN Aggregation Labels" so | ||||
that the title is more descriptive. Please let us know any | ||||
objections. | ||||
Original: | ||||
mvpn-evpn-aggregation-label | ||||
Currently (PDF output): | ||||
MVPN/EVPN Aggregation Labels --> | ||||
<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="April" /> | ||||
<area>rtg</area> | ||||
<workgroup>bess</workgroup> | ||||
<date year="2023"/> | <!-- [rfced] Please insert any keywords (beyond those that appear in the | |||
title) for use on <https://www.rfc-editor.org/search>. --> | ||||
<workgroup>BESS</workgroup> | <!-- [rfced] Datatracker idnits yielded the following warning: | |||
(Using the creation date from RFC6514, updated by this document, for | ||||
RFC5378 checks: 2006-08-01) | ||||
- The document seems to lack a disclaimer for pre-RFC5378 work, but may | ||||
have content which was first submitted before 10 November 2008. If you | ||||
have contacted all the original authors and they are all willing to grant | ||||
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore | ||||
this comment. If not, you may need to add the pre-RFC5378 disclaimer. | ||||
(See the Legal Provisions document at | ||||
https://trustee.ietf.org/license-info for more information.) | ||||
Please review, and advise. --> | ||||
<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"> | ||||
<t>Familiarity with MVPN/EVPN protocols and procedures is assumed. | <!-- [rfced] We restructured Sections 1 and 2 of this document per | |||
Some terminologies are listed below for convenience. | standard practice (e.g., RFCs 9251 and 9252, which are also part of | |||
<list style="symbols"> | Cluster 448 (https://www.rfc-editor.org/cluster_info.php?cid=C448)) | |||
<t>VPN: Virtual Private Network. In this document, it is specifi | and per Section 4.8.1 ("Introduction Section") of RFC 7322 | |||
cally IP VPN <xref target="RFC4364"/>. | ("RFC Style Guide" - https://www.rfc-editor.org/info/rfc7322). | |||
</t> | Please let us know any concerns. | |||
<t>BUM <xref target="RFC7432"/>: Broadcast, Unknown unicast, or Multicast (t | ||||
raffic). | Original: | |||
</t> | 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
<t>BD <xref target="RFC7432"/>: Broadcast Domain. | 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
</t> | 2.1. Problem Description . . . . . . . . . . . . . . . . . . . 5 | |||
<t>EC <xref target="RFC4360"/>: Extended Community. | 2.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . 6 | |||
</t> | 2.2.1. MP2MP Tunnels . . . . . . . . . . . . . . . . . . . . 8 | |||
<t>PMSI <xref target="RFC6513"/>: Provider Multicast Service Interface - | 2.2.2. Segmented Tunnels . . . . . . . . . . . . . . . . . . 8 | |||
a pseudo overlay interface for PEs to send certain overlay/customer multic | 2.2.3. Summary of Label Allocation Methods . . . . . . . . . 10 | |||
ast traffic via underlay/provider | 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
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. | Currently: | |||
</t> | 1. Introduction | |||
<t>Inclusive PMSI: A PMSI that enables traffic to be sent to all PEs of a VP | 1.1. Requirements Language | |||
N/BD. | 1.2. Terminology | |||
The underlay/provider tunnel that instantiates the Inclusive PMSI is referre | 2. Problem Description | |||
d to as an inclusive tunnel. | 3. Proposed Solutions | |||
</t> | 3.1. MP2MP Tunnels | |||
<t>Selective PMSI: A PMSI that enables traffic to be sent to a subset of PEs | 3.2. Segmented Tunnels | |||
of a VPN/BD. | 3.3. Summary of Label Allocation Methods | |||
The underlay/provider tunnel that instantiates the Selective PMSI is referre | 4. Specification | |||
d to as a selective tunnel. | ... --> | |||
</t> | ||||
<t>Aggregate Tunnel: a tunnel that instantiates x-PMSIs of multiple MVPNs or | <section numbered="true" toc="default"> | |||
EVPN BDs. | <name>Introduction</name> | |||
</t> | <t> | |||
<t>IMET <xref target="RFC7432"/>: Inclusive Multicast Ethernet Tag route. An | A Multicast VPN (MVPN) can use Point-to-Multipoint (P2MP) tunnels (set up b | |||
EVPN specific name | y RSVP-TE, Multipoint LDP (mLDP), or PIM) to | |||
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 <S,G> multicast flow. | ||||
</t> | ||||
<t>(C-*,C-G): Customer/overlay <*,G> 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 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. 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. | ||||
<!-- [rfced] Terminology section: | ||||
a) For ease of the reader, we defined "A-D" as "Auto-Discovery" per | ||||
RFC 6514 (but initial-capitalized, per other definitions in this | ||||
document). Please let us know any concerns. | ||||
Original: | ||||
* IMET [RFC7432]: Inclusive Multicast Ethernet Tag route. An EVPN | ||||
specific name for I-PMSI A-D route. | ||||
Currently: | ||||
IMET [RFC7432]: Inclusive Multicast Ethernet Tag. An EVPN- | ||||
specific name for an I-PMSI Auto-Discovery (A-D) route. | ||||
b) We changed "PMXI" to "PMSI", as we could not find "PMXI" elsewhere | ||||
in this document or in any published RFC. Also, we changed | ||||
"an BGP... routes" to "a BGP... route". Please let us know any | ||||
concerns. | ||||
Original: | ||||
* PTA [RFC6514]: PMSI Tunnel Attribute. A BGP attribute that may be | ||||
attached to an BGP-MVPN/EVPN x-PMXI A-D routes. | ||||
Currently: | ||||
PTA [RFC6514]: 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 <S,G> multicast flow. | ||||
</dd> | ||||
<dt>(C-*,C-G):</dt> | ||||
<dd>Customer/overlay <*,G> 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 Virtual Routing and Forward | |||
above. If there are 1,001 PEs, each attached to 1,000 ESes, this can | ing (VRF) / BD label case | |||
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> | ||||
</section> | <!-- [rfced] "Problem Description" section: Please confirm that | |||
<section title="Proposed Solution" anchor="solution"> | "the VRF/BD label case above" should not instead be "the VPN/BD label | |||
<t> | case above". We ask because we see "VPN/BD" used in the first | |||
paragraph of this section and elsewhere in this document, but we do | ||||
not see any other instances of "VRF/BD" in this document. | ||||
Original: | ||||
From the | ||||
receiving 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 tables, one for each source PE, just | ||||
like the VRF/BD label case above. --> | ||||
</t> | ||||
</section> | ||||
<section anchor="solution" numbered="true" toc="default"> | ||||
<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 VRF | |||
interfaces or EVPN Access Circuits) would know by provisioning which | interfaces or EVPN Access 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>For example, all PEs could reserve a DCB [1000, 2000] and they are | <!-- [rfced] "Proposed Solutions" section: Please confirm that | |||
"Access Circuits" and not "Attachment Circuits" is correct here. | ||||
Original: | ||||
A PE that is | ||||
attached (via L3VPN VRF interfaces or EVPN Access Circuits) would | ||||
know by provisioning which label from the DCB corresponds to which of | ||||
its locally attached VPNs, BDs, or ESes. --> | ||||
</t> | ||||
<t>For example, all PEs could reserve a DCB [1000, 2000], and they are | ||||
all provisioned that label 1000 maps to VPN 0, 1001 to VPN 1, and | all provisioned that label 1000 maps to VPN 0, 1001 to VPN 1, and | |||
so forth. Now only 1000 labels instead of 1,000,000 labels | so forth. Now, only 1000 labels instead of 1,000,000 labels | |||
are needed for 1000 VPNs. | are needed for 1000 VPNs. | |||
</t> | ||||
<t>The definition of "domain" is loose - it simply includes | <!-- [rfced] "Proposed Solutions" section: This sentence does not | |||
parse. It appears that some words are missing. Please clarify | ||||
"and they are all provisioned that label". | ||||
Also, should "[1000, 2000]" be "[1000~2000]" per other block ranges | ||||
listed in this document? | ||||
Original: | ||||
For example, all PEs could reserve a DCB [1000, 2000] and they are | ||||
all provisioned that label 1000 maps to VPN 0, 1001 to VPN 1, and so | ||||
forth. | ||||
Possibly: | ||||
For example, all PEs could reserve a DCB [1000~2000], and they | ||||
could all be provisioned such that label 1000 maps to VPN 0, 1001 to | ||||
VPN 1, and so forth. --> | ||||
</t> | ||||
<t>The definition of "domain" is loose -- 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. In this document, it only needs | |||
to include all PEs of an MVPN/EVPN network<!--, or in case of tunnel | to include all PEs of an MVPN/EVPN. | |||
segmentation <xref target="RFC6514"/> it may only need to include all PEs | ||||
and border nodes of a segmentation region (see more details in <xref target | <!-- [rfced] "Proposed Solutions" section: Is "domain" always | |||
="seg"/>)-->. | loosely defined, or does this statement only apply to this document? | |||
</t> | ||||
<t> | Original: | |||
The definition of "domain" is loose - it simply includes all the | ||||
routers that share the same DCB. In this document, it only needs to | ||||
include all PEs of an MVPN/EVPN network. | ||||
Possibly: | ||||
In this document, "domain" is defined loosely; it simply includes | ||||
all the routers that share the same DCB, and it only needs to | ||||
include all PEs of an MVPN/EVPN. --> | ||||
</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> | ||||
<!-- [rfced] "Proposed Solutions" section: Please confirm that | ||||
"P routers" and not "PE routers" is intended here. (We also ask | ||||
because we do not see "P router" or "P routers" used anywhere else | ||||
in Cluster 448 (https://www.rfc-editor.org/cluster_info.php?cid=C448). | ||||
Original: | ||||
Therefore, it is | ||||
better to not include internal P routers in the "domain". --> | ||||
</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 | separate context-specific label spaces 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> | <!-- [rfced] "Proposed Solution" section: Does "independent of each | |||
The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes that | PE" refer to allocation, as used elsewhere in this document (in which | |||
case it should be "independently of each PE"), or does it refer to | ||||
label spaces that are independent of each PE (in which case this text | ||||
should be rephrased)? Please clarify. | ||||
Original: | ||||
In this | ||||
case, it may be necessary to allocate those labels from one or a few | ||||
separate context-specific label spaces independent of each PE. --> | ||||
</t> | ||||
<t> | ||||
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> | ||||
<section title="MP2MP Tunnels"> | <!-- [rfced] "Proposed Solutions" section: As it appears that "them" | |||
<t>MP2MP tunnels present the same problem (<xref target="problem"/>) | in this sentence refers to "a label", we changed "them" to "the | |||
that can be solved the same way (<xref target="solution"/>), with | label". We also changed "from a context-specific label spaces" to | |||
"from a context-specific label space". If these updates are | ||||
incorrect, please provide text that clarifies the singular versus the | ||||
plural. | ||||
Original: | ||||
Allocating a label from the DCB or from a context-specific | ||||
label spaces and communicating them to all PEs is not different from | ||||
allocating VNIs, and is feasible especially with controllers. | ||||
Currently: | ||||
Allocating a label from the DCB or from a context-specific | ||||
label space and communicating the label to all PEs is not different | ||||
from allocating VNIs and is especially feasible with controllers. --> | ||||
</t> | ||||
<section numbered="true" toc="default"> | ||||
<name>MP2MP Tunnels</name> | ||||
<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> | <!-- [rfced] "MP2MP Tunnels" section: We found this sentence | |||
Per RFC 7582 ("MVPN: Using Bidirectional P-tunnels"), when MP2MP | confusing, because the "Problem Description" section appears to | |||
tunnels are used for MVPN, the root of the MP2MP tunnel may | discuss more than one problem ("This is an evident scaling problem", | |||
need to allocate and advertise "PE Distinguisher Labels" (section 4 | "this problem has not surfaced", "A similar problem also exists"). | |||
of <xref target="RFC6513"/>. These labels are assigned | Which problem is referred to here? Please provide clarifying text. | |||
Original: | ||||
MP2MP tunnels present the same problem (Section 2.1) that can be | ||||
solved the same way (Section 2.2), with the following additional | ||||
requirement. --> | ||||
</t> | ||||
<t> | ||||
Per <xref target="RFC7582"/> ("Multicast Virtual Private Network (MVPN): Usi | ||||
ng Bidirectional P-Tunnels"), when MP2MP | ||||
tunnels are used for an MVPN, the root of the MP2MP tunnel may | ||||
need to allocate and advertise "PE Distinguisher Labels" (<xref target="RFC6 | ||||
513" sectionFormat="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> | <!-- [rfced] "MP2MP Tunnels" section: Section 3.2.2.1 of RFC 7582 | |||
It is REQUIRED by this document that the PE Distinguisher | appears to use a "MUST" when discussing this topic, as opposed to the | |||
labels allocated by a particular node come from the same label space | "may" as used in this sentence. Will this distinction be clear to | |||
readers? | ||||
Original: | ||||
Per RFC 7582 ("MVPN: Using Bidirectional P-tunnels"), when MP2MP | ||||
tunnels are used for MVPN, the root of the MP2MP tunnel may need to | ||||
allocate and advertise "PE Distinguisher Labels" (section 4 of | ||||
[RFC6513]. --> | ||||
</t> | ||||
<t> | ||||
It is <bcp14>REQUIRED</bcp14> by this document that the PE Distinguisher | ||||
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 | |||
disjoint label blocks in those few context-specific label spaces, and eac | disjoint label blocks in those few context-specific label spaces, and eac | |||
h will | h PE will | |||
independently allocate labels for segmented S-PMSI from its | independently allocate labels for a segmented S-PMSI from its | |||
assigned label block that is different from any other PE's. For example, | assigned label block that is different from any other PE's. 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>Allocating from disjoint label blocks can be used for VPN/BD/ES labels | <!-- [rfced] "Selective Tunnels" section: We could not parse this | |||
sentence. To what do "that" and "PE's" refer - a block, a label, or | ||||
something else? | ||||
Original: | ||||
To address | ||||
this problem, all PEs can be assigned disjoint label blocks in those | ||||
few context-specific label spaces, and each will independently | ||||
allocate labels for segmented S-PMSI from its assigned label block | ||||
that is different from any other PE's. | ||||
Possibly: | ||||
To address | ||||
this problem, all PEs can be assigned their own disjoint label | ||||
blocks in those few context-specific label spaces; each PE will | ||||
independently allocate labels for a segmented S-PMSI from its own | ||||
assigned label block. --> | ||||
</t> | ||||
<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>Specification</name> | |||
<t> | ||||
</t> | <!-- [rfced] "Specification" section: The meaning and purpose of | |||
<section title="Context-Specific Label Space ID Extended Community"> | this section title are unclear. Would "Specifications" be clearer, | |||
<t>Context-Specific Label Space ID Extended Community (EC) is a new Transiti | or perhaps something more descriptive (e.g., "New Extended Community | |||
ve Opaque EC with the following structure: | and Related Procedures", assuming that this title would be accurate)? | |||
<figure> | ||||
<artwork align="center"><![CDATA[ | Original: | |||
0 1 2 3 | 3. Specification --> | |||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <section numbered="true" toc="default"> | |||
| 0x03 or 0x43 | 8 | ID-Type | | <name>Context-Specific Label Space ID Extended Community</name> | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <t>The Context-Specific Label Space ID Extended Community (EC) is a new | |||
| ID-Value | | Transitive Opaque EC with the following structure: | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | </t> | |||
]]></artwork> | <artwork align="center" name="" type="" alt=""><![CDATA[ | |||
</figure> | 0 1 2 3 | |||
<list style="symbols"> | 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 | |||
<t>ID-Type: A 2-octet field that specifies the type of Label Space ID. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
In this document, the ID-Type is 0, indicating that the ID-Value | | 0x03 or 0x43 | 8 | ID-Type | | |||
field is a label. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
</t> | | ID-Value | | |||
<t>ID-Value: A 4-octet field that specifies the value of Label Space ID. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
]]></artwork> | ||||
<dl spacing="normal"> | ||||
<dt>ID-Type:</dt> | ||||
<dd>A 2-octet field that specifies the type of Label Space | ||||
ID. In this document, the ID-Type is 0, indicating that the | ||||
ID-Value field is a label.</dd> | ||||
<dt>ID-Value:</dt> | ||||
<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 | |||
is set to the label value. | is set to the label value.</dd> | |||
</t> | ||||
</list> | <!-- [rfced] "Context-Specific Label Space ID Extended Community" | |||
</t> | section: Please clarify the meaning of "most significant 20-bit". | |||
<t>This document introduces a DCB flag (Bit 47 as assigned by IANA) in the | Does it mean "most significant 20 bits", "most significant 20-bit | |||
"Additional PMSI Tunnel Attribute Flags" BGP Extended Community [RFC7902] | portion", or something else? Is this related to Erratum ID 5554 | |||
. | for RFC 7432 (https://www.rfc-editor.org/errata/eid5554)? | |||
</t> | ||||
<t>In the remainder of the document, when we say a BGP-MVPN/EVPN A-D route | Original: | |||
"carries DCB-flag" or "has DCB-flag attached" we mean the following: | * ID-Value: A 4-octet field that specifies the value of Label Space | |||
<list style="symbols"> | ID. When it is a label (with ID-Type 0), the most significant | |||
<t>The route carries a PMSI Tunnel Attribute (PTA) and its Flags field has | 20-bit is set to the label value. --> | |||
the Extension bit set, AND, | ||||
</t> | </dl> | |||
<t>The route carries an "Additional PMSI Tunnel Attribute Flags" EC | <t>This document introduces a DCB-flag (Bit 47 as assigned by IANA) in t | |||
and its DCB flag is set | he | |||
</t> | "Additional PMSI Tunnel Attribute Flags" BGP Extended Community <xref tar | |||
</list> | get="RFC7902" format="default"/>. | |||
</t> | </t> | |||
</section> | <t>In the remainder of this document, when we say that a BGP-MVPN/EVPN A | |||
<section title="Procedures"> | -D route | |||
<t>The protocol and procedures specified in this section MAY be used | "carries the DCB-flag" or "has a DCB-flag attached", we mean the followin | |||
when BIER, or P2MP/MP2MP tunnel aggregation | g: | |||
is used for MVPN/EVPN, or BIER/P2MP/MP2MP tunnels are used with EVPN | ||||
multi-homing. When these procedures are used, all PE routers and segmenta | <!-- [rfced] "Context-Specific Label Space ID Extended Community" | |||
tion | section: We see one instance each of "carry a DCB-flag" and "carries | |||
points MUST support the procedures. It is outside the scope of this docum | the DCB-flag" in the "Procedures" section. However, we do not see | |||
ent | any instances of "has DCB-flag attached" or "DCB-flag attached" | |||
how that is ensured. | elsewhere in this document. To avoid confusion, we suggest either | |||
</t> | removing the quotes in this sentence or rephrasing the text. | |||
<t>By means outside the scope of this document, each VPN/BD/ES is assigned | ||||
Original: | ||||
In the remainder of the document, when we say a BGP-MVPN/EVPN A-D | ||||
route "carries DCB-flag" or "has DCB-flag attached" we mean the | ||||
following: | ||||
Possibly: | ||||
In the remainder of this document, when we say that a BGP-MVPN/EVPN | ||||
A-D route carries a DCB-flag or has a DCB-flag attached to it, we | ||||
mean the following: --> | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li>The route carries a PTA and its Flags field has | ||||
the Extension bit set, AND</li> | ||||
<li>The route carries an "Additional PMSI Tunnel Attribute Flags" EC | ||||
and its DCB-flag is set.</li> | ||||
</ul> | ||||
</section> | ||||
<section numbered="true" toc="default"> | ||||
<name>Procedures</name> | ||||
<t>The protocol and procedures specified in this section <bcp14>MAY</bcp | ||||
14> be used | ||||
when BIER or P2MP/MP2MP tunnel aggregation | ||||
is used for an MVPN/EVPN or when BIER/P2MP/MP2MP tunnels are used with EV | ||||
PN | ||||
multihoming. When these procedures are used, all PE routers and segmentat | ||||
ion | ||||
points <bcp14>MUST</bcp14> support the procedures. How to ensure this beh | ||||
avior is outside the scope of this document. | ||||
<!-- [rfced] "Procedures" section: This sentence did not parse. We | ||||
updated it as noted below. If this is incorrect, please provide | ||||
clarifying text. | ||||
Original: | ||||
The protocol and procedures specified in this section MAY be used | ||||
when BIER, or P2MP/MP2MP tunnel aggregation is used for MVPN/EVPN, or | ||||
BIER/P2MP/MP2MP tunnels are used with EVPN multi-homing. | ||||
Suggested: | ||||
The protocol and procedures specified in this section MAY be used | ||||
when BIER or P2MP/MP2MP tunnel aggregation is used for an MVPN/EVPN | ||||
or when BIER/P2MP/MP2MP tunnels are used with EVPN multihoming. --> | ||||
</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>If a PE originates two x-PMSI/IMET routes with the same tunnel, | <!-- [rfced] "Procedures" section: As it appears that "both" refers | |||
it MUST ensure one of the following so that the PE receiving the routes | to the DCB-flag and the Context-Specific Label Space ID EC and not | |||
to the x-PMSI/IMET route, we changed "both carry" to "carry both". | ||||
If this is incorrect, please provide clarifying text. | ||||
Original: | ||||
An x-PMSI/IMET route MUST NOT both carry the DCB-flag and the | ||||
Context-Specific Label Space ID EC. | ||||
Currently: | ||||
An x-PMSI/IMET route MUST NOT carry both the DCB-flag and the | ||||
Context-Specific Label Space ID EC. --> | ||||
</t> | ||||
<t>If a PE originates two x-PMSI/IMET routes with the same tunnel, | ||||
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 a few label | |||
forwarding tables to forward incoming labeled traffic. | forwarding tables to forward incoming labeled traffic. | |||
<!-- [rfced] Security Considerations: Should "one of a few" be | ||||
"one or a few" or "one or several" here, or does the text mean | ||||
"one out of several possible tables"? | ||||
Original: | ||||
In all | ||||
cases, a receiving PE is able to identify one of a few label | ||||
forwarding tables to forward incoming labeled traffic. | ||||
Possibly: | ||||
In all | ||||
cases, a receiving PE is able to identify one or several label | ||||
forwarding tables for forwarding 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> | <!-- [rfced] Section 5: We cited RFC 8126 here, per standard | |||
ID Type Name Reference | practice (e.g., RFCs 9251 and 9252), and we added a listing for | |||
------- ---------------------- ------------- | RFC 8126 in the Informative References section. Please let us | |||
0 MPLS Label This document | know any concerns. | |||
1-254 unassigned | ||||
255 reserved | Original: | |||
</artwork> | The registration procedure is First Come First Served. | |||
</figure> | ||||
Currently: | ||||
The registration procedure is First Come First Served | ||||
[RFC8126]. | ||||
... | ||||
[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>. --> | ||||
</t> | </t> | |||
<table align="left" anchor="context-iana-table"> | ||||
<name></name> | ||||
<thead> | ||||
<tr> | ||||
<th>Type Value</th> | ||||
<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> | </section> | |||
<section anchor="Acknowledgements" title="Acknowledgements"> | </middle> | |||
<t>The authors thank Stephane Litkowski, Ali Sajassi and Jingrong Xie | <back> | |||
for their review of, comments on and suggestions for this document. | ||||
<displayreference target="I-D.ietf-bier-evpn" to="BIER-EVPN"/> | ||||
<references> | ||||
<name>References</name> | ||||
<references> | ||||
<name>Normative References</name> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 | ||||
119.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
174.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 | ||||
513.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 | ||||
514.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
432.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
524.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 Feb 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) --> | ||||
<!-- Lynne: If authors of 9572 approve the FYI-AQed change from "Updates on" to | ||||
"Updates to", update this listing to match --> | ||||
<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='April'/> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9572"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9572"/> | ||||
</reference> | ||||
</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> | </t> | |||
</section> | </section> | |||
<section title="Contributors"> | <section numbered="false" toc="default"> | |||
<t>The following also contributed to this document. | <name>Contributors</name> | |||
<figure> | <t>The following individual also contributed to this document: | |||
<artwork> | </t> | |||
Selvakumar Sivaraj | ||||
Juniper Networks | ||||
Email: ssivaraj@juniper.net | <contact fullname="Selvakumar Sivaraj"> | |||
</artwork> | <organization>Juniper Networks</organization> | |||
</figure> | <address> | |||
</t> | <email>ssivaraj@juniper.net</email> | |||
</address> | ||||
</contact> | ||||
</section> | </section> | |||
</middle> | </back> | |||
<back> | <!-- [rfced] Please review the "Inclusive Language" portion of the | |||
<references title="Normative References"> | online Style Guide at | |||
<?rfc include='reference.RFC.2119.xml'?> | <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, | |||
<?rfc include='reference.RFC.8174.xml'?> | and let us know if any changes are needed. | |||
<?rfc include='reference.RFC.6513.xml'?> | ||||
<?rfc include='reference.RFC.6514.xml'?> | Note that our script did not flag any words in particular, but this | |||
<?rfc include='reference.RFC.7432.xml'?> | should still be reviewed as a best practice. --> | |||
<?rfc include='reference.RFC.7524.xml'?> | ||||
<?rfc include='reference.RFC.7582.xml'?> | <!-- [rfced] Please let us know if any changes are needed for the | |||
<?rfc include='reference.RFC.7902.xml'?> | following: | |||
<?rfc include='reference.RFC.4360.xml'?> | ||||
</references> | a) The following terms/values were used inconsistently in this | |||
<references title="Informative References"> | document. We chose to use the latter forms. Please let us know any | |||
<?rfc include='reference.RFC.5331.xml'?> | objections. | |||
<?rfc include='reference.RFC.8279.xml'?> | ||||
<?rfc include='reference.RFC.8556.xml'?> | 1,000 / 1000 | |||
<?rfc include='reference.RFC.8402.xml'?> | ||||
<?rfc include='reference.RFC.8660.xml'?> | 1,001 / 1001 | |||
<?rfc include='reference.RFC.4364.xml'?> | ||||
<?rfc include='reference.I-D.ietf-bier-evpn.xml'?> | context label spaces (1 instance) / context-specific label spaces | |||
<?rfc include='reference.I-D.ietf-bess-evpn-bum-procedure-updates.xml'?> | ||||
</references> | Context Label Space ID EC (1 instance) / | |||
Context-Specific Label Space ID EC | ||||
DCB flag (2 instances) / DCB-flag (9 instances)* | ||||
* Please note that although we updated this document so that usage | ||||
of this particular term is consistent, Cluster 448 | ||||
(https://www.rfc-editor.org/cluster_info.php?cid=C448) otherwise | ||||
does not use any hyphenated flag names. Please let us know if | ||||
you prefer that this document use "DCB flag" instead. | ||||
Ingress Replication / ingress replication (per RFCs 9251 and 9252) | ||||
PE Distinguisher labels / PE Distinguisher Labels (per RFCs 7582 | ||||
and 6513) | ||||
per-PE/Region / per-PE/region | ||||
(along the lines of "AS/region" as used in this document and | ||||
companion document draft-ietf-bess-evpn-bum-procedure-updates) | ||||
b) The following terms appear to be used inconsistently in this | ||||
document. Please let us know which form is preferred. | ||||
Customer / customer (e.g., "overlay/customer", | ||||
"All Customer/overlay") | ||||
(We suggest "customer" per the rest of Cluster 448.) --> | ||||
</back> | ||||
</rfc> | </rfc> | |||
End of changes. 99 change blocks. | ||||
548 lines changed or deleted | 1123 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |