<?xmlversion="1.1" encoding="US-ASCII"?>version="1.0" encoding="utf-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc strict="no"?> <?rfc rfcedstyle="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bess-mvpn-evpn-aggregation-label-14" number="9573" ipr="trust200902" submissionType="IETF" category="std"updates="7432, 6514,consensus="true" updates="6514, 7432, 7582"docName="draft-ietf-bess-mvpn-evpn-aggregation-label-14" ipr="trust200902">obsoletes="" xml:lang="en" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.18.1 --> <front> <titleabbrev="mvpn-evpn-aggregation-label">MVPN/EVPNabbrev="MVPN/EVPN Aggregation Labels">MVPN/EVPN Tunnel Aggregation with 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"> <organization>Juniper Networks</organization> <address> <email>zzhang@juniper.net</email> </address> </author> <author fullname="Eric Rosen" initials="E." surname="Rosen"> <organization>Individual</organization> <address> <email>erosen52@gmail.com</email> </address> </author> <author fullname="Wen Lin" initials="W." surname="Lin"> <organization>Juniper Networks</organization> <address> <email>wlin@juniper.net</email> </address> </author> <author fullname="Zhenbin Li" initials="Z." surname="Li"> <organization>Huawei Technologies</organization> <address> <email>lizhenbin@huawei.com</email> </address> </author> <author fullname="IJsbrand Wijnands"initials="I."initials="IJ." surname="Wijnands"> <organization>Individual</organization> <address> <email>ice@braindump.be</email> </address> </author> <dateyear="2023"/> <workgroup>BESS</workgroup>year="2024" month="April" /> <area>rtg</area> <workgroup>bess</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. --> <!-- [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> <t> TheMVPNMulticast VPN (MVPN) specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs(abbreviated(referred to asVPNs).VPNs in this document). The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP 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 mapped to its VPN or BD (in some cases, a distinct upstream-assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, 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) thanas, or larger than, the product 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 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. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514,74327432, and 7582 by specifying the necessary procedures. </t> </abstract><note title="Requirements Language"> <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",</front> <middle> <!-- [rfced] We restructured Sections 1 and"OPTIONAL" in2 of this documentare 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> <middle> <section title="Terminology"> <t>Familiarity with MVPN/EVPN protocolsper standard practice (e.g., RFCs 9251 andprocedures is assumed. Some terminologies9252, which arelisted below for convenience. <list style="symbols"> <t>VPN: Virtual Private Network. In this document, it is specifically IP VPN <xref target="RFC4364"/>. </t> <t>BUM <xref target="RFC7432"/>: Broadcast, Unknown unicast, or Multicast (traffic). </t> <t>BD <xref target="RFC7432"/>: Broadcast Domain. </t> <t>EC <xref target="RFC4360"/>: Extended Community. </t> <t>PMSI <xref target="RFC6513"/>: Provider Multicast Service Interface - a pseudo overlay interface for PEs to send certain overlay/customer multicast traffic via underlay/provider tunnels. It includes <br/>I/S-PMSI (often referred to as x-PMSI) for Inclusive/Selective PMSI. A PMSI is instantiated by the underlay/provider tunnel. </t> <t>Inclusive PMSI: A PMSI that enables traffic to be sent to all PEs of a VPN/BD. The underlay/provider tunnel that instantiates the Inclusive PMSI is referred to as an inclusive tunnel. </t> <t>Selective PMSI: A PMSI that enables traffic to be sent to a subset of PEs of a VPN/BD. The underlay/provider tunnel that instantiates the Selective PMSI is referred to as a selective tunnel. </t> <t>Aggregate Tunnel: a tunnel that instantiates x-PMSIs of multiple MVPNs or EVPN BDs. </t> <t>IMET <xref target="RFC7432"/>: Inclusive Multicast Ethernet Tag route. An EVPN specific name for I-PMSI A-D route. </t> <t>PTA <xref target="RFC6514"/>: PMSI Tunnel Attribute. A BGP attribute that may be attached to an BGP-MVPN/EVPN x-PMXI A-D routes. </t> <t>RBR: Regional Border Routers. Border routers between segmentation regions that participate in segmentation procedures. </t> <t>(C-S,C-G): A Customer/overlay <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 Segment </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 propertyalso part ofa nodeCluster 448 (https://www.rfc-editor.org/cluster_info.php?cid=C448)) andidentifies the setper Section 4.8.1 ("Introduction Section") oflocal labels reserved for global segments. </t> <t>DCB: Domain-wide Common Block, a common blockRFC 7322 ("RFC Style Guide" - https://www.rfc-editor.org/info/rfc7322). Please let us know any concerns. Original: 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Problem Description . . . . . . . . . . . . . . . . . . . 5 2.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . 6 2.2.1. MP2MP Tunnels . . . . . . . . . . . . . . . . . . . . 8 2.2.2. Segmented Tunnels . . . . . . . . . . . . . . . . . . 8 2.2.3. Summary oflabels reserved on all nodes in a domain. </t> <t>Context-specificLabelSpace [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 spaces is to be used to look up the label, hence those label spaces are referred to as context-specific label spaces. </t> <t>Upstream-assigned [RFC5331]: When the label at the topAllocation Methods . . . . . . . . . 10 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 11 ... Currently: 1. Introduction 1.1. Requirements Language 1.2. Terminology 2. Problem Description 3. Proposed Solutions 3.1. MP2MP Tunnels 3.2. Segmented Tunnels 3.3. Summary ofthe 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. </t> </list> </t> </section>Label Allocation Methods 4. Specification ... --> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>MVPNA Multicast VPN (MVPN) can useP2MPPoint-to-Multipoint (P2MP) tunnels (set up by RSVP-TE,mLDP,Multipoint LDP (mLDP), or PIM) to transport customer multicast traffic across a service provider's backbone network. Often, a given P2MP tunnel carries the traffic of only a single VPN.ThereHowever, there arehoweverprocedures defined that allow a single P2MP tunnel to carry traffic of multiple VPNs. In this case, the P2MP tunnel is called an "aggregate tunnel". ThePEProvider Edge (PE) router that is the ingress node of an aggregate P2MP tunnel allocates an "upstream-assigned MPLS label"[RFC5331]<xref target="RFC5331" format="default"/> for each VPN, and each packet sent on the P2MP tunnel carries the upstream-assigned MPLS label that the ingress PE has bound to the packet's VPN. </t> <t> Similarly, an EVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) to transportBUM traffic (Broadcast traffic, Unicast traffic with anBroadcast, Unknownaddress,Unicast, or Multicasttraffic),(BUM) traffic across the provider network.OftenOften, a P2MP tunnel carries the traffic of only a singleBD.Broadcast Domain (BD). However, there are procedures defined that allow a single P2MP tunnel to be an"aggregate tunnel"aggregate tunnel that carries traffic of multiple BDs. The procedures are analogous to the MVPN procedures -- the PE router that is the ingress node of an aggregate P2MP tunnel allocates an upstream-assigned MPLS label for each BD, and each packet sent on the P2MP tunnel carries the upstream-assigned MPLS label that the ingress PE has bound to the packet's BD. </t> <t> An MVPNandor EVPN can also useBIER [RFC8279]Bit Index Explicit Replication (BIER) <xref target="RFC8279" format="default"/> to transmit VPN multicast traffic <xref target="RFC8556" format="default"/> or EVPN BUM traffic[RFC8556]<xreftarget="I-D.ietf-bier-evpn"/>.target="I-D.ietf-bier-evpn" format="default"/>. Although BIER does not explicitly set up P2MP tunnels, from the perspective of an MVPN/EVPN, the use of BIER transport is very similar to the use of aggregate P2MP tunnels. When BIER is used, the PE transmitting a packet (the"BFIR" [RFC8279])"Bit-Forwarding Ingress Router" (BFIR) <xref target="RFC8279" format="default"/>) must allocate an upstream-assigned MPLS label for each VPN or BD, and the packets transmitted using BIER transport always carry the label that identifies their VPN or BD. (See[RFC8556]<xref target="RFC8556" format="default"/> and <xreftarget="I-D.ietf-bier-evpn"/>target="I-D.ietf-bier-evpn" format="default"/> forthedetails.) In the remainder of this document, we will use the term "aggregate tunnels" to include both P2MP tunnels and BIER transport. </t> <t> When an egress PE receives a packet from an aggregate tunnel, it must look at the upstream-assigned label carried by thepacket,packet and must interpret that label in the context of the ingress PE. Essentially, for each ingress PE, the egress PE has a context-specific label space[RFC5331]<xref target="RFC5331" format="default"/> that matches the default label space from which the ingress PE assigns the upstream-assigned labels. When an egress PE looks up the upstream-assigned label carried by a given packet, it looks it up in the context-specific label space for the ingress PE of the packet. How an egress PE identifies the ingress PE of a given packet depends on the tunnel type. </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> <sectiontitle="Problem Description" anchor="problem">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 refers to an IP VPN <xref target="RFC4364" format="default"/>. </dd> <dt>BUM <xref target="RFC7432" format="default"/>:</dt><dd>Broadcast, Unknown Unicast, or Multicast (traffic).</dd> <dt>BD <xref target="RFC7432" format="default"/>:</dt><dd>Broadcast Domain.</dd> <dt>EC <xref target="RFC4360" format="default"/>:</dt><dd>Extended Community. </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="default"/>:</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 number of labels. Suppose that an MVPN or EVPN deployment has 1001 PEs, each hosting 1000VPN/BDs.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 PEs. Since each ingress PE allocates labels from its own label space and does not coordinate label assignments with others, each egress PE must be prepared to interpret 1,000,000 upstream-assigned labels (across 1000 context-specific label spaces--- one for each ingress PE). This is an evident scaling problem. </t> <t> So far, few if any MVPN/EVPN deployments use aggregate tunnels, so this problem has not surfaced. However, the use of aggregate tunnels is likely to increase due to the following two factors:<list style="symbols"> <t> In</t> <ul spacing="normal"> <li>In an EVPN, a single customer ("tenant") may have a large number of BDs, and the use of aggregate RSVP-TE or mLDP P2MP tunnels may become important, since each tunnel creates state at the intermediatenodes. </t> <t> Thenodes.</li> <li>The use of BIER as the transport for an MVPN/EVPN is becoming more and more attractive andfeasible. </t> </list> </t> <!--t>Note there are pros and cons with traditional P2MP tunnel aggregation (vs. BIER), which are 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-->feasible.</li> </ul> <t>A similar problem also exists with EVPN ESI labels used formulti-homing.multihoming. A PE attached to amulti-homed Ethernet Segment (ES)multihomed ES advertises an ESI label in its Ethernet A-D perEthernet Segment Route.ES route. The PE imposes the label 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 the ESI label that the packet originated on the sourceES,ES and thus will not transmit the packet on its localattachment circuitAttachment Circuit to that ES. From the receiving PE's point of view, the ESI label is(upstream-)assigned(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 theVRF/BDVirtual Routing and Forwarding (VRF) / BD label case above. If there are1,0011001 PEs, each attached to1,000 ESes,1000 ESs, this can require each PE to understand 1,000,000 ESI labels. Notice that the issue exists even when no P2MP tunnel aggregation(i.e.(i.e., one tunnel used for multiple BDs) is used. <!-- [rfced] "Problem Description" section: Please confirm that "the VRF/BD label case above" should not instead be "the VPN/BD label 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> <sectiontitle="Proposed Solution" anchor="solution">anchor="solution" numbered="true" toc="default"> <name>Proposed Solutions</name> <t> The number of labels could be greatly reduced if a central entity in the provider network assigned a label to each VPN, BD, orES,ES and if all PEs used that same label to represent a givenVPN ,VPN, BD, or ES.ThenThen, the number of labels needed would just be the sum of the number of VPNs,BD,BDs, and/orESes.ESs. </t> <t> One method of achieving this is to reserve a portion of the default label space for assignment by a central entity. We refer to this reserved portion as the"Domain-wide Common Block" (DCB)DCB of labels. This is analogous to the concept of using identical"Segment Routing Global Block" (SRGB)SRGBs on allnodes that isnodes, as described in[RFC8402].<xref target="RFC8402"/>. 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 ESs. <!-- [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]2000], and they are all provisioned that label 1000 maps to VPN 0, 1001 to VPN 1, and so forth.NowNow, only 1000 labels instead of 1,000,000 labels are needed for 1000 VPNs. <!-- [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 to include all PEs of anMVPN/EVPN network<!--,MVPN/EVPN. <!-- [rfced] "Proposed Solutions" section: Is "domain" always loosely defined, orin casedoes this statement only apply to this document? Original: The definition oftunnel segmentation <xref target="RFC6514"/>"domain" is loose - it simply includes all the routers that share the same DCB. In this document, itmayonlyneedneeds 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, andborder nodesit only needs to include all PEs ofa segmentation region (see more details in <xref target="seg"/>)-->.an MVPN/EVPN. --> </t> <t> The "domain" could also include all routers in the provider network, making it not much different from a common SRGB across all the routers. However, that is notnecessarynecessary, as the labels used by PEs for the purposes defined in this document will only rise to the top of the label stack when traffic arrives at the PEs. Therefore, it is better to not include internal P routers in the "domain". Thatwayway, they do not have to set aside the same DCB used for the purposes defined in this document. <!-- [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 large enough to contain labels for all theVPNs/BDs/ESes.VPNs/BDs/ESs. In this case, it may be necessary to allocate those labels from one or a few separate context-specific label spaces independent of eachPE<!--'s default label space (that the DCB belongs to)-->.PE. For example, if it is too difficult to have a DCB of 10,000 labels across all PEs for all theVPNs/BDs/ESesVPNs/BDs/ESs that need to be supported, a separate context-specific label space can be dedicated to those 10,000 labels. Each separate context-specific label space is 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 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 labels (for the VPN/BD/ES) first, then imposes the label-space-identifying DCB label. From the label-space-identifying DCBlabellabel, an egress PE can determine the label space where the inner VPN/BD/ES label is looked up. <!-- [rfced] "Proposed Solution" section: Does "independent of each 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[RFC6514]<xref target="RFC6514"/> and[RFC7432]<xref target="RFC7432"/> assumes that certain MPLS labels are allocated from a context-specific label space for a particular ingress PE. In this document, we augment the signaling 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 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 not for an ingress PE. </t> <t>Noticethat,that the VPN/BD/ES-identifying labels from the DCB or from those few context-specific label spaces are very similar to Virtual eXtensible Local Area Network (VXLAN) Network Identifiers (VNIs) in VXLANs. 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. <!-- [rfced] "Proposed Solutions" section: As it appears that "them" inVXLAN.this sentence refers to "a label", we changed "them" to "the 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> <sectiontitle="MP2MP Tunnels"> <t>MP2MPnumbered="true" toc="default"> <name>MP2MP Tunnels</name> <t>Multipoint-to-Multipoint (MP2MP) tunnels present the same problem (<xreftarget="problem"/>)target="problem" format="default"/>) that can be solved the same way (<xreftarget="solution"/>),target="solution" format="default"/>), with the following additional requirement. <!-- [rfced] "MP2MP Tunnels" section: We found this sentence confusing, because the "Problem Description" section appears to discuss more than one problem ("This is an evident scaling problem", "this problem has not surfaced", "A similar problem also exists"). 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> PerRFC 7582 ("MVPN:<xref target="RFC7582"/> ("Multicast Virtual Private Network (MVPN): Using BidirectionalP-tunnels"),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"(section 4 of <xref target="RFC6513"/>.(<xref target="RFC6513" sectionFormat="of" section="4"/>). These labels are assigned from the label space used by the root node for its upstream-assigned labels. <!-- [rfced] "MP2MP Tunnels" section: Section 3.2.2.1 of RFC 7582 appears to use a "MUST" when discussing this topic, as opposed to the "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 isREQUIRED<bcp14>REQUIRED</bcp14> by this document that the PE DistinguisherlabelsLabels allocated by a particular node come from the same label space that the node uses to allocate its VPN-identifying labels. </t> </section> <sectiontitle="Segmented Tunnels" anchor="seg">anchor="seg" numbered="true" toc="default"> <name>Segmented Tunnels</name> <t>There are some additional issues to be considered when an MVPN or EVPN is using "tunnel segmentation" (see[RFC6514], [RFC7524], and<xreftarget="I-D.ietf-bess-evpn-bum-procedure-updates"/>target="RFC6514"/>, <xref target="RFC7524"/>, and Sections5<xref target="RFC9572" sectionFormat="bare" section="5"/> and6).<xref target="RFC9572" sectionFormat="bare" section="6"/> of <xref target="RFC9572"/>). </t> <sectiontitle="Selective Tunnels" anchor="select">anchor="select" numbered="true" toc="default"> <name>Selective Tunnels</name> <t>For"selective tunnels"selective tunnels that instantiate S-PMSIs (see[RFC6513]Sections2.1.1<xref target="RFC6513" sectionFormat="bare" section="2.1.1"/> and3.2.1,<xref target="RFC6513" sectionFormat="bare" section="3.2.1"/> of <xref target="RFC6513"/> and <xreftarget="I-D.ietf-bess-evpn-bum-procedure-updates"/> Section 4),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 particular subset of the PEs that attach to a given VPN or BD. Each set of flows is identified bya Selective PMSIan S-PMSI A-D route[RFC6514].<xref target= "RFC6514"/>. The PTA of the S-PMSI route identifies the tunnel used to carry the corresponding set of flows. Multiple S-PMSI routes can identify the same tunnel. </t> <t> When tunnel segmentation is applied to an S-PMSI, certain nodes are "segmentation points". A segmentation point is a node at the boundary between two"segmentation regions".segmentation regions. Let's call these "region A" and "region B". A segmentation point is an egress node for one or more selective tunnels in regionA,A and an ingress node for one or more selective tunnels in region B. A given segmentation point must be able to receive traffic on a selective tunnel from regionA,A andlabel switchlabel-switch the traffic to the proper selective tunnel in region B. </t> <t>Suppose that one selective tunnel (call itT1)"T1") in region A is carrying two flows, Flow-1 and Flow-2, identified by S-PMSIrouteroutes Route-1 and Route-2, respectively. However, it is possiblethat,that in region B, Flow-1 is not 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 tunnel T3. Then, when the segmentation point receives traffic from T1, it must be able tolabel switchlabel-switch Flow-1 from T1 to T2, while alsolabel switchinglabel-switching Flow-2 from T1 to T3. This implies that Route-1 and Route-2 must signal different labels in the PTA. For comparison, when segmentation is not used, they can all use the common per-VPN/BD DCB label. </t> <t>In this case, it is not practical to have a central entity assign domain-wide unique labels to individual S-PMSI routes. To address this problem, all PEs can be assigned disjoint label blocks in those few context-specific label spaces, and each PE will independently allocate labels for a segmented S-PMSI from its 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 [201~300], and so on. <!-- [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 labels as well, though it does not address the original scaling issue, because there would beone million1,000,000 labels allocated from those fewcontextcontext-specific label spaces in the original example, instead of justone thousand1000 common labels. </t> </section> <sectiontitle="Per-PE/Region Tunnels">numbered="true" toc="default"> <name>Per-PE/Region Tunnels</name> <t>Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN IMET) or per-AS/region (MVPN Inter-AS I-PMSI or EVPNper-Regionper-region I-PMSI) tunnels([RFC6514] [RFC7432]<xreftarget="I-D.ietf-bess-evpn-bum-procedure-updates"/>),target="RFC6514"/> <xref target="RFC7432"/> <xref target="RFC9572" format="default"/>, labels need to be allocated per PMSI route. In the case of a per-PE PMSI route, the labels should be allocated from the label block allocated to the advertising PE. In the case of a per-AS/region PMSI route, differentASBR/RBRs (Regional Border Routers)ASBRs/RBRs attached to the same source AS/region will advertise the same PMSI route. The same label could be used when the same route is advertised by different ASBRs/RBRs, though that requirescoordination andcoordination; a simpler way is for each ASBR/RBR to allocate a label from the label block allocated to itself (see <xreftarget="select"/>).target="select" format="default"/>). </t> <t>In the rest ofthethis document, we call the label allocated for a particular PMSI a(per-)PMSI label,"(per-)PMSI label", just like we have (per-)VPN/BD/ES labels. Notice that using a per-PMSI label in the case of a per-PE PMSI still has the original scaling issue associated with the upstream-assigned label, so per-region PMSIsisare preferred. Within each AS/region, per-PE PMSIs are stillusedused, though they do not go acrossborderborders and per-VPN/BD labels can still be used. </t> <t>Notethat,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 the upstream or downstream segment usesIngress Replication.ingress replication. </t> </section> <sectiontitle="Alternativenumbered="true" toc="default"> <name>Alternative tothe per-PMSIPer-PMSI LabelAllocation"> <t>The per-PMSIAllocation</name> <t>Per-PMSI label allocation in the case of segmentation, whether forS-PMSIS-PMSIs orfor per-PE/Region I-PMSI,per-PE/region I-PMSIs, isfor theapplied so that segmentation pointsto beare able tolabel switchlabel-switch traffic without having to do IP orMAC lookupMedia Access Control (MAC) lookups in VRFs (the segmentation points typically do not have those VRFs at all).IfAlternatively, if the label scaling becomes a concern,alternativelythe segmentation points could use (C-S,C-G)lookuplookups in VRFs for flows identified by the S-PMSIs. This allows the S-PMSIs for the same VPN/BD to share a VPN/BD-identifying label that leads tolook uplookups in the VRFs. That label needs to be different from the label used in the per-PE/region I-PMSIs though, so that the segmentation points canlabel switchlabel-switch other traffic (not identified by those S-PMSIs). 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. </t> </section> </section> <sectiontitle="Summaryanchor="methods" numbered="true" toc="default"> <name>Summary of Label AllocationMethods" anchor="methods">Methods</name> <t>In summary, labels can be allocated and advertised in the following ways:<list style="numbers"> <t</t> <ol spacing="normal" type="1"> <li anchor="dcb-assignment">A central entity allocates per-VPN/BD/ES labels from the DCB. PEs advertise the labels with an indication that they are from the DCB.</t> <t</li> <li anchor="context-space">A central entity allocates per-VPN/BD/ES labels from a few common context-specific labelspaces,spaces andallocateallocates labels from the DCB to identify those context-specific label spaces. PEs advertise the VPN/BD labels along with the context-identifying labels.</t> <t</li> <li anchor="context-block">A central entity assigns disjoint label blocks from a few context-specific label spaces to eachPE,PE and allocates labels from the DCB to identify those context-specific label spaces. A PE independently allocates a label for a segmented S-PMSI from its assigned labelblock,block and advertises the label along with the context-identifying label.</t> </list> </t></li> </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 DCB that is large enough for all theVPNs/BDs/ESesVPNs/BDs/ESs combined. Option <xref target="context-block" format="counter"/> is needed only for segmented selective tunnels that are set up dynamically. Multiple options could be used in anycombinationcombination, depending on the deployment situation. </t> </section> </section></section><sectiontitle="Specification"> <t> </t>numbered="true" toc="default"> <name>Specification</name> <!-- [rfced] "Specification" section: The meaning and purpose of this section title are unclear. Would "Specifications" be clearer, or perhaps something more descriptive (e.g., "New Extended Community and Related Procedures", assuming that this title would be accurate)? Original: 3. Specification --> <sectiontitle="Context-Specificnumbered="true" toc="default"> <name>Context-Specific Label Space ID ExtendedCommunity"> <t>Context-SpecificCommunity</name> <t>The Context-Specific Label Space ID Extended Community (EC) is a new Transitive Opaque EC with the following structure:<figure></t> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 or 0x43 | 8 | ID-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID-Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure> <list style="symbols"> <t>ID-Type: A<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 alabel. </t> <t>ID-Value: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 is set to the label value.</dd> <!-- [rfced] "Context-Specific Label Space ID Extended Community" section: Please clarify the meaning of "most significant 20-bit". Does it mean "most significant 20 bits", "most significant 20-bit portion", or something else? Is this related to Erratum ID 5554 for RFC 7432 (https://www.rfc-editor.org/errata/eid5554)? Original: * ID-Value: A 4-octet field that specifies the value of Label Space ID. When it is a label (with ID-Type 0), the most significant 20-bit is set to the label value.</t> </list> </t>--> </dl> <t>This document introduces aDCB flagDCB-flag (Bit 47 as assigned by IANA) in the "Additional PMSI Tunnel Attribute Flags" BGP Extended Community[RFC7902].<xref target="RFC7902" format="default"/>. </t> <t>In the remainder of this document, when we say that a BGP-MVPN/EVPN A-D route "carries the DCB-flag" or "has a DCB-flag attached", we mean the following: <!-- [rfced] "Context-Specific Label Space ID Extended Community" section: We see one instance each of "carry a DCB-flag" and "carries the DCB-flag" in the "Procedures" section. However, we do not see any instances of "has DCB-flag attached" or "DCB-flag attached" elsewhere in this document. To avoid confusion, we suggest either removing the quotes in this sentence or rephrasing the text. 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:<list style="symbols"> <t>ThePossibly: In the remainder of this document, when we say that a BGP-MVPN/EVPN A-D route carries aPMSI Tunnel Attribute (PTA)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, </t> <t>TheAND</li> <li>The route carries an "Additional PMSI Tunnel Attribute Flags" EC and itsDCB flagDCB-flag isset </t> </list> </t>set.</li> </ul> </section> <sectiontitle="Procedures">numbered="true" toc="default"> <name>Procedures</name> <t>The protocol and procedures specified in this sectionMAY<bcp14>MAY</bcp14> be used whenBIER,BIER or P2MP/MP2MP tunnel aggregation is used forMVPN/EVPN,an MVPN/EVPN or when BIER/P2MP/MP2MP tunnels are used with EVPNmulti-homing.multihoming. When these procedures are used, all PE routers and segmentation pointsMUST<bcp14>MUST</bcp14> support the procedures.ItHow to ensure this behavior is outside the scope of thisdocument how thatdocument. <!-- [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 isensured.used for an MVPN/EVPN or when BIER/P2MP/MP2MP tunnels are used with EVPN multihoming. --> </t><t>By means<t>Via methods outside the scope of this document, each VPN/BD/ES is assigned a label from the DCB or one of those few context-specific label spaces, and every PE that is part of the VPN/BD/ES is aware of the assignment. The ES label and the BD labelMUST<bcp14>MUST</bcp14> be assigned from the same label space. If PE DistinguisherlabelsLabels are used[RFC7582],<xref target="RFC7582" format="default"/>, theyMUST<bcp14>MUST</bcp14> be allocated from the same label space as well. </t> <t>In the case of tunnel segmentation, each PE is also assigned a disjoint label block from one of those few context-specific labelspacesspaces, and it allocates labels for its segmented PMSI routes from its assigned label block. </t> <t>When a PE originates/re-advertises an x-PMSI/IMET route, the routeMUST<bcp14>MUST</bcp14> carry a DCB-flag if and only if the label in its PTA is assigned from the DCB. </t> <t>If the VPN/BD/ES/PMSI label is assigned from one of those few context-specific label spaces, a Context-Specific Label Space IDExtended Community MUSTEC <bcp14>MUST</bcp14> be attached to the route. The ID-Type in the EC is set to00, and the ID-Value is set to a label allocated from the DCB and identifies the context-specific label space. When an ingress PE sends traffic, it imposes the DCB label that identifies the context-specific label space after it imposes the label (that is advertised in the Label field of the PTA in the x-PMSI/IMET route) 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. </t> <t>When a PE receives an x-PMSI/IMET route with the Context-Specific Label Space ID EC, itMUST<bcp14>MUST</bcp14> place an entry in its default MPLS forwarding table 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 data traffic with the label signaled in the EC. </t> <t>Then, the receiving PEMUST<bcp14>MUST</bcp14> place an entry for the label that is in the PTA or ESI Label ECintoin either the default MPLS forwarding table (if the route carries the DCB-flag) or the context-specific label table (if the Context-Specific Label Space ID EC is present) according to the x-PMSI/IMET route. </t> <t>An x-PMSI/IMET routeMUST NOT both<bcp14>MUST NOT</bcp14> carry both the DCB-flag and the Context-Specific Label Space ID EC. A received route with both the DCB-flag set and theContextContext-Specific Label Space ID EC attachedMUST<bcp14>MUST</bcp14> be treated as withdrawn. If neither the DCB-flag nor the Context-Specific Label Space ID EC is attached, the label in the PTA or ESI Label ECMUST<bcp14>MUST</bcp14> be treated as the upstream-assigned label from the label space of the source PE, and procedures provided in[RFC6514][RFC7432] MUST<xref target="RFC6514"/> and <xref target="RFC7432"/> <bcp14>MUST</bcp14> be followed. <!-- [rfced] "Procedures" section: As it appears that "both" refers 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, itMUST<bcp14>MUST</bcp14> ensure that one of the following scenarios applies, so that the PE receiving the routes can correctly interpret the label that follows the tunnel encapsulation of data packets arriving via thetunnel. <list style="symbols"> <t>They MUSTtunnel: </t> <ul spacing="normal"> <li>They <bcp14>MUST</bcp14> all have theDCB-flag, or, </t> <t>They MUSTDCB-flag,</li> <li>They <bcp14>MUST</bcp14> all carry the Context-Specific Label Space IDEC, or, </t> <t>NoneEC,</li> <li>None of themhashave the DCB-flag,or, </t> <t>Noneor</li> <li>None of them carry the Context-Specific Label Space IDEC. </t> </list> </t>EC.</li> </ul> <t>Otherwise, a receiving PEMUST<bcp14>MUST</bcp14> treat the routes as if they were withdrawn. </t> </section> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This document allows three methods (<xreftarget="methods"/>)target="methods" format="default"/>) of label allocation for MVPN[RFC6514]PEs <xref target="RFC6514"/> or EVPN[RFC7432]PEs <xref target="RFC7432"/> and specifies corresponding signaling and procedures. The first method (Option <xref target="dcb-assignment" format="counter"/>) is the equivalent of using common SRGBs[RFC8402]<xref target="RFC8402"/> from the regularper platformper-platform label space. The secondonemethod (Option <xref target="context-space" format="counter"/>) is the equivalent of using common SRGBs from athird partythird-party label space[RFC5331].<xref target="RFC5331" format="default"/>. The third method (Option <xref target="context-block" format="counter"/>) is a variation of thesecond,second in that thethird partythird-party label space is divided into disjoint blocks for use by different PEs,whowhere each PE will use labels fromtheirits respective block to send traffic. In all cases, a receiving PE is able to identify one of a few label forwarding tables to forward incoming labeled traffic.</t> <t>None<!-- [rfced] Security Considerations: Should "one of a few" be "one or a few" or "one or several" here, or does the[RFC6514], [RFC7432], [RFC8402]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><xref target="RFC6514"/>, <xref target="RFC7432"/>, <xref target="RFC8402"/>, and[RFC5331] specifications lists<xref target="RFC5331" format="default"/> do not list any security concerns related to label allocation methods, and this document does not introduce any new security concernseither.in this regard. </t> </section> <sectiontitle="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA has made the following assignments:<list style="symbols"></t> <ul spacing="normal"> <li> <t>Bit 47 (DCB)fromin the "Additional PMSI Tunnel Attribute Flags"registry <figure> <artwork> Bit Flag Name Reference -------- ---------------------- ------------- 47 DCB (temporary) This document </artwork> </figure> </t>registry:</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 Community"fromin the "Transitive Opaque Extended Community Sub-Types"registry <figure> <artwork> Sub-Type Value Name Reference -------------- ---------------------- ------------- 0x08 Context-Specificregistry: </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 IDThis documentExtendedCommunity </artwork> </figure> </t> </list> </t>Community</td> <td>RFC 9573</td> </tr> </tbody> </table> </li> </ul> <t>IANAis requested to create ahas created the "Context-Specific Label Space ID Type" registryinwithin the "Border Gateway Protocol (BGP) Extended Communities"group.group of registries. The registration procedure is First Come FirstServed.Served <xref target="RFC8126"/>. The initial assignment is as follows:<figure> <artwork> ID Type Name Reference ------- ---------------------- ------------- 0 MPLS Label This document 1-254 unassigned 255 reserved </artwork> </figure> </t><!-- [rfced] Section 5: We cited RFC 8126 here, per standard practice (e.g., RFCs 9251 and 9252), and we added a listing for RFC 8126 in the Informative References section. Please let us know any concerns. Original: The registration procedure is First Come First Served. 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> <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> </middle> <back> <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.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7524.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7582.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7902.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4360.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5331.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8556.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.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"title="Acknowledgements">numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors thankStephane Litkowski, Ali Sajassi and Jingrong Xie<contact fullname="Stephane Litkowski"/>, <contact fullname="Ali Sajassi"/>, and <contact fullname="Jingrong Xie"/> for theirreviewreviews of, commentsonon, and suggestions for this document. </t> </section> <sectiontitle="Contributors">numbered="false" toc="default"> <name>Contributors</name> <t>The following individual also contributed to thisdocument. <figure> <artwork> Selvakumar Sivaraj Juniper Networks Email: ssivaraj@juniper.net </artwork> </figure>document: </t> <contact fullname="Selvakumar Sivaraj"> <organization>Juniper Networks</organization> <address> <email>ssivaraj@juniper.net</email> </address> </contact> </section></middle> <back> <references title="Normative References"> <?rfc include='reference.RFC.2119.xml'?> <?rfc include='reference.RFC.8174.xml'?> <?rfc include='reference.RFC.6513.xml'?> <?rfc include='reference.RFC.6514.xml'?> <?rfc include='reference.RFC.7432.xml'?> <?rfc include='reference.RFC.7524.xml'?> <?rfc include='reference.RFC.7582.xml'?> <?rfc include='reference.RFC.7902.xml'?> <?rfc include='reference.RFC.4360.xml'?> </references> <references title="Informative References"> <?rfc include='reference.RFC.5331.xml'?> <?rfc include='reference.RFC.8279.xml'?> <?rfc include='reference.RFC.8556.xml'?> <?rfc include='reference.RFC.8402.xml'?> <?rfc include='reference.RFC.8660.xml'?> <?rfc include='reference.RFC.4364.xml'?> <?rfc include='reference.I-D.ietf-bier-evpn.xml'?> <?rfc include='reference.I-D.ietf-bess-evpn-bum-procedure-updates.xml'?> </references></back> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> <!-- [rfced] Please let us know if any changes are needed for the following: a) The following terms/values were used inconsistently in this document. We chose to use the latter forms. Please let us know any objections. 1,000 / 1000 1,001 / 1001 context label spaces (1 instance) / context-specific label spaces 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.) --> </rfc>