rfc9573v3.txt   rfc9573.txt 
skipping to change at line 12 skipping to change at line 12
Internet Engineering Task Force (IETF) Z. Zhang Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 9573 Juniper Networks Request for Comments: 9573 Juniper Networks
Updates: 6514, 7432, 7582 E. Rosen Updates: 6514, 7432, 7582 E. Rosen
Category: Standards Track Individual Category: Standards Track Individual
ISSN: 2070-1721 W. Lin ISSN: 2070-1721 W. Lin
Juniper Networks Juniper Networks
Z. Li Z. Li
Huawei Technologies Huawei Technologies
IJ. Wijnands IJ. Wijnands
Individual Individual
April 2024 May 2024
MVPN/EVPN Tunnel Aggregation with Common Labels MVPN/EVPN Tunnel Aggregation with Common Labels
Abstract Abstract
The Multicast VPN (MVPN) specifications allow a single Point-to- The Multicast VPN (MVPN) specifications allow a single Point-to-
Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs
(referred to as VPNs in this document). The EVPN specifications (referred to as VPNs in this document). 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
skipping to change at line 296 skipping to change at line 296
One method of achieving this is to reserve a portion of the default One method of achieving this is to reserve a portion of the default
label space for assignment by a central entity. We refer to this label space for assignment by a central entity. We refer to this
reserved portion as the DCB of labels. This is analogous to the reserved portion as the DCB of labels. This is analogous to the
concept of using identical SRGBs on all nodes, as described in concept of using identical SRGBs on all nodes, as described in
[RFC8402]. A PE that is attached (via L3VPN Virtual Routing and [RFC8402]. A PE that is attached (via L3VPN Virtual Routing and
Forwarding (VRF) interfaces or EVPN Attachment Circuits) would know Forwarding (VRF) interfaces or EVPN Attachment Circuits) would know
by provisioning which label from the DCB corresponds to which of its by provisioning which label from the DCB corresponds to which of its
locally attached VPNs, BDs, or ESs. locally attached VPNs, BDs, or ESs.
For example, all PEs could reserve a DCB [1000~2000], and they are For example, all PEs could reserve a DCB [1000~2000], and they would
all provisioned that label 1000 maps to VPN 0, 1001 to VPN 1, and so all be provisioned so that label 1000 maps to VPN 0, label 1001 maps
forth. Now, only 1000 labels instead of 1,000,000 labels are needed to VPN 1, and so forth. Now, only 1000 labels instead of 1,000,000
for 1000 VPNs. labels are needed for 1000 VPNs.
In this document, "domain" is defined loosely; it simply includes all 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 the routers that share the same DCB, and it only needs to include all
PEs of an MVPN/EVPN. PEs of an MVPN/EVPN.
The "domain" could also include all routers in the provider network, The "domain" could also include all routers in the provider network,
making it not much different from a common SRGB across all the making it not much different from a common SRGB across all the
routers. However, that is not necessary, as the labels used by PEs routers. However, that is not necessary, as the labels used by PEs
for the purposes defined in this document will only rise to the top for the purposes defined in this document will only rise to the top
of the label stack when traffic arrives at the PEs. Therefore, it is of the label stack when traffic arrives at the PEs. Therefore, it is
better to not include internal P routers in the "domain". That way, better to not include internal P routers in the "domain". That way,
they do not have to set aside the same DCB used for the purposes they do not have to set aside the same DCB used for the purposes
defined in this document. defined in this document.
In some deployments, it may be impractical to allocate a DCB that is In some deployments, it may be impractical to allocate a DCB that is
large enough to contain labels for all the VPNs/BDs/ESs. 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 label case, it may be necessary to allocate those labels from one or a few
space or the few separate context-specific label spaces that are context-specific label spaces that are independent of each PE. For
independent of each PE. For example, if it is too difficult to have example, if it is too difficult to have a DCB of 10,000 labels across
a DCB of 10,000 labels across all PEs for all the VPNs/BDs/ESs that all PEs for all the VPNs/BDs/ESs that need to be supported, a
need to be supported, a separate context-specific label space can be separate context-specific label space can be dedicated to those
dedicated to those 10,000 labels. Each separate context-specific 10,000 labels. Each separate context-specific label space is
label space is identified in the forwarding plane by a label from the identified in the forwarding plane by a label from the DCB (which
DCB (which does not need to be large). Each PE is provisioned with does not need to be large). Each PE is provisioned with the label-
the label-space-identifying DCB label and the common VPN/BD/ES labels space-identifying DCB label and the common VPN/BD/ES labels allocated
allocated from that context-specific label space. When sending from that context-specific label space. When sending traffic, an
traffic, an ingress PE imposes all necessary service labels (for the ingress PE imposes all necessary service labels (for the VPN/BD/ES)
VPN/BD/ES) first, then imposes the label-space-identifying DCB label. first, then imposes the label-space-identifying DCB label. From the
From the label-space-identifying DCB label, an egress PE can label-space-identifying DCB label, an egress PE can determine the
determine the label space where the inner VPN/BD/ES label is looked label space where the inner VPN/BD/ES label is looked up.
up.
The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes
that certain MPLS labels are allocated from a context-specific label that certain MPLS labels are allocated from a context-specific label
space for a particular ingress PE. In this document, we augment the space for a particular ingress PE. In this document, we augment the
signaling procedures so that it is possible to signal that a signaling procedures so that it is possible to signal that a
particular label is from the DCB, rather than from a context-specific particular label is from the DCB, rather than from a context-specific
label space for an ingress PE. We also augment the signaling so that label space for an ingress PE. We also augment the signaling so that
it is possible to indicate that a particular label is from an it is possible to indicate that a particular label is from an
identified context-specific label space that is not for an ingress identified context-specific label space that is not for an ingress
PE. PE.
skipping to change at line 357 skipping to change at line 356
from allocating VNIs and is especially feasible with controllers. from allocating VNIs and is especially feasible with controllers.
3.1. MP2MP Tunnels 3.1. MP2MP Tunnels
Multipoint-to-Multipoint (MP2MP) tunnels present the same problem Multipoint-to-Multipoint (MP2MP) tunnels present the same problem
(Section 2) that can be solved the same way (Section 3), with the (Section 2) that can be solved the same way (Section 3), with the
following additional requirement. following additional requirement.
Per [RFC7582] ("Multicast Virtual Private Network (MVPN): Using Per [RFC7582] ("Multicast Virtual Private Network (MVPN): Using
Bidirectional P-Tunnels"), when MP2MP tunnels are used for an MVPN, Bidirectional P-Tunnels"), when MP2MP tunnels are used for an MVPN,
the root of the MP2MP tunnel may need to allocate and advertise "PE the root of the MP2MP tunnel is required to allocate and advertise
Distinguisher Labels" (Section 4 of [RFC6513]). These labels are "PE Distinguisher Labels" (Section 4 of [RFC6513]). These labels are
assigned from the label space used by the root node for its upstream- assigned from the label space used by the root node for its upstream-
assigned labels. assigned labels.
It is REQUIRED by this document that the PE Distinguisher Labels It is REQUIRED by this document that the PE Distinguisher Labels
allocated by a particular node come from the same label space that allocated by a particular node come from the same label space that
the node uses to allocate its VPN-identifying labels. the node uses to allocate its VPN-identifying labels.
3.2. Segmented Tunnels 3.2. Segmented Tunnels
There are some additional issues to be considered when an MVPN or There are some additional issues to be considered when an MVPN or
skipping to change at line 761 skipping to change at line 760
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660, Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019, DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>. <https://www.rfc-editor.org/info/rfc8660>.
[RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. [RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or
Multicast (BUM) Procedures", RFC 9572, Multicast (BUM) Procedures", RFC 9572,
DOI 10.17487/RFC9572, April 2024, DOI 10.17487/RFC9572, May 2024,
<https://www.rfc-editor.org/info/rfc9572>. <https://www.rfc-editor.org/info/rfc9572>.
Acknowledgements Acknowledgements
The authors thank Stephane Litkowski, Ali Sajassi, and Jingrong Xie The authors thank Stephane Litkowski, Ali Sajassi, and Jingrong Xie
for their reviews of, comments on, and suggestions for this document. for their reviews of, comments on, and suggestions for this document.
Contributors Contributors
The following individual also contributed to this document: The following individual also contributed to this document:
 End of changes. 5 change blocks. 
23 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.48.