rfc9572xml2.original.xml   rfc9572.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!DOCTYPE rfc [
.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC7117 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!ENTITY zwsp "&#8203;">
.7117.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC7432 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.7432.xml">
<!ENTITY RFC7524 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7524.xml">
<!ENTITY RFC6513 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6513.xml">
<!ENTITY RFC6514 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6514.xml">
<!ENTITY RFC7988 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7988.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8279.xml">
<!ENTITY RFC8584 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8584.xml">
<!ENTITY RFC8534 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8534.xml">
<!ENTITY RFC4875 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4875.xml">
<!ENTITY RFC4684 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4684.xml">
<!ENTITY RFC6388 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6388.xml">
]> ]>
<?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 category="std" updates="7432" docName="draft-ietf-bess-evpn-bum-procedure-u
pdates-14" ipr="trust200902">
<front>
<title abbrev="evpn-bum-procedure-update">Updates on EVPN BUM Procedures</ti
tle>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" updates="7432" docName="draft-ie
tf-bess-evpn-bum-procedure-updates-14" number="9572" ipr="trust200902" obsoletes
="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclu
de="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.12.0 -->
<front>
<title abbrev="EVPN BUM Procedures: Updates">Updates to EVPN Broadcast, Unkn
own Unicast, or Multicast (BUM) Procedures</title>
<seriesInfo name="RFC" value="9572"/>
<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>zzhang@juniper.net</email> <email>zzhang@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Wen Lin" initials="W." surname="Lin"> <author fullname="Wen Lin" initials="W." surname="Lin">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>wlin@juniper.net</email> <email>wlin@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Jorge Rabadan" initials="J." surname="Rabadan"> <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>jorge.rabadan@nokia.com</email> <email>jorge.rabadan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Keyur Patel" initials="K." surname="Patel"> <author fullname="Keyur Patel" initials="K." surname="Patel">
<organization>Arrcus</organization> <organization>Arrcus</organization>
<address> <address>
<email>keyur@arrcus.com</email> <email>keyur@arrcus.com</email>
</address> </address>
</author> </author>
<author fullname="Ali Sajassi" initials="A." surname="Sajassi"> <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>sajassi@cisco.com</email> <email>sajassi@cisco.com</email>
</address> </address>
</author> </author>
<date year="2024" month="April" />
<date year="2021"/> <area>rtg</area>
<workgroup>BESS</workgroup> <workgroup>BESS</workgroup>
<keyword>per-region I-PMSI</keyword>
<keyword>selective multicast forwarding</keyword>
<keyword>tunnel segmentation</keyword>
<keyword>inter-AS segmentation</keyword>
<keyword>inter-region segmentation</keyword>
<abstract> <abstract>
<t>This document specifies updated procedures for handling <t>This document specifies updated procedures for handling
broadcast, unknown unicast, and multicast (BUM) traffic in Broadcast, Unknown Unicast, or Multicast (BUM) traffic in
Ethernet VPNs (EVPN), including selective multicast, Ethernet VPNs (EVPNs), including selective multicast
and provider tunnel segmentation. This document updates RFC 7432. and segmentation of provider tunnels. This document updates RFC 7432.
</t> </t>
</abstract> </abstract>
<note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.
</t>
</note>
</front> </front>
<middle> <middle>
<section title="Terminology"> <section numbered="true" toc="default">
<t>It is expected that audience is familiar with MVPN [RFC6513] [RFC6514], V <name>Introduction</name>
PLS Multicast [RFC7117] and EVPN [RFC7432] concepts and <t><xref target="RFC7117" format="default"/> specifies procedures for mult
terminologies. For convenience, the following terms are briefly icast in the Virtual Private LAN
Service (VPLS multicast), using both inclusive tunnels and
selective tunnels with or without inter-AS segmentation, similar to the
Multicast VPN (MVPN) procedures specified in <xref target="RFC6513" forma
t="default"/> and <xref target="RFC6514" format="default"/>.
<xref target="RFC7524" format="default"/> specifies inter-area tunnel seg
mentation procedures for
both VPLS multicast and MVPNs.
</t>
<t><xref target="RFC7432" format="default"/> specifies BGP MPLS-based Ethe
rnet VPN (EVPN) procedures,
including those handling Broadcast, Unknown Unicast, or Multicast
(BUM) traffic. <xref target="RFC7432"/> refers to <xref target="RFC7117"
format="default"/> for details but leaves a few feature gaps related to selectiv
e tunnel and tunnel segmentation (<xref target="motivation"/>).
</t>
<t>This document aims to fill in those gaps by covering the use of selecti
ve
and segmented tunnels in EVPNs.
In the same way that <xref target="RFC7432"/> refers to <xref target="RFC
7117" format="default"/> for details, this document only specifies differences f
rom relevant procedures provided in <xref target="RFC7117" format="default"/> an
d <xref target="RFC7524" format="default"/>, rather than repeating the text from
those documents.
Note that these differences are applicable to EVPNs only
and are not updates to <xref target="RFC7117" format="default"/> or <xref
target="RFC7524" format="default"/>.
</t>
<t>MVPN, VPLS, and EVPN technologies all need to discover other Provider E
dges (PEs) in the
same L3/L2 VPN and announce the inclusive tunnels. MVPN technology introd
uced
the Inclusive P-Multicast Service Interface (I-PMSI) concept and uses I-P
MSI Auto-Discovery (A-D) routes for that purpose.
EVPN technology uses Inclusive Multicast Ethernet Tag (IMET) A-D routes,
but VPLS technology just adds a PMSI Tunnel Attribute (PTA) to an existin
g
VPLS A-D route for that purpose. For selective tunnels, they all
do use the same term: Selective PMSI (S-PMSI) A-D routes.
</t>
<t>This document often refers to the I-PMSI concept, which is
the same for all three technologies. For consistency and convenience,
an EVPN's IMET A-D route and a VPLS's VPLS A-D route carrying a PTA for B
UM traffic
purposes may each be referred to as an I-PMSI A-D route, depending on the
context.
</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>It is assumed that the reader is familiar with concepts and terminologi
es related to MVPN technology <xref target="RFC6513" format="default"/> <xref ta
rget="RFC6514" format="default"/>, VPLS multicast <xref target="RFC7117" format=
"default"/>, and EVPN technology <xref target="RFC7432" format="default"/>. For
convenience, the following terms are briefly
explained. explained.
<list style="symbols"> </t>
<t>PMSI [RFC6513]: P-Multicast Service Interface - a conceptual interface <dl spacing="normal">
for a PE <dt>AS:</dt><dd>Autonomous System</dd>
<dt>PMSI <xref target="RFC6513" format="default"/>:</dt><dd>P-Multicast
Service Interface. A conceptual interface for a PE
to send customer multicast traffic to all or some PEs in the same to send customer multicast traffic to all or some PEs in the same
VPN. VPN.</dd>
</t> <dt>I-PMSI:</dt><dd>Inclusive PMSI. Enables traffic to be sent to all PE
<t>I-PMSI: Inclusive PMSI - to all PEs in the same VPN. s in the same VPN.</dd>
</t> <dt>S-PMSI:</dt><dd>Selective PMSI. Enables traffic to be sent to some o
<t>S-PMSI: Selective PMSI - to some of the PEs in the same VPN. f the PEs in the same VPN.</dd>
</t> <dt>I/S-PMSI A-D Route:</dt><dd>Auto-Discovery route used to announce th
<t>I/S-PMSI A-D Route: Auto-Discovery routes used to announce the tunn e tunnels that instantiate an I/S-PMSI.</dd>
els that instantiate an I/S-PMSI. <dt>Leaf Auto-Discovery (A-D) Route <xref target="RFC6513" format="defau
</t> lt"/>:</dt><dd>For explicit leaf-tracking purposes.
<t>Leaf Auto-Discovery (A-D) routes [RFC6513]: For explicit leaf tracking Triggered by I/S-PMSI A-D routes and targeted at the triggering
purpose. route's (re-)advertiser. Its Network Layer
Triggered by I/S-PMSI A-D routes and targeted at triggering Reachability Information (NLRI) embeds the entire NLRI of the triggering PMSI
route's (re-)advertiser. Its NLRI embeds the entire NLRI of the trigge A-D route.</dd>
ring PMSI A-D route. <dt>IMET A-D Route <xref target="RFC7432" format="default"/>:</dt><dd>In
</t> clusive Multicast Ethernet Tag A-D route.
<t>IMET A-D route [RFC7432]: Inclusive Multicast Ethernet Tag A-D route. The EVPN equivalent of an MVPN Intra-AS I-PMSI A-D route
The EVPN equivalent of MVPN Intra-AS I-PMSI A-D route used to announce the tunnels that instantiate an I-PMSI.</dd>
used to announce the tunnels that instantiate an I-PMSI. <dt>SMET A-D Route <xref target="RFC9251" format="default"/>:</dt>
</t> <dd>Selective Multicast Ethernet Tag A-D route. The EVPN
<t>SMET A-D route <xref target="I-D.ietf-bess-evpn-igmp-mld-proxy"/>: equivalent of an MVPN Leaf A-D route, but unsolicited and untargeted.<
Selective Multicast Ethernet Tag A-D route. The EVPN /dd>
equivalent of MVPN Leaf A-D route but unsolicited and untargeted. <dt>PMSI Tunnel Attribute (PTA):</dt><dd>An optional transitive BGP attr
</t> ibute
<t>PMSI Tunnel Attribute (PTA): An optional transitive BGP attribute
that may be attached to PMSI/Leaf A-D routes to provide that may be attached to PMSI/Leaf A-D routes to provide
information for a PMSI tunnel. information for a PMSI tunnel.</dd>
</t> <dt>IBGP:</dt><dd>Internal BGP (BGP connection between internal peers).<
</list> /dd>
</t> <dt>EBGP:</dt><dd>External BGP (BGP connection between external peers).<
/dd>
<dt>RT:</dt><dd>Route Target. Controls route importation and propagation
.</dd>
</dl>
</section> </section>
<section title="Introduction"> </section>
<t>[RFC7117] specifies procedures for Multicast in Virtual Private LAN <section anchor="segmentation" numbered="true" toc="default">
Service (VPLS Multicast) using both inclusive tunnels and <name>Tunnel Segmentation</name>
selective tunnels with or without inter-as segmentation, similar to the <t>MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are
Multicast VPN (MVPN) procedures specified in [RFC6513] and [RFC6514].
[RFC7524] specifies inter-area tunnel segmentation procedures for
both VPLS Multicast and MVPN.
</t>
<t>[RFC7432] specifies BGP MPLS-Based Ethernet VPN (EVPN) procedures,
including those handling broadcast, unknown unicast, and multicast
(BUM) traffic. A lot of details are referred to [RFC7117], yet
with quite some feature gaps like selective tunnel and tunnel
segmentation (<xref target="segmentation"/>).
</t>
<t>This document aims at filling the gaps - cover the use of selective
and segmented tunnels in EVPN. It follows the same editorial choice
as in RFC7432 and only specifies differences from relevant procedures
in [RFC7117] and [RFC7524], instead of repeating the text.
Note that these differences are applicable to EVPN only,
and are not updates to [RFC7117] or [RFC7524].
</t>
<t>MVPN, VPLS and EVPN all have the need to discover other PEs in the
same L3/L2 VPN and announce the inclusive tunnels. MVPN introduced
the I-PMSI concept and uses I-PMSI A-D route for that.
EVPN uses Inclusive Multicast Ethernet Tag Route (IMET) A-D route
but VPLS just adds an PMSI Tunnel Attribute (PTA) to the existing
VPLS A-D route for that purpose. For selective tunnels, they all
do use the same term S-PMSI A-D routes.
</t>
<t>Many places of this document involve the I-PMSI concept that is all
the same for all three technologies. For consistency and convenience,
EVPN's IMET and VPLS's VPLS A-D route carrying PTA for BUM traffic
purpose may all be referred to as I-PMSI A-D routes depending on the
context.
</t>
<!--t>MVPN uses terms I-PMSI and S-PMSI A-D Routes. For
consistency and convenience, this document will use the same I/S-PMSI
terms for VPLS and EVPN. In particular, EVPN's Inclusive Multicast
Ethernet Tag Route and VPLS's VPLS A-D route carrying PTA
(PMSI Tunnel Attribute) for BUM traffic purpose will all be referred
to as I-PMSI A-D routes. Depending on the context, they may be used
interchangeably.
</t-->
<section title="Tunnel Segmentation" anchor="segmentation">
<t>MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are
referred to as MVPN/EVPN/VPLS provider tunnels in this document for referred to as MVPN/EVPN/VPLS provider tunnels in this document for
simplicity, can be segmented for technical or administrative reasons, simplicity, can be segmented for technical or administrative reasons,
which are summarized in <xref target="motivation"/> of this document. which are summarized in <xref target="motivation" format="default"/> of t
[RFC6513] and [RFC6514] cover MVPN inter-as segmentation, his document.
[RFC7117] covers <xref target="RFC6513" format="default"/> and <xref target="RFC6514" form
VPLS multicast inter-as segmentation, and [RFC7524] (Seamless MPLS at="default"/> cover MVPN inter-AS segmentation,
Multicast) covers inter-area segmentation for both MVPN and VPLS. <xref target="RFC7117" format="default"/> covers
</t> VPLS multicast inter-AS segmentation, and <xref target="RFC7524" format="
<t>With tunnel segmentation, different segments of an end-to-end tunnel default"/> (seamless MPLS
may have different encapsulation overhead. However, the largest overhead multicast) covers inter-area segmentation for both MVPNs and VPLSs.
</t>
<t>With tunnel segmentation, different segments of an end-to-end tunnel
may have different encapsulation overheads. However, the largest overhead
of the tunnel caused by an encapsulation method on a particular segment of the tunnel caused by an encapsulation method on a particular segment
is not different from the case of a non-segmented tunnel with that is not different from the case of a non-segmented tunnel with that
encapsulation method. This is similar to the case of a network encapsulation method. This is similar to the case of a network
with different link types. with different link types.
</t> </t>
<t>There is a difference between MVPN and VPLS multicast inter-as <t>There is a difference between MVPN and VPLS multicast inter-AS
segmentation (the VPLS approach is briefly discribed in <xref target="int segmentation (the VPLS approach is briefly described in <xref target="int
eraschanges"/>). For simplicity, EVPN will use the same procedures as eraschanges" format="default"/>). For simplicity, EVPNs will use the same proced
in MVPN. All ASBRs can re-advertise ures as those for
MVPNs. All ASBRs can re-advertise
their choice of the best route. Each can become the root of its their choice of the best route. Each can become the root of its
intra-AS segment and inject traffic it receives from its upstream, intra-AS segment and inject traffic it receives from its upstream,
while each downstream PE/ASBR will only pick one of the upstream ASBRs while each downstream PE/ASBR will only pick one of the upstream ASBRs
as its upstream. This is also the behavior even for VPLS in case of as its upstream. This is also the behavior even for VPLS in the case of
inter-area segmentation. inter-area segmentation.
</t> </t>
<t>For inter-area segmentation, [RFC7524] requires the use of Inter-area <t>For inter-area segmentation, <xref target="RFC7524" format="default"/
P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting > requires the use of the Inter-Area
of "Leaf Information Required" L flag in PTA in certain situations. Point-to-Multipoint (P2MP) Segmented Next-Hop Extended Community (S-NH-EC
In the EVPN case, the requirements around S-NH-EC and the PTA "L" flag ) and the setting
differ from [RFC7524] to make the segmentation procedures transparent to of the Leaf Information Required (L) flag in the PTA in certain situation
s.
In the EVPN case, the requirements around the S-NH-EC and the L flag in t
he PTA
differ from <xref target="RFC7524" format="default"/> to make the segment
ation procedures transparent to
ingress and egress PEs. ingress and egress PEs.
</t> </t>
<t>[RFC7524] assumes that segmentation happens at area borders. <t><xref target="RFC7524" format="default"/> assumes that segmentation h
appens at area borders.
However, it could be at "regional" borders, where a region could be a However, it could be at "regional" borders, where a region could be a
sub-area, or even an entire AS plus its external links sub-area, or even an entire AS plus its external links
(<xref target = "region"/>). That would (<xref target="region" format="default"/>); this would
allow for more flexible deployment scenarios (e.g. for single-area allow for more flexible deployment scenarios (e.g., for single-area
provider networks). This document extends the inter-area segmentation provider networks). This document extends the inter-area segmentation con
to inter-region segmentation for EVPN. cept
</t> to inter-region segmentation for EVPNs.
<section title="Reasons for Tunnel Segmentation" anchor="motivation"> </t>
<t>Tunnel segmentation may be required and/or desired because of <section anchor="motivation" numbered="true" toc="default">
<name>Reasons for Tunnel Segmentation</name>
<t>Tunnel segmentation may be required and/or desired for
administrative and/or technical reasons. administrative and/or technical reasons.
</t> </t>
<t>For example, an MVPN/VPLS/EVPN network may span multiple providers <t>For example, an MVPN/VPLS/EVPN may span multiple providers,
and the end-to-end provider and the end-to-end provider
tunnels have to be segmented at and stitched by the ASBRs. tunnels have to be segmented at and stitched by the ASBRs.
Different providers may use different tunnel technologies (e.g., Different providers may use different tunnel technologies (e.g.,
provider A uses Ingress Replication [RFC7988], provider B uses RSVP-TE provider A uses ingress replication <xref target="RFC7988" format="defaul
P2MP [RFC4875] while provider C uses mLDP [RFC6388]). Even if they use t"/>, provider B uses RSVP-TE
the same tunnel technology like RSVP-TE P2MP <xref target="RFC4875" format="default"/>, and provider C uses Multi
P2MP, it may be impractical to set up the tunnels across provider point LDP (mLDP) <xref target="RFC6388" format="default"/>). Even if they use
the same tunnel technology (e.g., RSVP-TE
P2MP), it may be impractical to set up the tunnels across provider
boundaries. boundaries.
</t> </t>
<t>The same situations may apply between the ASes and/or areas of a <t>The same situations may apply between the ASes and/or areas of a
single provider. For example, the backbone area may use RSVP-TE single provider. For example, the backbone area may use RSVP-TE
P2MP tunnels while non-backbone areas may use mLDP tunnels. P2MP tunnels while non-backbone areas may use mLDP tunnels.
</t> </t>
<t>Segmentation can also be used to divide an AS/area into smaller regions, <t>Segmentation can also be used to divide an AS/area into smaller reg
ions,
so that control plane state and/or forwarding plane state/burden can be so that control plane state and/or forwarding plane state/burden can be
limited to that of individual regions. For example, instead of Ingress limited to that of individual regions. For example, instead of
Replicating to 100 PEs in the entire AS, with inter-area segmentation ingress-replicating to 100 PEs in the entire AS, with inter-area segmenta
[RFC7524] a PE only needs to replicate to local PEs and ABRs. tion
<xref target="RFC7524" format="default"/>, a PE only needs to replicate t
o local PEs and Area Border Routers (ABRs).
The ABRs will further replicate to their downstream PEs and ABRs. The ABRs will further replicate to their downstream PEs and ABRs.
This not only reduces the forwarding plane burden, but also reduces This not only reduces the forwarding plane burden, but also reduces
the leaf tracking burden in the control plane. the leaf-tracking burden in the control plane.
</t> </t>
<t>Smaller regions also have the benefit that, in case of tunnel <t>In the case of tunnel aggregation, smaller regions provide the bene
aggregation, it is easier to find congruence among the segments of fit of
making it easier to find congruence among the segments of
different constituent (service) tunnels and the resulting aggregation different constituent (service) tunnels and the resulting aggregation
(base) tunnel in a region. This leads to better bandwidth efficiency, (base) tunnel in a region. This leads to better bandwidth efficiency,
because the more congruent they are, the fewer leaves of the base because the more congruent they are, the fewer leaves of the base
tunnel need to discard traffic when a service tunnel's segment tunnel need to discard traffic when a service tunnel's segment
does not need to receive the traffic (yet it is receiving the traffic does not need to receive the traffic (yet it is receiving the traffic
due to aggregation). due to aggregation).
</t> </t>
<t>Another advantage of the smaller region is smaller BIER [RFC8279] <t>Another advantage of the smaller region is smaller Bit Index
sub-domains. With BIER, packets carry a BitString, Explicit Replication (BIER) subdomains <xref target="RFC8279" format="def
in which the bits correspond to edge routers that needs to receive ault"/>.
traffic. Smaller sub-domains means smaller BitStrings can be used With BIER, packets carry a BitString,
in which the bits correspond to edge routers that need to receive
traffic. Smaller subdomains means that smaller BitStrings can be used
without having to send multiple copies of the same packet. without having to send multiple copies of the same packet.
</t> </t>
<!--
<t>Finally, EVPN tunnel segmentation can be used for EVPN DCIs,
as discussed in <xref target="dci"/>. It follows the same concepts
discussed above.
</t>
</section>
</section>
</section> </section>
<section title="Additional Route Types of EVPN NLRI" anchor="routes"> </section>
<t>[RFC7432] defines the format of EVPN NLRI as the following: <section anchor="routes" numbered="true" toc="default">
<figure> <name>Additional Route Types of EVPN NLRI</name>
<artwork> <t><xref target="RFC7432" format="default"/> defines the format of EVPN NL
RI as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------------------------+ +-----------------------------------+
| Route Type (1 octet) | | Route Type (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Length (1 octet) | | Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Route Type specific (variable) | | Route Type specific (variable) |
+-----------------------------------+ +-----------------------------------+
</artwork> ]]></artwork>
</figure> <t>
So far eight route types have been defined in [RFC7432], So far, eight route types have been defined in <xref target="RFC7432" fo
<xref target="I-D.ietf-bess-evpn-prefix-advertisement"/>, and rmat="default"/>,
<xref target="I-D.ietf-bess-evpn-igmp-mld-proxy"/>: <xref target="RFC9136" format="default"/>, and
<figure> <xref target="RFC9251" format="default"/>:
<artwork> </t>
+ 1 - Ethernet Auto-Discovery (A-D) route <table anchor="tab-0">
+ 2 - MAC/IP Advertisement route <name>Pre-existing Route Types</name>
+ 3 - Inclusive Multicast Ethernet Tag route <thead>
+ 4 - Ethernet Segment route <tr>
+ 5 - IP Prefix Route <th>Value</th>
+ 6 - Selective Multicast Ethernet Tag Route <th>Description</th>
+ 7 - Multicast Join Synch Route </tr>
+ 8 - Multicast Leave Synch Route </thead>
</artwork> <tbody>
</figure> <tr>
<td>1</td>
<td>Ethernet Auto-discovery</td>
</tr>
<tr>
<td>2</td>
<td>MAC/IP Advertisement</td>
</tr>
<tr>
<td>3</td>
<td>Inclusive Multicast Ethernet Tag</td>
</tr>
<tr>
<td>4</td>
<td>Ethernet Segment</td>
</tr>
<tr>
<td>5</td>
<td>IP Prefix</td>
</tr>
<tr>
<td>6</td>
<td>Selective Multicast Ethernet Tag Route</td>
</tr>
<tr>
<td>7</td>
<td>Multicast Membership Report Synch Route</td>
</tr>
<tr>
<td>8</td>
<td>Multicast Leave Synch Route</td>
</tr>
</tbody>
</table>
<t>
This document defines three additional route types: This document defines three additional route types:
<figure> </t>
<artwork> <table anchor="tab-0a">
+ 9 - Per-Region I-PMSI A-D route <name>New Route Types</name>
+ 10 - S-PMSI A-D route <thead>
+ 11 - Leaf A-D route <tr>
</artwork> <th>Value</th>
</figure> <th>Description</th>
The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs </tr>
starts with a type 1 RD, whose Administrator sub-field MUST match </thead>
that of the RD in all current non-Leaf A-D (<xref target="leaf"/>) <tbody>
EVPN routes from the same advertising router for a given EVI. <tr>
</t> <td>9</td>
<section title="Per-Region I-PMSI A-D route" anchor="per-region"> <td>Per-Region I-PMSI A-D route</td>
<t>The Per-region I-PMSI A-D route has the following format. Its usage is </tr>
discussed in <xref target="aggregation"/>. <tr>
<figure> <td>10</td>
<artwork> <td>S-PMSI A-D route</td>
</tr>
<tr>
<td>11</td>
<td>Leaf A-D route</td>
</tr>
</tbody>
</table>
<!--
<artwork name="" type="" align="left" alt=""><![CDATA[
9 - Per-Region I-PMSI A-D route
10 - S-PMSI A-D route
11 - Leaf A-D route
]]></artwork>
-->
<t>
The "Route Type specific" field of the Type 9 and Type 10 EVPN NLRIs
starts with a Type 1 RD (Route Distinguisher), whose Administrator sub-f
ield <bcp14>MUST</bcp14> match
that of the RD in all current EVPN routes that are not Leaf A-D routes
(<xref target="leaf" format="default"/>), i.e., non-Leaf A-D routes
from the same advertising router for a given EVPN instance (EVI).
</t>
<section anchor="per-region" numbered="true" toc="default">
<name>Per-Region I-PMSI A-D Route</name>
<t>The per-region I-PMSI A-D route has the following format. Its usage i
s
discussed in <xref target="aggregation" format="default"/>.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------------------------+ +-----------------------------------+
| RD (8 octets) | | RD (8 octets) |
+-----------------------------------+ +-----------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+-----------------------------------+ +-----------------------------------+
| Region ID (8 octets) | | Region ID (8 octets) |
+-----------------------------------+ +-----------------------------------+
</artwork> ]]></artwork>
</figure> <t>
The Region ID identifies the region and is encoded just as how an The Region ID identifies the region and is encoded in the same way that
Extended Community is encoded, as detailed in an
<xref target="aggregation"/>. EC is encoded, as detailed in
</t> <xref target="aggregation" format="default"/>.
</section> </t>
<section title="S-PMSI A-D route"> </section>
<t>The S-PMSI A-D route has the following format: <section numbered="true" toc="default">
<figure> <name>S-PMSI A-D Route</name>
<artwork> <t>The S-PMSI A-D route has the following format:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------------------------+ +-----------------------------------+
| RD (8 octets) | | RD (8 octets) |
+-----------------------------------+ +-----------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+-----------------------------------+ +-----------------------------------+
| Multicast Source Length (1 octet) | | Multicast Source Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Multicast Source (Variable) | | Multicast Source (variable) |
+-----------------------------------+ +-----------------------------------+
| Multicast Group Length (1 octet) | | Multicast Group Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Multicast Group (Variable) | | Multicast Group (variable) |
+-----------------------------------+ +-----------------------------------+
|Originator's Addr Length (1 octet) | |Originator's Addr Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
|Originator's Addr (4 or 16 octets) | |Originator's Addr (4 or 16 octets) |
+-----------------------------------+ +-----------------------------------+
</artwork> ]]></artwork>
</figure> <t>
Other than the addition of Ethernet Tag ID and Originator's Addr Other than the addition of the Ethernet Tag ID and Originator's Addr
Length, it is identical Length fields, it is identical
to the S-PMSI A-D route as defined in [RFC7117]. The procedures to the S-PMSI A-D route as defined in <xref target="RFC7117" format="def
in [RFC7117] also apply (including wildcard functionality), ault"/>. The procedures specified
in <xref target="RFC7117" format="default"/> also apply (including wildc
ard functionality),
except that the granularity level is per Ethernet Tag. except that the granularity level is per Ethernet Tag.
</t> </t>
</section> </section>
<section title="Leaf A-D route" anchor="leaf"> <section anchor="leaf" numbered="true" toc="default">
<t>The Route Type specific field of a Leaf A-D route consists of <name>Leaf A-D Route</name>
<t>The Route Type specific field of a Leaf A-D route consists of
the following: the following:
<figure> </t>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------------------------+ +-----------------------------------+
| Route Key (variable) | | Route Key (variable) |
+-----------------------------------+ +-----------------------------------+
|Originator's Addr Length (1 octet) | |Originator's Addr Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
|Originator's Addr (4 or 16 octets) | |Originator's Addr (4 or 16 octets) |
+-----------------------------------+ +-----------------------------------+
</artwork> ]]></artwork>
</figure> <t>
A Leaf A-D route is originated in response to a PMSI route, A Leaf A-D route is originated in response to a PMSI route,
which could be an Inclusive Multicast Tag route, a per-region which could be an IMET A-D route, a per-region
I-PMSI A-D route, an S-PMSI A-D route, or some other types of I-PMSI A-D route, an S-PMSI A-D route, or some other types of
routes that may be defined in the future that triggers Leaf A-D routes that may be defined in the future that trigger Leaf A-D
routes. The Route Key is the NLRI of the routes. The Route Key is the NLRI of the
route for which this Leaf A-D route is generated. route for which this Leaf A-D route is generated.
</t> </t>
<t>The general procedures of Leaf A-D route are first specified in <t>The general procedures for Leaf A-D routes were first specified in
[RFC6514] for MVPN. The principles apply to VPLS and EVPN as well. <xref target="RFC6514" format="default"/> for MVPNs. The principles there
[RFC7117] has details for VPLS Multicast, and this document points in apply to VPLSs and EVPNs as well.
out some specifics for EVPN, e.g. in <xref target="inter-as"/>. <xref target="RFC7117" format="default"/> provides details regarding VPLS
</t> multicast, and this document points
</section> out some specifics for EVPNs, e.g., in <xref target="inter-as" format="de
fault"/>.
</t>
</section>
</section> </section>
<section title="Selective Multicast"> <section numbered="true" toc="default">
<t><xref target="I-D.ietf-bess-evpn-igmp-mld-proxy"/> specifies <name>Selective Multicast</name>
procedures for EVPN selective forwarding of IP multicast using SMET <t><xref target="RFC9251" format="default"/> specifies
routes. It assumes selective forwarding is always used with IR procedures for EVPN selective forwarding of IP multicast traffic using SM
ET
routes. It assumes that selective forwarding is always used with ingress
replication
for all flows (though the same signaling can also be used for an for all flows (though the same signaling can also be used for an
ingress PE to find out the set of egress PEs for selective ingress PE to learn the set of egress PEs for selective
forwarding with BIER). forwarding with BIER).
An NVE proxies the IGMP/MLD state that it learns on its A Network Virtualization Edge (NVE) proxies the IGMP/MLD state ("MLD"
ACs to (C-S,C-G) or (C-*,C-G) SMET routes that advertises to other NVEs, stands for "Multicast Listener Discovery") that it learns on its
Attachment Circuits (ACs) to (C-S,C-G) or (C-*,C-G) SMET routes that are
advertised to other NVEs,
and a receiving NVE converts the SMET routes back to IGMP/MLD messages and a receiving NVE converts the SMET routes back to IGMP/MLD messages
and sends them out of its ACs. The receiving NVE also uses the SMET and sends them out of its ACs. The receiving NVE also uses the SMET
routes to identify which NVEs need to receive traffic for a particular routes to identify which NVEs need to receive traffic for a particular
(C-S,C-G) or (C-*,C-G) to achieve selective forwarding using IR or (C-S,C-G) or (C-*,C-G) to achieve selective forwarding using ingress repl ication or
BIER. BIER.
</t> </t>
<t>With the above procedures, selective forwarding is done for all flows <t>With the above procedures, selective forwarding is done for all flows,
and the SMET routes are advertised for all flows. and the SMET routes are advertised for all flows.
It is possible that an operator may not want to track all those It is possible that an operator may not want to track all those
(C-S, C-G) or (C-*,C-G) state on the NVEs, and the multicast traffic (C-S, C-G) or (C-*,C-G) states on the NVEs, and the multicast traffic
pattern allows inclusive forwarding for most flows while selective pattern allows inclusive forwarding for most flows while selective
forwarding is needed only for a few high-rate flows. For that, forwarding is needed only for a few high-rate flows. For that reason,
or for tunnel types other than IR/BIER, S-PMSI/Leaf A-D procedures or for tunnel types other than ingress replication or BIER, S-PMSI/Leaf A
defined for Selective Multicast for VPLS in [RFC7117] are used. Other -D procedures
than that different route types and formats are specified with EVPN SAFI defined for selective multicast for VPLS in <xref target="RFC7117" format
for S-PMSI A-D and Leaf A-D routes (<xref target="routes"/>), all ="default"/> are used. Other
procedures in [RFC7117] with respect to Selective Multicast apply to than the fact that different route types and formats are specified with a
EVPN as well, including wildcard procedures. In a nutshell, a source n EVPN SAFI
for S-PMSI A-D and Leaf A-D routes (<xref target="routes" format="default
"/>), all
procedures specified in <xref target="RFC7117" format="default"/> with re
spect to selective multicast apply to
EVPNs as well, including wildcard procedures. In a nutshell, a source
NVE advertises S-PMSI A-D routes to announce the tunnels used for NVE advertises S-PMSI A-D routes to announce the tunnels used for
certain flows, and receiving NVEs either join the announced PIM/mLDP certain flows, and receiving NVEs either join the announced PIM/mLDP
tunnel or respond with Leaf A-D routes if the Leaf Information Required tunnel or respond with Leaf A-D routes if the L
flag is set in the S-PMSI A-D route's PTA (so that the source NVE can flag is set in the S-PMSI A-D route's PTA (so that the source NVE can
include them as tunnel leaves). include them as tunnel leaves).
</t> </t>
<t>An optimization to the [RFC7117] procedures may be applied. Even if <t>An optimization to the procedures provided in <xref target="RFC7117" fo
rmat="default"/> may be applied. Even if
a source NVE sets the L flag to request Leaf A-D routes, an egress a source NVE sets the L flag to request Leaf A-D routes, an egress
NVE MAY omit the Leaf A-D route if it has already advertised a NVE <bcp14>MAY</bcp14> omit the Leaf A-D route if it has already advertised a
corresponding SMET route, and the source NVE MUST use that in lieu of corresponding SMET route, and the source NVE <bcp14>MUST</bcp14> use that in
lieu of
the Leaf A-D route. the Leaf A-D route.
</t> </t>
<t>The optional optimizations specified for MVPN in <t>The optional optimizations specified for MVPNs in
<xref target="RFC8534"/> are also applicable <xref target="RFC8534" format="default"/> are also applicable
to EVPN when the S-PMSI/Leaf A-D routes procedures are used for EVPN to EVPNs when the procedures for S-PMSI/Leaf A-D routes are used for EVPN
selective multicast forwarding. selective multicast forwarding.
</t> </t>
</section> </section>
<section title="Inter-AS Segmentation" anchor="inter-as"> <section anchor="inter-as" numbered="true" toc="default">
<section title="Differences from Section 7.2.2 of [RFC7117] When Applied to <name>Inter-AS Segmentation</name>
EVPN" anchor="interaschanges"> <section anchor="interaschanges" numbered="true" toc="default">
<t>The first paragraph of Section 7.2.2.2 of [RFC7117] says: <name>Differences from Section 7.2.2 of RFC 7117 when Applied to EVPNs</
<figure> name>
<artwork> <t>The first paragraph of <xref target="RFC7117" sectionFormat="of" sect
"... The best route procedures ensure that if multiple ion="7.2.2.2"/> says:
</t>
<!-- DNE; verified -->
<blockquote>
... The best route procedures ensure that if multiple
ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP
neighbors, only one of these ASBRs propagates this route in Internal neighbors, only one of these ASBRs propagates this route in Internal
BGP (IBGP). This ASBR becomes the root of the intra-AS segment of BGP (IBGP). This ASBR becomes the root of the intra-AS segment of
the inter-AS tree and ensures that this is the only ASBR that accepts the inter-AS tree and ensures that this is the only ASBR that accepts
traffic into this AS from the inter-AS tree." traffic into this AS from the inter-AS tree.
</artwork> </blockquote>
</figure> <t>
The above VPLS behavior requires complicated VPLS specific procedures The above VPLS behavior requires complicated VPLS-specific procedures
for the ASBRs to reach agreement. For EVPN, a different approach for the ASBRs to reach agreement. For EVPNs, a different approach
is used and the above quoted text is not applicable to EVPN. is used; the above text from <xref target="RFC7117"/> is not applicable t
</t> o EVPNs.
<t>With the different approach for EVPN/MVPN, each ASBR will re-advertise </t>
<t>With the different approach for EVPNs/MVPNs, each ASBR will re-advert
ise
its received Inter-AS A-D route to its IBGP peers and becomes the root its received Inter-AS A-D route to its IBGP peers and becomes the root
of an intra-AS segment of the inter-AS tree. The intra-AS segment of an intra-AS segment of the inter-AS tree. The intra-AS segment
rooted at one ASBR is disjoint with another intra-AS segment rooted rooted at one ASBR is disjoint from another intra-AS segment rooted
at another ASBR. This is the same as the procedures for S-PMSI at another ASBR. This is the same as the procedures for S-PMSI routes
in [RFC7117] itself. in <xref target="RFC7117" format="default"/> itself.
</t> </t>
<t>The following bullet in Section 7.2.2.2 of [RFC7117] does not apply <t>The following bullet in <xref target="RFC7117" sectionFormat="of" sec
to EVPN. tion="7.2.2.2"/> does not apply
<figure> to EVPNs.
<artwork> </t>
+ If the ASBR uses ingress replication to instantiate the intra-AS <!-- DNE; verified -->
segment of the inter-AS tunnel, the re-advertised route MUST NOT <blockquote>
carry the PMSI Tunnel attribute. <ul><li>If the ASBR uses ingress replication to instantiate the intra-AS
</artwork> segment of the inter-AS tunnel, the re-advertised route <bcp14>MUST NOT</
</figure> bcp14>
</t> carry the PMSI Tunnel attribute.</li></ul>
<t>The following bullet in Section 7.2.2.2 of [RFC7117]: </blockquote>
<figure> <t>The following bullet in <xref target="RFC7117" sectionFormat="of" sec
<artwork> tion="7.2.2.2"/>:
+ If the ASBR uses a P-multicast tree to instantiate the intra-AS </t>
segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST <!-- DNE; verified -->
<blockquote><ul><li>
If the ASBR uses a P-multicast tree to instantiate the intra-AS
segment of the inter-AS tunnel, the PMSI Tunnel attribute <bcp14>MUST</bc
p14>
contain the identity of the tree that is used to instantiate the contain the identity of the tree that is used to instantiate the
segment (note that the ASBR could create the identity of the tree segment (note that the ASBR could create the identity of the tree
prior to the actual instantiation of the segment). If, in order prior to the actual instantiation of the segment). If, in order
to instantiate the segment, the ASBR needs to know the leaves of to instantiate the segment, the ASBR needs to know the leaves of
the tree, then the ASBR obtains this information from the A-D the tree, then the ASBR obtains this information from the A-D
routes received from other PEs/ASBRs in the ASBR's own AS. routes received from other PEs/ASBRs in the ASBR's own AS.</li></ul>
</artwork> </blockquote>
</figure> <t>is changed to the following when applied to EVPNs:
</t> </t>
<t>is changed to the following when applied to EVPN: <blockquote><ul><li>
<figure> The PTA <bcp14>MUST</bcp14> specify the tunnel for the segment.
<artwork>
"The PMSI Tunnel attribute MUST specify the tunnel for the segment.
If and only if, in order to establish the tunnel, the ASBR needs to If and only if, in order to establish the tunnel, the ASBR needs to
know the leaves of the tree, then the ASBR MUST set the L flag to know the leaves of the tree, then the ASBR <bcp14>MUST</bcp14> set the L f lag to
1 in the PTA to trigger Leaf A-D routes from egress PEs and 1 in the PTA to trigger Leaf A-D routes from egress PEs and
downstream ASBRs. It MUST be (auto-)configured with an import RT, downstream ASBRs. It <bcp14>MUST</bcp14> be (auto-)configured with an impo
which controls acceptance of leaf A-D routes by the ASBR." rt RT,
</artwork> which controls acceptance of Leaf A-D routes by the ASBR.</li></ul>
</figure> </blockquote>
</t> <t>Accordingly, the following paragraph in <xref target="RFC7117" sectio
<t>Accordingly, the following paragraph in Section 7.2.2.4 of [RFC7117]: nFormat="of" section="7.2.2.4"/>:
<figure> </t>
<artwork> <!-- DNE; verified -->
"If the received Inter-AS A-D route carries the PMSI Tunnel attribute <blockquote>
If the received Inter-AS A-D route carries the PMSI Tunnel attribute
with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR
that originated the route MUST establish an RSVP-TE P2MP LSP with the that originated the route <bcp14>MUST</bcp14> establish an RSVP-TE P2MP LSP w
local PE/ASBR as a leaf. This LSP MAY have been established before ith the
the local PE/ASBR receives the route, or it MAY be established after local PE/ASBR as a leaf. This LSP <bcp14>MAY</bcp14> have been established b
the local PE receives the route." efore
</artwork> the local PE/ASBR receives the route, or it <bcp14>MAY</bcp14> be established
</figure> after
is changed to the following when applied to EVPN: the local PE receives the route.
</t> </blockquote>
<t> <t>
"If the received Inter-AS A-D route has the L flag set in its PTA, is changed to the following when applied to EVPNs:
then a receiving PE MUST originate a corresponding Leaf A-D route, while </t>
a receiving ASBR MUST originate a corresponding Leaf A-D route <blockquote>
if and only if it received and imported one or more corresponding Leaf If the received Inter-AS A-D route has the L flag set in its PTA,
A-D routes from its downstream IBGP or EBGP peers, or it has non-null then a receiving PE <bcp14>MUST</bcp14> originate a corresponding Leaf A-D rout
downstream forwarding state for the PIM/mLDP tunnel that instantiates e.
its downstream intra-AS segment. The targeted ASBR for the Leaf A-D route, A receiving ASBR <bcp14>MUST</bcp14> originate a corresponding Leaf A-D
which (re-)advertised the Inter-AS A-D route, MUST establish a tunnel route if and only if one of the following conditions is met:
to the leaves discovered by the Leaf A-D routes." (1) it received and imported one or more corresponding Leaf A-D
</t> routes from its downstream IBGP or EBGP peers or (2) it has
</section> non-null downstream forwarding state for the PIM/mLDP tunnel that
<section title="I-PMSI Leaf Tracking" instantiates its downstream intra-AS segment. The targeted ASBR for the Leaf A-
anchor="leaf-tracking"> D
<t>An ingress PE does not set the L flag in its Inclusive Multicast route, which (re-)advertised the Inter-AS A-D route, <bcp14>MUST</bcp14> establ
Ethernet Tag (IMET) A-D route's PTA, ish a tunnel to the
even with Ingress Replication or RSVP-TE P2MP tunnels. leaves discovered by the Leaf A-D routes.
</blockquote>
</section>
<section anchor="leaf-tracking" numbered="true" toc="default">
<name>I-PMSI Leaf Tracking</name>
<t>An ingress PE does not set the L flag in its IMET A-D route's PTA,
even with Ingress Replication tunnels or RSVP-TE P2MP tunnels.
It does not rely on the Leaf A-D routes to discover leaves in It does not rely on the Leaf A-D routes to discover leaves in
its AS, and Section 11.2 of [RFC7432] explicitly states that the L its AS, and <xref target="RFC7432" sectionFormat="of" section="11.2"/> ex
flag must be set to zero. plicitly states that the L
</t> flag must be set to 0.
<t>An implementation of [RFC7432] might have used the Originating </t>
<t>An implementation of <xref target="RFC7432" format="default"/> might
have used the Originating
Router's IP Address field of the IMET A-D Router's IP Address field of the IMET A-D
routes to determine the leaves, or might have used the Next Hop field routes to determine the leaves or might have used the Next Hop field
instead. Within the same AS, both will lead to the same result. instead. Within the same AS, both will lead to the same result.
</t> </t>
<t>With segmentation, an ingress PE MUST determine the leaves <t>With segmentation, an ingress PE <bcp14>MUST</bcp14> determine the le
aves
in its AS from the BGP next hops in all its received IMET A-D in its AS from the BGP next hops in all its received IMET A-D
routes, so it does not have to set the L flag set to request Leaf A-D routes, so it does not have to set the L flag to request Leaf A-D
routes. PEs within the same AS will all have different next hops routes. PEs within the same AS will all have different next hops
in their IMET A-D routes (hence will all be considered as leaves), in their IMET A-D routes (and hence will all be considered as leaves),
and PEs from other ASes will have the next hop in their IMET A-D and PEs from other ASes will have the next hop in their IMET A-D
routes set to addresses of ASBRs in this local AS, hence only those routes set to addresses of ASBRs in this local AS; hence, only those
ASBRs will be considered as leaves (as proxies for those PEs in other ASBRs will be considered as leaves (as proxies for those PEs in other
ASes). Note that in case of Ingress Replication, when an ASBR ASes). Note that in the case of ingress replication, when an ASBR
re-advertises IMET A-D routes to IBGP peers, it MUST advertise the re-advertises IMET A-D routes to IBGP peers, it <bcp14>MUST</bcp14> adver
same label for all those for the same Ethernet Tag ID and the same tise the
same label for all those routes for the same Ethernet Tag ID and the same
EVI. Otherwise, duplicated copies will be sent by the ingress PE EVI. Otherwise, duplicated copies will be sent by the ingress PE
and received by egress PEs in other regions. For the same reason, and received by egress PEs in other regions. For the same reason,
when an ingress PE builds its flooding list, if multiple routes when an ingress PE builds its flooding list, if multiple routes
have the same (nexthop, label) tuple they MUST only be have the same (nexthop, label) tuple, they <bcp14>MUST</bcp14> only be
added as a single branch in the flooding list. added as a single branch in the flooding list.
</t> </t>
</section> </section>
<section title="Backward Compatibility" anchor="compatibility"> <section anchor="compatibility" numbered="true" toc="default">
<t>The above procedures assume that all PEs are upgraded to support <name>Backward Compatibility</name>
<t>The above procedures assume that all PEs are upgraded to support
the segmentation procedures: the segmentation procedures:
<list style="symbols"> </t>
<t>An ingress PE uses the Next Hop and not Originating <ul spacing="normal">
<li>An ingress PE uses the Next Hop and not the Originating
Router's IP Address to determine leaves for the I-PMSI tunnel. Router's IP Address to determine leaves for the I-PMSI tunnel.
</t> </li>
<t>An egress PE sends Leaf A-D routes in response to I-PMSI routes, <li>An egress PE sends Leaf A-D routes in response to I-PMSI routes,
if the PTA has the L flag set by the re-advertising ASBR. if the PTA has the L flag set by the re-advertising ASBR.
</t> </li>
<t>In case of Ingress Replication, when an ingress PE builds <li>In the case of ingress replication, when an ingress PE builds
its flooding list, multiple I-PMSI routes may have the same (nexthop, label) its flooding list, multiple I-PMSI routes may have the same (nexthop, label)
tuple and only a single branch for those will be added in the flooding tuple, and only a single branch for those routes will be added in the floodin g
list. list.
</t> </li>
</list> </ul>
</t> <t>If a deployment has legacy PEs that do not support the above,
<t>If a deployment has legacy PEs that does not support the above,
then a legacy ingress PE would include all PEs (including those then a legacy ingress PE would include all PEs (including those
in remote ASes) as leaves of the inclusive tunnel and try to send in remote ASes) as leaves of the inclusive tunnel and try to send
traffic to them directly (no segmentation), which is either undesired traffic to them directly (no segmentation), which is either undesirable
or not possible; a legacy egress PE would not send Leaf A-D routes or impossible; a legacy egress PE would not send Leaf A-D routes
so the ASBRs would not know to send external traffic to them. so the ASBRs would not know to send external traffic to them.
</t> </t>
<t>If this backward compatibility problem needs to be addressed, the <t>If this backward-compatibility problem needs to be addressed, the
following procedure MUST be used (see <xref target="aggregation"/> following procedure <bcp14>MUST</bcp14> be used (see <xref target="aggreg
ation" format="default"/>
for per-PE/AS/region I-PMSI A-D routes): for per-PE/AS/region I-PMSI A-D routes):
<list style="symbols"> </t>
<t>An upgraded PE indicates in its per-PE I-PMSI A-D <ul spacing="normal">
<li>An upgraded PE indicates in its per-PE I-PMSI A-D
route that it supports the new procedures. This is done route that it supports the new procedures. This is done
by setting a flag bit in the EVPN Multicast Flags Extended by setting a flag bit in the EVPN Multicast Flags Extended
Community. Community.
</t> </li>
<t>All per-PE I-PMSI A-D routes are restricted to the local AS <li>All per-PE I-PMSI A-D routes are restricted to the local AS
and not propagated to external peers. and not propagated to external peers.
</t> </li>
<t>The ASBRs in an AS originate per-region I-PMSI A-D routes <li>The ASBRs in an AS originate per-region I-PMSI A-D routes
and advertise them to their external peers to specify tunnels and advertise them to their external peers to specify tunnels
used to carry traffic from the local AS to other ASes. used to carry traffic from the local AS to other ASes.
Depending on the types of tunnels being used, the L flag Depending on the types of tunnels being used, the L flag
in the PTA may be set, in which case the downstream ASBRs in the PTA may be set, in which case the downstream ASBRs
and upgraded PEs will send Leaf A-D routes to pull traffic and upgraded PEs will send Leaf A-D routes to pull traffic
from their upstream ASBRs. In a particular downstream AS, from their upstream ASBRs. In a particular downstream AS,
one of the ASBRs is elected, based on the per-region one of the ASBRs is elected, based on the per-region
I-PMSI A-D routes for a particular source AS, I-PMSI A-D routes for a particular source AS,
to send traffic from that source AS to legacy PEs in the to send traffic from that source AS to legacy PEs in the
downstream AS. The traffic arrives at the elected ASBR downstream AS.
on the tunnel announced in the best per-region I-PMSI A-D The traffic arrives at the elected ASBR on the tunnel
route for the source AS, that the ASBR has selected of announced in the best per-region I-PMSI A-D route for the source
all those that it received over EBGP or IBGP sessions. AS, as selected by the ASBR from all the routes that it received
The election procedure is described in over EBGP or IBGP sessions. The election procedure is described in
<xref target="election"/>. <xref target="election" format="default"/>.
</t> </li>
<t>In an ingress/upstream AS, if and only if an ASBR has active downst <li>In an ingress/upstream AS, if and only if an ASBR has active downs
ream tream
receivers (PEs and ASBRs), which are learned either explicitly receivers (PEs and ASBRs), which are learned either explicitly
via Leaf A-D routes or implicitly via PIM join or mLDP label via Leaf A-D routes or implicitly via PIM Join or mLDP label
mapping, the ASBR originates a per-PE I-PMSI A-D route (i.e., mapping, the ASBR originates a per-PE I-PMSI A-D route (i.e., a
regular Inclusive Multicast Ethernet Tag route) into the local regular IMET route) into the local
AS, and stitches incoming per-PE I-PMSI tunnels into its AS and stitches incoming per-PE I-PMSI tunnels into its
per-region I-PMSI tunnel. With this, it gets traffic from per-region I-PMSI tunnel. Via this process, it gets traffic from
local PEs and send to other ASes via the tunnel announced in local PEs and sends the traffic to other ASes via the tunnel announ
ced in
its per-region I-PMSI A-D route. its per-region I-PMSI A-D route.
</t> </li>
</list> </ul>
</t> <t>Note that even if there are no backward-compatibility issues, the use
<t>Note that, even if there is no backward compatibility issue, the use of of
per-region I-PMSI has the benefit of keeping all per-PE I-PMSI A-D routes per-region I-PMSI A-D routes provides the benefit of keeping all per-PE I
-PMSI A-D routes
in their local ASes, greatly reducing the flooding of the routes and in their local ASes, greatly reducing the flooding of the routes and
their corresponding Leaf A-D routes (when needed), and the number of their corresponding Leaf A-D routes (when needed) and reducing the number
inter-as tunnels. of
</t> inter-AS tunnels.
<section title="Designated ASBR Election" anchor="election"> </t>
<t>When an ASBR re-advertises a per-region I-PMSI A-D route into an AS <section anchor="election" numbered="true" toc="default">
<name>Designated ASBR Election</name>
<t>When an ASBR re-advertises a per-region I-PMSI A-D route into an AS
in which a designated ASBR needs to be used to forward traffic in which a designated ASBR needs to be used to forward traffic
to the legacy PEs in the AS, it MUST include a DF Election EC. to the legacy PEs in the AS, it <bcp14>MUST</bcp14> include a Designated
The EC and its use is specified in <xref target="RFC8584"/>. Forwarder (DF) Election EC.
The AC-DF bit in the DF Election EC MUST be cleared. The EC and its use are specified in <xref target="RFC8584" format="defaul
If it is known that no legacy PEs exist in the AS, the ASBR MUST NOT t"/>.
include the EC and MUST remove the DF Election EC if one is carried in The AC-DF bit in the DF Election EC <bcp14>MUST</bcp14> be cleared.
If it is known that no legacy PEs exist in the AS, the ASBR <bcp14>MUST N
OT</bcp14>
include the EC and <bcp14>MUST</bcp14> remove the DF Election EC if one i
s carried in
the per-region I-PMSI A-D routes that it receives. Note that this is done the per-region I-PMSI A-D routes that it receives. Note that this is done
for each set of per-region I-PMSI A-D routes with the same NLRI. for each set of per-region I-PMSI A-D routes with the same NLRI.
</t> </t>
<t>Based on the procedures in <t>Based on the procedures specified in
<xref target="RFC8584"/>, an election <xref target="RFC8584" format="default"/>, an election
algorithm is determined according to the DF Election ECs carried in algorithm is determined according to the DF Election ECs carried in
the set of per-region I-PMSI routes of the same NLRI re-adverised into th e AS. the set of per-region I-PMSI routes of the same NLRI re-advertised into t he AS.
The algorithm is then applied to a candidate list, which is the set of The algorithm is then applied to a candidate list, which is the set of
ASBRs that re-advertised the per-region I-PMSI routes of the same NLRI ASBRs that re-advertised the per-region I-PMSI routes of the same NLRI
carrying the DF Election EC. carrying the DF Election EC.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section title="Inter-Region Segmentation" anchor="inter-region"> <section anchor="inter-region" numbered="true" toc="default">
<section title="Area/AS vs. Region" anchor="region"> <name>Inter-Region Segmentation</name>
<t>[RFC7524] is for MVPN/VPLS inter-area segmentation and does not explicitl <section anchor="region" numbered="true" toc="default">
y cover <name>Area/AS vs. Region</name>
EVPN. However, if "area" is replaced by "region" and "ABR" is replaced <t><xref target="RFC7524" format="default"/> addresses MVPN/VPLS inter-a
by "RBR" (Regional Border Router) then everything still works, and rea segmentation and does not explicitly cover
can be applied to EVPN as well. EVPNs. However, if "area" is replaced by "region" and "ABR" is replaced
</t> by "RBR" (Regional Border Router), then everything still works and
<t>A region can be a sub-area, or can be an entire AS including its can be applied to EVPNs as well.
external links. Instead of automatic region definition based on </t>
<t>A region can be a sub-area, or it can be an entire AS, including its
external links. Instead of automatically defining a region based on
IGP areas, a region would be defined as a BGP peer group. In fact, IGP areas, a region would be defined as a BGP peer group. In fact,
even with IGP area based region definition, a BGP peer group even with a region definition based on an IGP area, a BGP peer group
listing the PEs and ABRs in an area is still needed. listing the PEs and ABRs in an area is still needed.
</t> </t>
<t>Consider the following example diagram for inter-as segmentation: <t>Consider the following example diagram for inter-AS segmentation:
<figure> </t>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
--------- ------ --------- --------- ------ ---------
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
| PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 | | PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 |
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
--------- ------ --------- --------- ------ ---------
AS 100 AS 200 AS 300 AS 100 AS 200 AS 300
|-----------|--------|---------|--------|------------| |-----------|--------|---------|--------|------------|
segment1 segment2 segment3 segment4 segment5 segment1 segment2 segment3 segment4 segment5
</artwork> ]]></artwork>
</figure> <t>
The inter-as segmentation procedures specified so far ([RFC6513] [RFC6514 The inter-AS segmentation procedures specified so far (<xref target="RFC6
], 513" format="default"/>, <xref target="RFC6514" format="default"/>,
[RFC7117], and <xref target="inter-as"/> of this document) require all <xref target="RFC7117" format="default"/>, and <xref target="inter-as" fo
ASBRs to be involved, and Ingress Replication is used between two ASBRs rmat="default"/> of this document) require all
ASBRs to be involved, and ingress replication is used between two ASBRs
in different ASes. in different ASes.
</t> </t>
<t> <t>
In the above diagram, it's possible that ASBR1/4 does not support In the above diagram, it's possible that ASBR1/4 does not support
segmentation, and the provider tunnels in AS 100/300 can actually segmentation, and the provider tunnels in AS 100/300 can actually
extend across the external link. In this case, the inter-region extend across the external link. In this case, the inter-region
segmentation procedures can be used instead - a region is the segmentation procedures can be used instead -- a region is the
entire (AS100 + ASBR1-ASBR2 link) or (AS300 + ASBR3-ASBR4 link). entire AS100 plus the ASBR1-ASBR2 link or the entire AS300 plus the
ASBR3-ASBR4 link.
ASBR2/3 would be the RBRs, and ASBR1/4 will just be a transit core ASBR2/3 would be the RBRs, and ASBR1/4 will just be a transit core
router with respect to provider tunnels. router with respect to provider tunnels.
</t> </t>
<t>As illustrated in the diagram below, ASBR2/3 will establish a multihop <t>As illustrated in the diagram below, ASBR2/3 will establish a multiho
EBGP session with either a RR or directly with PEs in the neighboring p
EBGP session, either with a Route Reflector (RR) or directly with PEs in
the neighboring
AS. I/S-PMSI A-D routes from ingress PEs will not be processed by AS. I/S-PMSI A-D routes from ingress PEs will not be processed by
ASBR1/4. When ASBR2 re-advertises the routes into AS 200, it changes ASBR1/4. When ASBR2 re-advertises the routes into AS 200, it changes
the next hop to its own address and changes PTA to specify the tunnel the next hop to its own address and changes its PTA to specify the tunnel
type/identification in its own AS. When ASBR3 re-advertises type/identification in its own AS. When ASBR3 re-advertises
I/S-PMSI A-D routes into the neighboring AS 300, it changes the I/S-PMSI A-D routes into the neighboring AS 300, it changes the
next hop to its own address and changes PTA to specify the tunnel next hop to its own address and changes its PTA to specify the tunnel
type/identification in the neighboring region. Now the segment is type/identification in the neighboring region. Now, the segment is
rooted at ASBR3 and extends across the external link to PEs. rooted at ASBR3 and extends across the external link to PEs.
<figure> </t>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
--------- ------ --------- --------- ------ ---------
/ RR....\.mh-ebpg / \ mh-ebgp/....RR \ / RR....\.mh-ebpg / \ mh-ebgp/....RR \
/ : \ `. / \ .' / : \ / : \ `. / \ .' / : \
| PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 | | PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 |
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
--------- ------ --------- --------- ------ ---------
AS 100 AS 200 AS 300 AS 100 AS 200 AS 300
|-------------------|----------|---------------------| |-------------------|----------|---------------------|
segment 1 segment 2 segment 3 segment 1 segment 2 segment 3
</artwork> ]]></artwork>
</figure> </section>
</t> <section anchor="aggregation" numbered="true" toc="default">
</section> <name>Per-Region Aggregation</name>
<section title="Per-region Aggregation" anchor="aggregation"> <t>Notice that every I/S-PMSI route from each PE will be propagated
<t>Notice that every I/S-PMSI route from each PE will be propagated
throughout all the ASes or regions. They may also trigger corresponding throughout all the ASes or regions. They may also trigger corresponding
Leaf A-D routes depending on the types of tunnels used in each region. Leaf A-D routes, depending on the types of tunnels used in each region.
This may become too many - routes and corresponding tunnels. To address This may result in too many routes and corresponding tunnels. To address
this concern, the I-PMSI routes from all PEs in a AS/region can be this concern, the I-PMSI routes from all PEs in an AS/region can be
aggregated into a single I-PMSI route originated from the RBRs, aggregated into a single I-PMSI route originated from the RBRs,
and traffic from all those individual I-PMSI tunnels and traffic from all those individual I-PMSI tunnels
will be switched into the single I-PMSI tunnel. This is like the will be switched into the single I-PMSI tunnel. This is like the
MVPN Inter-AS I-PMSI route originated by ASBRs. MVPN Inter-AS I-PMSI route originated by ASBRs.
</t> </t>
<t>The MVPN Inter-AS I-PMSI A-D route can be better called as per-AS I-PMSI <t>The MVPN Inter-AS I-PMSI A-D route can be better called a "per-AS I-P
A-D route, to be compared against the (per-PE) Intra-AS I-PMSI A-D routes MSI
originated by each PE. In this document we will call it as per-region A-D route", to be compared against the (per-PE) Intra-AS I-PMSI A-D route
I-PMSI A-D route, in case we want to apply the aggregation at regional s
originated by each PE. In this document, we will call it a "per-region
I-PMSI A-D route" in cases where we want to apply aggregation at the regi
onal
level. The per-PE I-PMSI routes will not be propagated to other level. The per-PE I-PMSI routes will not be propagated to other
regions. If multiple RBRs are connected to a region, then each regions. If multiple RBRs are connected to a region, then each
will advertise such a route, with the same Region ID and Ethernet Tag ID will advertise such a route, with the same Region ID and Ethernet Tag ID
(<xref target= (<xref target="per-region" format="default"/>). Similar to the per-PE I-PMSI A-D
"per-region"/>). Similar to the per-PE I-PMSI A-D routes, RBRs/PEs in a downstream region will each select the best route
routes, RBRs/PEs in a downstream region will each select a best one from all those re-advertised by the upstream RBRs and hence will only
from all those re-advertised by the upstream RBRs, hence will only
receive traffic injected by one of them. receive traffic injected by one of them.
</t> </t>
<t>MVPN does not aggregate S-PMSI routes from all PEs in an AS like it <t>MVPNs do not aggregate S-PMSI routes from all PEs in an AS like they
does for I-PMSIs routes, because the number of PEs that will advertise do for I-PMSI routes, because the number of PEs that will advertise
S-PMSI routes for the same (s,g) or (*,g) is small. This is also the S-PMSI routes for the same (S,G) or (*,G) is small. This is also the
case for EVPN, i.e., there is no per-region S-PMSI routes. case for EVPNs, i.e., there are no per-region S-PMSI routes.
</t> </t>
<t>Notice that per-region I-PMSI routes can also be used to address <t>Notice that per-region I-PMSI routes can also be used to address
backwards compatibility issue, as discussed in backward-compatibility issues, as discussed in
<xref target="compatibility"/>. <xref target="compatibility" format="default"/>.
</t> </t>
<t>The Region ID in the per-region I-PMSI route's NLRI is encoded like an <t>The Region ID in the per-region I-PMSI route's NLRI is encoded like a
n
EC. For example, the EC. For example, the
Region ID can encode an AS number or area ID in the following EC format: Region ID can encode an AS number or area ID in the following EC format:
<list style="symbols"> </t>
<t>For a two-octet AS number, a Transitive Two-Octet AS-Specific <ul spacing="normal">
<li>For a two-octet AS number, a Transitive Two-Octet AS-specific
EC of sub-type 0x09 (Source AS), with the Global Administrator EC of sub-type 0x09 (Source AS), with the Global Administrator
sub-field set to the AS number and the Local Administrator sub-field set to the AS number and the Local Administrator
sub-field set to 0. sub-field set to 0.
</t> </li>
<t>For a four-octet AS number, a Transitive Four-Octet AS-Specific <li>For a four-octet AS number, a Transitive Four-Octet AS-specific
EC of sub-type 0x09 (Source AS), with the Global Administrator EC of sub-type 0x09 (Source AS), with the Global Administrator
sub-field set to the AS number and the Local Administrator sub-field set to the AS number and the Local Administrator
sub-field set to 0. sub-field set to 0.
</t> </li>
<t>For an area ID, a Transitive IPv4-Address-Specific EC of any <li>For an area ID, a Transitive IPv4-Address-specific EC of any
sub-type, with the Global Administrator sub-type, with the Global Administrator
sub-field set to the area ID and the Local Administrator sub-field set to the area ID and the Local Administrator
sub-field set to 0. sub-field set to 0.
</t> </li>
</list> </ul>
Uses of other EC encoding MAY be allowed as long as it uniquely <t>
identifies the region and the RBRs for the same region uses the The use of other EC encodings <bcp14>MAY</bcp14> be allowed as long as th
ey uniquely
identify the region and the RBRs for the same region use the
same Region ID. same Region ID.
</t> </t>
</section> </section>
<section title="Use of S-NH-EC"> <section numbered="true" toc="default">
<t>[RFC7524] specifies the use of S-NH-EC because it does not allow ABRs <name>Use of S-NH-EC</name>
<t><xref target="RFC7524" format="default"/> specifies the use of the S-
NH-EC because it does not allow ABRs
to change the BGP next hop when they re-advertise I/S-PMSI A-D routes to change the BGP next hop when they re-advertise I/S-PMSI A-D routes
to downstream areas. That is only to be consistent with the MVPN to downstream areas. That behavior is only to be consistent with the MVPN
Inter-AS I-PMSI A-D routes, whose next hop must not be changed Inter-AS I-PMSI A-D routes, whose next hop must not be changed
when they're re-advertised by the segmenting ABRs for reasons specific when they're re-advertised by the segmenting ABRs for reasons specific
to MVPN. For EVPN, to MVPNs. For EVPNs,
it is perfectly fine to change the next hop when RBRs re-advertise it is perfectly fine to change the next hop when RBRs re-advertise
the I/S-PMSI A-D routes, instead of relying on S-NH-EC. As a result, the I/S-PMSI A-D routes, instead of relying on the S-NH-EC. As a result,
this document specifies that RBRs change the BGP next hop when they this document specifies that RBRs change the BGP next hop when they
re-advertise I/S-PMSI A-D routes and do not use S-NH-EC. re-advertise I/S-PMSI A-D routes and do not use the S-NH-EC. This provide
The advantage of this is that neither ingress nor egress PEs need to s
understand/use S-NH-EC, and a consistent procedure (based on BGP next the advantage that neither ingress PEs nor egress PEs need to
hop) is used for both inter-as and inter-region segmentation. understand/use the S-NH-EC, and a consistent procedure (based on BGP next
</t> hops) is used for both inter-AS and inter-region segmentation.
<t> </t>
<t>
If a downstream PE/RBR needs to originate Leaf A-D routes, it constructs If a downstream PE/RBR needs to originate Leaf A-D routes, it constructs
an IP-based Route Target Extended Community by an IP-based Route Target Extended Community by
placing the IP address carried in the Next Hop of the received placing the IP address carried in the Next Hop of the received
I/S-PMSI A-D route in the Global Administrator field of the I/S-PMSI A-D route in the Global Administrator field of the extended
Community, with the Local Administrator field of this Community community, with the Local Administrator field of this extended community
set to 0 and setting the Extended Communities attribute of the set to 0, and also setting the Extended Communities attribute of the
Leaf A-D route to that Community. Leaf A-D route to that extended community.
</t> </t>
<t>Similar to [RFC7524], the upstream RBR MUST (auto-)configure <t>Similar to <xref target="RFC7524" format="default"/>, the upstream RB
a RT with the Global Administrator field set to the Next Hop in R <bcp14>MUST</bcp14> (auto-)configure
an RT with the Global Administrator field set to the Next Hop in
the re-advertised I/S-PMSI A-D route and with the Local Administrator the re-advertised I/S-PMSI A-D route and with the Local Administrator
field set to 0. With this, the mechanisms specified in [RFC4684] field set to 0. Using this technique, the mechanisms specified in <xref t arget="RFC4684" format="default"/>
for constrained BGP route for constrained BGP route
distribution can be used along with this specification to ensure that distribution can be used along with this specification to ensure that
only the needed PE/ABR will have to process a said Leaf A-D route. only the needed PE/ABR will have to process a particular Leaf A-D route.
</t> </t>
</section> </section>
<section title="Ingress PE's I-PMSI Leaf Tracking"> <section numbered="true" toc="default">
<t>[RFC7524] specifies that when an ingress PE/ASBR (re-)advertises an <name>Ingress PE's I-PMSI Leaf Tracking</name>
<t><xref target="RFC7524" format="default"/> specifies that when an ingr
ess PE/ASBR (re-)advertises a
VPLS I-PMSI A-D route, it sets the L flag to 1 in the route's PTA. VPLS I-PMSI A-D route, it sets the L flag to 1 in the route's PTA.
Similar to the inter-as case, this is actually not really needed Similar to the inter-AS case, this is actually not really needed
for EVPN. To be consistent with the inter-as case, the ingress PE for EVPNs. To be consistent with the inter-AS case, the ingress PE
does not set the L flag in its originated I-PMSI A-D routes, does not set the L flag in its originated I-PMSI A-D routes,
and determines the leaves based on the BGP next hops in its received and it determines the leaves based on the BGP next hops in its received
I-PMSI A-D routes, as specified in <xref target="leaf-tracking"/>. I-PMSI A-D routes, as specified in <xref target="leaf-tracking" format="d
</t> efault"/>.
<t>The same backward compatibility issue exists, and the same solution </t>
as in the inter-as case applies, as specified in <xref target= <t>The same backward-compatibility issue exists, and the same solution
"compatibility"/>. as that for the inter-AS case applies, as specified in <xref target="comp
</t> atibility" format="default"/>.
</section> </t>
</section>
</section> </section>
<section title="Multi-homing Support"> <section numbered="true" toc="default">
<!-- <name>Multihoming Support</name>
<t>EVPN support active-active multi-homing. For BUM traffic, only an <t>To support multihoming with segmentation, Ethernet Segment Identifier
elected DF PE is allowed to send to a multi-homed Ethernet Segment (ES), (ESI) labels <bcp14>SHOULD</bcp14> be
while a TS may use any of its active-active links to the ES. If the allocated from a "Domain-wide Common Block" (DCB)
link a TS uses is not attached to the DF PE, the receiving non-DF PE <xref target="RFC9573" format="default"/> for all
will deliver the traffic to all PEs in the same EVI, including the DF PE tunnel types, including Ingress Replication tunnels <xref target="RFC7988
for the sourcing ES. To prevent the DF PE from delivering the received "/>.
traffic back to the ES, in case of MPLS encapsulation, a BUM packet
from a non-DF PE carries an ESI
label, so that when the DF receives the packet it will know from the ESI
label that the packet is from a non-DF for an ES and will not send the
packet back to the ES.
</t>
<t>To support multi-homing with segmentation, ESI labels SHOULD be
allocated from "Domain-wide Common Block" (DCB)
<xref target="I-D.ietf-bess-mvpn-evpn-aggregation-label"/> for all
tunnel types including Ingress Replication.
Via means outside the scope of this document, PEs know that ESI labels Via means outside the scope of this document, PEs know that ESI labels
are from DCB and then existing multi-homing procedures work as is are from a DCB, and existing multihoming procedures will then work "as is
(whether a multi-homed Ethernet Segment spans across segmentation "
(whether a multihomed Ethernet Segment spans segmentation
regions or not). regions or not).
</t>
<t>Not using DCB-allocated ESI labels is outside the scope of this
document.<!-- It would require complicated forwarding
procedures on segmentation points, and, in case of multi-homing across
segmentation regions, complicated control plane procedures as well.-->
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA has temporarily assigned the following new EVPN route types in
the EVPN Route Types registry:
<list style="symbols">
<t>9 - Per-Region I-PMSI A-D route</t>
<t>10 - S-PMSI A-D route</t>
<t>11 - Leaf A-D route</t>
</list>
</t> </t>
<t>This document requests IANA to assign one flag bit from the <t>Not using DCB-allocated ESI labels is outside the scope of this
EVPN Multicast Flags Extended Community Flags registry to be created in document.
[draft-ietf-bess-evpn-igmp-mld-proxy]:
<list style="symbols">
<t>Bit-S - Segmentation Procedure Support
</t>
</list>
</t> </t>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="IANA" numbered="true" toc="default">
<t> <name>IANA Considerations</name>
The Selective Forwarding procedures via S-PMSI/Leaf A-D routes <t>IANA has assigned the following new EVPN route types in
in this document are based on the same procedures for MVPN [RFC6513] [R the "EVPN Route Types" registry:
FC6514] </t>
and VPLS Multicast [RFC7117]. The tunnel segmentation procedures
in this document are based on the similar procedures for MVPN inter-AS <table anchor="tab-1">
[RFC6514] and inter-area [RFC7524] tunnel segmentation, and procedures <name>New Route Types</name>
for VPLS Multicast [RFC7117] inter-as tunnel segmentation. <thead>
When applied to EVPN, they do not introduce new security concerns <tr>
besides what have been discussed in [RFC6513], [RFC6514], [RFC7117], <th>Value</th>
and [RFC7524]. They also do not introduce new security concerns <th>Description</th>
compared to [RFC7432]. <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>9</td>
<td>Per-Region I-PMSI A-D route</td>
<td>RFC 9572</td>
</tr>
<tr>
<td>10</td>
<td>S-PMSI A-D route</td>
<td>RFC 9572</td>
</tr>
<tr>
<td>11</td>
<td>Leaf A-D route</td>
<td>RFC 9572</td>
</tr>
</tbody>
</table>
<t>IANA has assigned one flag bit from the
"Multicast Flags Extended Community" registry created by
<xref target="RFC9251"/>:
</t> </t>
<table anchor="tab-2">
<name>New Multicast Flag</name>
<thead>
<tr>
<th>Bit</th>
<th>Name</th>
<th>Reference</th>
<th>Change Controller</th>
</tr>
</thead>
<tbody>
<tr>
<td>8</td>
<td>Segmentation Support</td>
<td>RFC 9572</td>
<td>IETF</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements"> <section anchor="Security" numbered="true" toc="default">
<t>The authors thank Eric Rosen, John Drake, and Ron Bonica for their <name>Security Considerations</name>
comments and suggestions. <t>
The procedures specified in this document for selective forwarding via
S-PMSI/Leaf A-D routes
are based on the same procedures as those used for MVPNs <xref target="
RFC6513" format="default"/> <xref target="RFC6514" format="default"/>
and VPLS multicast <xref target="RFC7117" format="default"/>. The proce
dures for tunnel segmentation as specified
in this document are based on similar procedures used for MVPN inter-AS
tunnel segmentation <xref target="RFC6514" format="default"/> and inter-area tu
nnel segmentation <xref target="RFC7524" format="default"/>, as well as procedur
es
for VPLS multicast inter-AS tunnel segmentation <xref target="RFC7117"
format="default"/>.
When applied to EVPNs, they do not introduce new security concerns
beyond those discussed in <xref target="RFC6513" format="default"/>, <xref t
arget="RFC6514" format="default"/>, <xref target="RFC7117" format="default"/>,
and <xref target="RFC7524" format="default"/>. They also do not introduce ne
w security concerns
compared to <xref target="RFC7432" format="default"/>.
</t> </t>
</section> </section>
<section title="Contributors"> </middle>
<t>The following also contributed to this document through their earlier <back>
work in EVPN selective multicast. <references>
<figure> <name>References</name>
<artwork> <references>
Junlin Zhang <name>Normative References</name>
Huawei Technologies <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
Huawei Bld., No.156 Beiqing Rd. 119.xml"/>
Beijing 100095 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
China 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
117.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
524.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
584.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
534.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
513.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
514.xml"/>
Email: jackey.zhang@huawei.com <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9251.xml" />
Zhenbin Li <!-- draft-ietf-bess-mvpn-evpn-aggregation-label (AUTH48 as RFC 9573) -->
Huawei Technologies <reference anchor='RFC9573' target="https://www.rfc-editor.org/info/rfc9573">
Huawei Bld., No.156 Beiqing Rd. <front>
Beijing 100095 <title>MVPN/EVPN Tunnel Aggregation with Common Labels</title>
China <author initials='Z' surname='Zhang' fullname='Zhaohui Zhang'>
<organization />
</author>
<author initials='E' surname='Rosen' fullname='Eric Rosen'>
<organization />
</author>
<author initials='W' surname='Lin' fullname='Wen Lin'>
<organization />
</author>
<author initials='Z' surname='Li' fullname='Zhenbin Li'>
<organization />
</author>
<author initials='IJ' surname='Wijnands' fullname='IJsbrand Wijnands'>
<organization />
</author>
<date year='2024' month='April' />
</front>
<seriesInfo name="RFC" value="9573"/>
<seriesInfo name="DOI" value="10.17487/RFC9573"/>
</reference>
Email: lizhenbin@huawei.com </references>
</artwork> <references>
</figure> <name>Informative References</name>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</section> 279.xml"/>
</middle> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
875.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
684.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
388.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
988.xml"/>
<back> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<references title="Normative References"> 136.xml"/>
&RFC2119; </references>
&RFC8174;
&RFC7432;
&RFC7117;
&RFC7524;
&RFC8584;
&RFC8534;
&RFC6513;
&RFC6514;
<?rfc include='reference.I-D.ietf-bess-evpn-igmp-mld-proxy'?>
<?rfc include='reference.I-D.ietf-bess-mvpn-evpn-aggregation-label'?>
</references> </references>
<references title="Informative References"> <section anchor="Acknowledgements" numbered="false" toc="default">
&RFC8279; <name>Acknowledgements</name>
&RFC4875; <t>The authors thank <contact fullname="Eric Rosen"/>, <contact fullname="
&RFC4684; John Drake"/>, and <contact fullname="Ron Bonica"/> for their
&RFC6388; comments and suggestions.
&RFC7988; </t>
<?rfc include='reference.I-D.ietf-bess-evpn-prefix-advertisement'?> </section>
</references> <section numbered="false" toc="default">
<name>Contributors</name>
<t>The following people also contributed to this document through their ea
rlier
work in EVPN selective multicast.
</t>
<contact fullname="Junlin Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No. 156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>jackey.zhang@huawei.com</email>
</address>
</contact>
<contact fullname="Zhenbin Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No. 156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>lizhenbin@huawei.com</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 134 change blocks. 
676 lines changed or deleted 905 lines changed or added

This html diff was produced by rfcdiff 1.48.