Internet DRAFT - draft-ietf-bess-mvpn-evpn-aggregation-label
draft-ietf-bess-mvpn-evpn-aggregation-label
BESS Z. Zhang
Internet-Draft Juniper Networks
Updates: 7432, 6514, 7582 (if approved) E. Rosen
Intended status: Standards Track Individual
Expires: 15 June 2023 W. Lin
Juniper Networks
Z. Li
Huawei Technologies
I. Wijnands
Individual
12 December 2022
MVPN/EVPN Tunnel Aggregation with Common Labels
draft-ietf-bess-mvpn-evpn-aggregation-label-09
Abstract
The MVPN specifications allow a single Point-to-Multipoint (P2MP)
tunnel to carry traffic of multiple VPNs. 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) 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, 7432 and 7582 by specifying the necessary
procedures.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Zhang, et al. Expires 15 June 2023 [Page 1]
Internet-Draft mvpn-evpn-aggregation-label December 2022
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 15 June 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 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 of Label Allocation Methods . . . . . . . . . 10
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Context-Specific Label Space ID Extended Community . . . 11
3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Zhang, et al. Expires 15 June 2023 [Page 2]
Internet-Draft mvpn-evpn-aggregation-label December 2022
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Terminologies
Familiarity with MVPN/EVPN protocols and procedures is assumed. Some
terminologies are listed below for convenience.
* BUM [RFC7432]: Broadcast, Unknown Unicast, or Multicast (traffic).
* BD [RFC7432]: Broadcast Domain.
* PMSI [RFC6513]: Provider Multicast Service Interface - a pseudo
overlay interface for PEs to send certain overlay/customer
multicast traffic via underlay/provider tunnels. Includes I/
S-PMSI (often referred to as x-PMSI) for Inclusive/Selective PMSI.
A PMSI is instantiated by the underlay/provider tunnel.
* 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.
* Selective PMSI: A PMSI that enables traffic to be sent to a sub
set of PEs of a VPN/BD. The underlay/provider tunnel that
instantiates the Selective PMSI is referred to as a selective
tunnel.
* Aggregate Tunnel: a tunnel that instantiates x-PMSIs of multiple
MVPNs or EVPN BDs.
* IMET [RFC7432]: Inclusive Multicast Ethernet Tag route. An EVPN
specific name for I-PMSI A-D route.
* PTA [RFC6514]: PMSI Tunnel Attribute. A BGP attribute that may be
attached to an BGP-MVPN/EVPN x-PMXI A-D routes.
* RBR: Regional Border Routers. Border routers between segmentation
regions that participate in segmentation procedures.
* (C-S,C-G): A Customer/overlay <S,G> multicast flow.
* (C-*,C-G): Customer/overlay <*,G> multicast flows.
* (C-*,C-*): All Customer/overlay multicast flows.
* ESI [RFC7432]: Ethernet Segment Identifier.
Zhang, et al. Expires 15 June 2023 [Page 3]
Internet-Draft mvpn-evpn-aggregation-label December 2022
* ESI Label[RFC7432]: A label that identifies an Ethernet Segment
* SRGB [RFC8402]: SR Global Block, the set of global segments in the
SR domain. In SR-MPLS, SRGB is a local property of a node and
identifies the set of local labels reserved for global segments.
In SR-MPLS, using identical SRGBs on all nodes within the SR
domain is strongly recommended.
* DCB: Domain-wide Common Block, a common block of labels reserved
on all nodes in a domain.
* Context-specific Label Space [RFC5331]: A router may maintain
additional label spaces besides its default label space. When the
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 lookup the
label, hence those label spaces are referred to as context-
specific label spaces.
* 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 context-specific
label space specific for the assigner.
2. Introduction
MVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) to
transport customer multicast traffic across a service provider's
backbone network. Often, a given P2MP tunnel carries the traffic of
only a single VPN. There are however procedures defined that allow a
single P2MP tunnel to carry traffic of multiple VPNs. In this case,
the P2MP tunnel is called an "aggregate tunnel". The PE router that
is the ingress node of an aggregate P2MP tunnel allocates an
"upstream-assigned MPLS label" [RFC5331] for each VPN, and each
packet sent on the P2MP tunnel carries the upstream-assigned MPLS
label that the ingress PE has bound to the packet's VPN.
Zhang, et al. Expires 15 June 2023 [Page 4]
Internet-Draft mvpn-evpn-aggregation-label December 2022
Similarly, EVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or
PIM) to transport BUM traffic (Broadcast traffic, Unicast traffic
with an Unknown address, or Multicast traffic), across the provider
network. Often a P2MP tunnel carries the traffic of only a single
BD. However, there are procedures defined that allow a single P2MP
tunnel to be an "aggregate tunnel" that carries traffic of multiple
BDs. The procedures are analogous to the MVPN procedures -- the PE
router that is the ingress node of an aggregate P2MP tunnel allocates
an upstream-assigned MPLS label for each BD, and each packet sent on
the P2MP tunnel carries the upstream-assigned MPLS label that the
ingress PE has bound to the packet's BD.
MVPN and EVPN can also use BIER [RFC8279] to transmit multicast
traffic or BUM traffic [RFC8556] [I-D.ietf-bier-evpn]. Although BIER
does not explicitly set up P2MP tunnels, from the perspective of
MVPN/EVPN, the use of BIER transport is very similar to the use of
aggregate P2MP tunnels. When BIER is used, the PE transmitting a
packet (the "BFIR" [RFC8279]) must allocate an upstream-assigned MPLS
label for each VPN or BD, and the packets transmitted using BIER
transport always carry the label that identifies their VPN or BD.
(See [RFC8556] and [I-D.ietf-bier-evpn] for the details.) In the
remainder of this document, we will use the term "aggregate tunnels"
to include both P2MP tunnels and BIER transport.
When an egress PE receives a packet from an aggregate tunnel, it must
look at the upstream-assigned label carried by the packet, and must
interpret that label in the context of the ingress PE. Essentially,
for each ingress PE, the egress PE has a context-specific label space
[RFC5331] that matches the ingress PE's 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
packet's ingress PE. How an egress PE identifies the ingress PE of a
given packet depends on the tunnel type.
2.1. Problem Description
Note that these procedures may require a very large number of labels.
Suppose 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 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.
Zhang, et al. Expires 15 June 2023 [Page 5]
Internet-Draft mvpn-evpn-aggregation-label December 2022
At the present time, 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:
* In 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
intermediate nodes.
* The use of BIER as transport for MVPN/EVPN is becoming more and
more attractive and feasible.
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 simply specifies a way to increase label
scaling when tunnel aggregation is used.
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 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 source ES, and thus will not transmit the
packet on 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 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. If there are 1,001 PEs, each
attached to 1,000 ESes, 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. one tunnel used for multiple BDs) is used.
2.2. Proposed Solution
The number of labels could be greatly reduced if a central authority
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
total number of labels needed would just be the sum of the number of
VPNs, BD, and/or ESes.
Zhang, et al. Expires 15 June 2023 [Page 6]
Internet-Draft mvpn-evpn-aggregation-label December 2022
One method of achieving this is to reserve a portion of the default
label space for assignment by a central authority. We refer to this
reserved portion as the "Domain-wide Common Block" (DCB) of labels.
This is analogous to the identical "Segment Routing Global Block"
(SRGB) on all nodes that is described in [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 ESes.
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. Now only 1000 label instead of 1,000,000 labels are needed
for 1000 VPNs.
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.
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 not necessary 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 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 the purposes in
this document.
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
case, it may be necessary to allocate those labels from one or a few
separate context-specific label spaces independent of each PE. For
example, if it is too difficult to have a DCB of 10,000 labels across
all PEs for all the VPNs/BDs/ESes that need to be supported, a
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 DCB label an egress PE can determine the
label space where the inner VPN/BD/ES label is looked up.
The MVPN/EVPN signaling defined in [RFC6514] and [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
Zhang, et al. Expires 15 June 2023 [Page 7]
Internet-Draft mvpn-evpn-aggregation-label December 2022
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.
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. Allocating a label from the DCB or from those a few context-
specific label spaces and communicating them to all PEs is not
different from allocating VNIs, and is feasible in today's networks
since controllers are used more and more widely.
2.2.1. MP2MP Tunnels
MP2MP tunnels present the same problem (Section 2.1) that can be
solved the same way (Section 2.2), with the following additional
requirement.
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]. These labels are assigned from the label space used by
the root node for its upstream-assigned labels.
It is REQUIRED by this document that the PE Distinguisher labels
allocated by a particular node come from the same label space that
the node uses to allocate its VPN-identifying labels.
2.2.2. Segmented Tunnels
There are some additional issues to be considered when MVPN or EVPN
is using "tunnel segmentation" (see [RFC6514], [RFC7524], and
[I-D.ietf-bess-evpn-bum-procedure-updates] Sections 5 and 6).
2.2.2.1. Selective Tunnels
For "selective tunnels" that instantiate S-PMSIs (see [RFC6513]
Sections 2.1.1 and 3.2.1, and
[I-D.ietf-bess-evpn-bum-procedure-updates] Section 4), the procedures
outlined above work only if tunnel segmentation is not used.
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 by a Selective PMSI A-D route [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.
Zhang, et al. Expires 15 June 2023 [Page 8]
Internet-Draft mvpn-evpn-aggregation-label December 2022
When tunnel segmentation is applied to a S-PMSI, certain nodes are
"segmentation points". A segmentation point is a node at the
boundary between two "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 region 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
region A, and label switch the traffic to the proper selective tunnel
in region B.
Suppose one 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. However, it is possible 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 to label switch Flow-1 from T1 to
T2, while also label 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.
In this case, it is not practical to have a central authority 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 will allocate labels for
segmented S-PMSI independently 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.
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 be one million labels allocated from those
a few context label spaces in the original example, instead of just
one thousand common labels.
2.2.2.2. Per-PE/Region Tunnels
Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN IMET)
or per-AS/region (MVPN Inter-AS I-PMSI or EVPN per-Region I-PMSI)
tunnels ([RFC6514] [RFC7432]
[I-D.ietf-bess-evpn-bum-procedure-updates]), labels need to be
allocated per PMSI route. In case of per-PE PMSI route, the labels
should be allocated from the label block allocated to the advertising
PE. In case of per-AS/region PMSI route, different ASBR/RBRs
(Regional Border Routers) 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
Zhang, et al. Expires 15 June 2023 [Page 9]
Internet-Draft mvpn-evpn-aggregation-label December 2022
requires coordination and a simpler way is for each ASBR/RBR to
allocate a label from the label block allocated to itself (see
Section 2.2.2.1).
In the rest of the document, we call the label allocated for a
particular PMSI a (per-)PMSI label, just like we have (per-)VPN/BD/ES
labels. Notice that using per-PMSI label in case of per-PE PMSI
still has the original scaling issue associated with the upstream-
assigned label, so per-region PMSIs is 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 be used.
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
the upstream or downstream segment uses Ingress Replication.
2.2.2.3. Alternative to the per-PMSI Label Allocation
The per-PMSI label allocation in case of segmentation, whether for
S-PMSI or for per-PE/Region I-PMSI, is for the segmentation points to
be able to label switch traffic w/o having to do IP or MAC lookup in
VRFs (the segmentation points typically do not have those VRFs at
all). If the label scaling becomes a concern, alternatively the
segmentation points could use (C-S,C-G) lookup in VRFs for flows
identified by the S-PMSIs. This allows the S-PMSIs for the same VPN/
BD to share the a VPN/BD-identifying label that leads to lookup 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 can
label 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.
2.2.3. Summary of Label Allocation Methods
In summary, labels can be allocated and advertised the following
ways:
1. A central authority allocates per-VPN/BD/ES labels from the DCB.
PEs advertise the labels with an indication that they are from
the DCB.
2. A central authority allocates per-VPN/BD/ES labels from a few
common context-specific label spaces, and allocate labels from
the DCB to identify those context-specific label spaces. PEs
advertise the VPN/BD labels along with the context-identifying
labels.
Zhang, et al. Expires 15 June 2023 [Page 10]
Internet-Draft mvpn-evpn-aggregation-label December 2022
3. A central authority assigns disjoint label blocks from those a
few context-specific label spaces to each PE, and allocate labels
from the DCB to identify the context-specific label spaces. Each
PE allocates labels from its assigned label block independently
for its segmented S-PMSI, along with the context-identifying
labels.
Option 1 is simplest, but it requires that all the PEs set aside a
common label block for the DCB that is large enough for all the
VPNs/BDs/ESes combined. Option 3 is needed only for segmented
selective tunnels that are set up dynamically. Multiple options
could be used in any combination depending on the deployment
situation.
3. Specification
3.1. Context-Specific Label Space ID Extended Community
Context-Specific Label Space ID Extended Community is a new
Transitive Opaque EC with the following structure (Sub-Type value to
be assigned by IANA):
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 | Sub-Type | ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* 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 field is a label.
* ID-Value: A 4-octet field that specifies the value of Label Space
ID. When it is a label (with ID-Value 0), the most significant
20-bit is set to the label value.
This document introduces a DCB flag (to be assigned by IANA) in the
"Additional PMSI Tunnel Attribute Flags" BGP Extended Community
[RFC7902].
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:
Zhang, et al. Expires 15 June 2023 [Page 11]
Internet-Draft mvpn-evpn-aggregation-label December 2022
* The route carries a PMSI Tunnel Attribute (PTA) and its Flags
field has the Extension bit set
* The route carries an "Additional PMSI Tunnel Attribute Flags" EC
and its DCB flag is set
3.2. Procedures
The protocol and procedures specified in this section need not be
applied unless when BIER, or P2MP/MP2MP tunnel aggregation 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
segmentation points MUST support the procedures. It is outside the
scope of this document how that is ensured.
By means 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 label MUST be assigned from
the same label space. If PE Distinguisher labels are used [RFC7582],
they MUST be allocated from the same label space as well.
In case of tunnel segmentation, each PE is also assigned a disjoint
label block from one of those few context-specific label spaces and
it allocates labels for its segmented PMSI routes from its assigned
label block.
When a PE originates/re-advertises an x-PMSI/IMET route, the route
MUST carry a DCB-flag if and only if the label in its PTA is assigned
from the DCB.
If the VPN/BD/ES/PMSI label is assigned from one of those few
context-specific label spaces, a Context-Specific Label Space ID
Extended Community is attached to the 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. 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 PTA's Label field of 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.
When a PE receives an x-PMSI/IMET route with the Context-Specific
Label Space ID EC, it MUST program its default MPLS forwarding table
to map the label in the EC that identifies the context-specific label
space to a corresponding context-specific label table in which the
next label lookup is done for traffic that this PE receives.
Zhang, et al. Expires 15 June 2023 [Page 12]
Internet-Draft mvpn-evpn-aggregation-label December 2022
Then, the receiving PE MUST program the label in the PTA or ESI Label
EC into 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.
A PE MUST NOT both carry the DCB-flag in an x-PMSI/IMET route and
attach the Context-Specific Label Space ID EC in the route. A PE
MUST ignore a received route with both the DCB-flag and the Context
Label Space ID EC attached, treating as if it was not received. If
neither the DCB-flag nor the Context-Specific Label Space ID EC is
attached, the label in the PTA or ESI Label EC MUST be treated as the
upstream-assigned from the source PE's label space, and procedures in
[RFC6514][RFC7432] MUST be followed.
In case of MPLS P2MP tunnels, if two x-PMSI/IMET routes specify the
same tunnel, one of the following conditions MUST be met, so that a
receiving PE can correctly interpret the label that follows the
tunnel label in the right context.
* They MUST all have the DCB-flag, or,
* They MUST all carry the Context-Specific Label Space ID EC, or,
* None of them has the DCB-flag, or,
* None of them carry the Context-Specific Label Space ID EC.
4. Security Considerations
This document allows three methods (Section 2.2.3) of label
allocation for MVPN/EVPN PEs and specifies corresponding signaling
and procedures. The first method is the equivalent of using common
SRGBs from the regular per platform label space. The second one is
the equivalent of using common SRGBs from a third party's label
space, which is also considered as an upstream-assigned label
allocation [RFC5331]. The third method is a variation of the second,
in that the third party's label space is divided into disjoint blocks
for use by different PEs, who will use labels from their respective
block to send traffic. In all cases, a receiving PE is able to
identify one of a few LFIBs to forward incoming labeled traffic.
Therefore, this document does not introduce new security issues
besides what have been discussed in existing specifications [RFC5331]
[RFC6514] [RFC7432] [RFC8402].
Zhang, et al. Expires 15 June 2023 [Page 13]
Internet-Draft mvpn-evpn-aggregation-label December 2022
5. IANA Considerations
IANA has made the following assignments:
* Bit 47 (DCB) from the "Additional PMSI Tunnel Attribute Flags"
registry
Bit Flag Name Reference
-------- ---------------------- -------------
47 DCB (temporary) This document
* Sub-type 0x08 for "Context-Specific Label Space ID Extended
Community" from the "Transitive Opaque Extended Community Sub-
Types" registry
Sub-Type Value Name Reference
-------------- ---------------------- -------------
0x08 Context-Specific Label Space ID This document
Extended Community
6. Acknowledgements
The authors thank Stephane Litkowski, Ali Sajassi and Jingrong Xie
for their review of, comments on and suggestions for this document.
7. Contributors
The following also contributed to this document.
Selvakumar Sivaraj
Juniper Networks
Email: ssivaraj@juniper.net
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
Zhang, et al. Expires 15 June 2023 [Page 14]
Internet-Draft mvpn-evpn-aggregation-label December 2022
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<https://www.rfc-editor.org/info/rfc7524>.
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
"Multicast Virtual Private Network (MVPN): Using
Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
July 2015, <https://www.rfc-editor.org/info/rfc7582>.
[RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for
P-Multicast Service Interface Tunnel Attribute Flags",
RFC 7902, DOI 10.17487/RFC7902, June 2016,
<https://www.rfc-editor.org/info/rfc7902>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[I-D.ietf-bess-evpn-bum-procedure-updates]
Zhang, Z. J., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates on EVPN BUM Procedures", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-bum-
procedure-updates-14, 18 November 2021,
<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-bum-
procedure-updates-14.txt>.
[I-D.ietf-bier-evpn]
Zhang, Z. J., Przygienda, T., Sajassi, A., and J. Rabadan,
"EVPN BUM Using BIER", Work in Progress, Internet-Draft,
draft-ietf-bier-evpn-07, 10 August 2022,
<https://www.ietf.org/archive/id/draft-ietf-bier-evpn-
07.txt>.
Zhang, et al. Expires 15 June 2023 [Page 15]
Internet-Draft mvpn-evpn-aggregation-label December 2022
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>.
Authors' Addresses
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Eric Rosen
Individual
Email: erosen52@gmail.com
Wen Lin
Juniper Networks
Email: wlin@juniper.net
Zhenbin Li
Huawei Technologies
Email: lizhenbin@huawei.com
IJsbrand Wijnands
Individual
Email: ice@braindump.be
Zhang, et al. Expires 15 June 2023 [Page 16]
