rfc9624xml2.original.xml   rfc9624.xml 
<?xml version="1.1" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?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" docName="draft-ietf-bier-evpn-14" ipr="trust200902">
<front>
<title abbrev="bier-evpn">EVPN BUM Using BIER</title>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-bier-evpn-14" number="9624" ipr="trust200902" consensus="true" obsoletes="" u
pdates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" sym
Refs="true" sortRefs="true" version="3">
<front>
<title abbrev="EVPN BUM Using BIER">EVPN Broadcast, Unknown Unicast, or Mult
icast (BUM) Using Bit Index
Explicit Replication (BIER)</title>
<seriesInfo name="RFC" value="9624"/>
<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="Tony Przygienda" initials="T." surname="Przygienda">
<author fullname="Antoni Przygienda" initials="A." surname="Przygienda">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>prz@juniper.net</email> <email>prz@juniper.net</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>
<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>
<date year="2024"/> <date month="August" year="2024"/>
<area>RTF</area>
<workgroup>BIER</workgroup> <workgroup>BIER</workgroup>
<abstract> <abstract>
<t>This document specifies protocols and procedures for forwarding <t>This document specifies protocols and procedures for forwarding
broadcast, unknown unicast, and multicast (BUM) traffic Broadcast, Unknown Unicast, or Multicast (BUM) traffic
of Ethernet VPNs (EVPN) using Bit Index Explicit Replication (BIER). of Ethernet VPNs (EVPNs) using Bit Index Explicit Replication (BIER).
</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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
</t>
</note>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t><xref target="RFC7432"/> and <xref target='RFC8365'/> specify <name>Introduction</name>
the protocols and procedures for Ethernet VPNs (EVPNs). For broadcast, <t><xref target="RFC7432" format="default"/> and <xref target="RFC8365" fo
unknown unicast and multicast (BUM) traffic, provider/underlay tunnels rmat="default"/> specify
the protocols and procedures for Ethernet VPNs (EVPNs). For Broadcast,
Unknown Unicast, or Multicast (BUM) traffic, provider/underlay tunnels
are used to carry the BUM traffic. Several are used to carry the BUM traffic. Several
kinds of tunnel technologies can be used as specified in <xref target="RF kinds of tunnel technologies can be used as specified in <xref target="RF
C7432"/> and C7432" format="default"/> and
<xref target="RFC8365"/>, and this document specifies the protocols an <xref target="RFC8365" format="default"/>, and this document specifies
d procedures to the protocols and procedures to
use Bit Index Explicit Replication (BIER) use Bit Index Explicit Replication (BIER)
<xref target='RFC8279'/> as provider tunnels for EVPN BUM traffic. <xref target="RFC8279" format="default"/> as provider tunnels for EVPN BUM tr
</t> affic.
<t> </t>
<t>
BIER is an BIER is an
architecture that provides optimal multicast forwarding through a architecture that provides optimal multicast forwarding through a
"multicast domain", without requiring intermediate routers to "multicast domain" without requiring intermediate routers to
maintain any per-flow state or to engage in an explicit tree-building maintain any per-flow state or to engage in an explicit tree-building
protocol. protocol.
</t> </t>
<t> <t>
The EVPN BUM procedures specified in <xref target="RFC7432"/> and extende The EVPN BUM procedures specified in <xref target="RFC7432" format="defau
d in <xref lt"/> and extended in <xref target="RFC9572" format="default"/>, <xref target="R
target='I-D.ietf-bess-evpn-bum-procedure-updates'/>, <xref FC9251" format="default"/>, and <xref target="I-D.zzhang-bess-mvpn-evpn-cmcast-e
target='RFC9251'/>, and <xref nhancements" format="default"/>
target='I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements'/> are much aligned with Multicast VPN (MVPN) procedures <xref target="RFC65
are much aligned with Multicast VPN (MVPN) procedures <xref target="RFC65 14" format="default"/>,
14"/> and an EVPN Broadcast Domain (BD) corresponds to a VPN in MVPN.
and an EVPN Broadcast Domain corresponds to a VPN in MVPN. As such, this document is also very much aligned with <xref target="RF
As such, this document is also very much aligned with <xref target='RF C8556" format="default"/>, which specifies MVPN with BIER.
C8556'/> that specifies MVPN with BIER. For terseness, some background, terms, and concepts are not
For terseness, some background, terms and concepts are not
repeated here. Additionally, some text is borrowed verbatim from repeated here. Additionally, some text is borrowed verbatim from
<xref target='RFC8556'/>. <xref target="RFC8556" format="default"/>.
</t> </t>
<section title="Terminologies"> <section numbered="true" toc="default">
<t> <name>Terminology</name>
<list style="symbols"> <dl newline="false" spacing="normal">
<t>ES: Ethernet Segment.</t> <dt>ES:</dt> <dd>Ethernet Segment</dd>
<t>ESI: Ethernet Segment Identifier.</t> <dt>ESI:</dt> <dd>Ethernet Segment Identifier</dd>
<t>BFR: Bit-Forwarding Router.</t> <dt>BFR:</dt> <dd>Bit-Forwarding Router</dd>
<t>BFIR: Bit-Forwarding Ingress Router.</t> <dt>BFIR:</dt> <dd>Bit-Forwarding Ingress Router</dd>
<t>BFER: Bit-Forwarding Egress Router.</t> <dt>BFER:</dt> <dd>Bit-Forwarding Egress Router</dd>
<t>BFR-Prefix: An IP address that uniquely identifies a BFR <dt>BFR-Prefix:</dt> <dd>An IP address that uniquely identifies a BF
and is routable in a BIER domain.</t> R
<t> and is routable in a BIER domain.</dd>
C-S: A multicast source address identifying a multicast source <dt>C-S:</dt> <dd>A multicast source address identifying a multicast
source
located at an EVPN customer site. "C-" stands for "Customer-". located at an EVPN customer site. "C-" stands for "Customer-".
</t> </dd>
<t> <dt>C-G:</dt> <dd>A multicast group address used by an EVPN customer
C-G: A multicast group address used by an EVPN customer. .</dd>
</t> <dt>C-flow:</dt> <dd>A customer multicast flow. Each C-flow is iden
<t> tified by
C-flow: A customer multicast flow. Each C-flow is identified by
the ordered pair (source address, group address), where each the ordered pair (source address, group address), where each
address is in the customer's address space. The identifier of a address is in the customer's address space. The identifier of a
particular C-flow is usually written as (C-S, C-G). particular C-flow is usually written as (C-S, C-G).
Sets of C-flows can be denoted by the use of the "C-*" wildcard Sets of C-flows can be denoted by the use of the "C-*" wildcard
(see <xref target="RFC6625"/>), e.g., (C-*, C-G). (see <xref target="RFC6625" format="default"/>), e.g., (C-*, C-G).</dd
</t> >
<t> <dt>P-tunnel:</dt> <dd>A multicast tunnel through the network of one
P-tunnel. A multicast tunnel through the network of one or more or more
service providers used to transport C-flows. "P-" stands for "Provider -". service providers used to transport C-flows. "P-" stands for "Provider -".
</t> </dd>
<t> <dt>IMET A-D Route:</dt> <dd>Inclusive Multicast Ethernet Tag
IMET Route: Inclusive Multicast Ethernet Tag
Auto-Discovery route. Carried in BGP Update messages, these Auto-Discovery route. Carried in BGP Update messages, these
routes are used to advertise the "default" P-tunnel for a routes are used to advertise the "default" P-tunnel for a
particular broadcast domain. particular BD.</dd>
</t> <dt>SMET A-D Route:</dt> <dd>Selective Multicast Ethernet Tag
<t>
SMET Route: Selective Multicast Ethernet Tag
Auto-Discovery route. Carried in BGP Update messages, these Auto-Discovery route. Carried in BGP Update messages, these
routes are used to advertise the C-flows that the advertising PE routes are used to advertise the C-flows that the advertising Provider
is interested in. Edge (PE)
</t> is interested in.</dd>
<t>PMSI [RFC6513]: Provider Multicast Service Interface - a conceptual in <dt>PMSI:</dt> <dd>Provider Multicast Service Interface <xref target="
terface for a PE RFC6513" format="default"/>. A conceptual interface used by 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. For all PEs in the same VPN.</dd>
<t>I-PMSI: Inclusive PMSI - to all PEs in the same VPN. <dt>S-PMSI:</dt> <dd>Selective PMSI. For some of the PEs in the same V
</t> PN.</dd>
<t>S-PMSI: Selective PMSI - to some of the PEs in the same VPN. <dt>I-PMSI A-D Route:</dt> <dd>Inclusive PMSI Auto-Discovery route use
</t> d to advertise the tunnels that instantiate an I-PMSI.</dd>
<t>I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route used to adver <dt>S-PMSI A-D Route:</dt> <dd>Selective PMSI Auto-Discovery route use
tise the tunnels that instantiate an I-PMSI. d to advertise that particular C-flows are
</t> bound to (i.e., are traveling through) particular P-tunnels.</dd>
<t> <dt>PTA:</dt> <dd>PMSI Tunnel Attribute. A BGP attribute used
S-PMSI A-D route: Selective PMSI Auto-Discovery route used to advertis to identify a particular P-tunnel.</dd>
e that particular C-flows are <dt>VXLAN:</dt> <dd>Virtual eXtensible Local Area Network <xref target
bound to (i.e., are traveling through) particular P-tunnels. ="RFC7348" format="default"/></dd>
</t> <dt>NVGRE:</dt> <dd>Network Virtualization Using Generic Routing Encap
<t> sulation <xref target="RFC7637" format="default"/></dd>
PMSI Tunnel attribute (PTA): A BGP attribute used <dt>GENEVE:</dt> <dd>Generic Network Virtualization Encapsulation <xre
to identify a particular P-tunnel. f target="RFC8926" format="default"/></dd>
</t> <dt>VNI:</dt> <dd>VXLAN Network Identifier</dd>
<t>VXLAN [RFC7348]: Virtual eXtensible Local Area Network. <dt>VSID:</dt> <dd>Virtual Subnet Identifier</dd>
</t> <dt>RSVP-TE P2MP:</dt> <dd>Resource Reservation Protocol for Point-to-
<t>NVGRE [RFC7637]: Network Virtualization using Generic Routing Encapsul Multipoint TE Label Switched Paths (LSPs) <xref target="RFC4875" format="default
ation. "/></dd>
</t> <dt>mLDP P2MP:</dt> <dd>Multipoint Label Distribution Protocol extensio
<t>GENEVE [RFC8926]: Generic Network Virtualization Encapsulation. ns
</t> for Point-to-Multipoint LSPs <xref target="RFC6388" format="default"/></dd>
<t>VNI: VXLAN Network Identifier. </dl>
</t> </section>
<t>VSID: Virtual Subnet IDentifier. <section>
</t> <name>Requirements Language</name>
<t>RSVP-P2MP [RFC4875]: Resource ReserVation Protocol for Point-to-Multip <t>
oint TE Label Switched Paths. The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
</t> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<t>mLDP-P2MP [RFC6388]: Label Distribution Protocol Extensions for NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</list> be interpreted as
</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section title="Use of the PMSI Tunnel Attribute" anchor="pta"> </section>
<t><xref target="RFC7432"/> specifies that Inclusive Multicast Ethernet Tag <section anchor="pta" numbered="true" toc="default">
(IMET) <name>Use of the PMSI Tunnel Attribute</name>
<t><xref target="RFC7432" format="default"/> specifies that Inclusive Mult
icast Ethernet Tag (IMET)
routes carry a PMSI Tunnel Attribute (PTA) to identify the particular routes carry a PMSI Tunnel Attribute (PTA) to identify the particular
P-tunnel to which one or more BUM flows are being assigned, the same as P-tunnel to which one or more BUM flows are being assigned, which is the
specified in <xref target="RFC6514"/> for MVPN. same as
<xref target='RFC8556'/> specifies the encoding of specified in <xref target="RFC6514" format="default"/> for MVPN.
<xref target="RFC8556" format="default"/> specifies the encoding of the
PTA for the use of BIER with MVPN. Much of that specification is reused PTA for the use of BIER with MVPN. Much of that specification is reused
for the use of BIER with EVPN and much of the text below is borrowed for the use of BIER with EVPN, and much of the text below is borrowed
verbatim from <xref target='RFC8556'/>. verbatim from <xref target="RFC8556" format="default"/>.
</t> </t>
<t>The PMSI Tunnel Attribute (PTA) contains the following fields: <t>The PTA contains the following fields:
<list style="symbols"> </t>
<t>"Tunnel Type". The same codepoint 0x0B that IANA has assigned for <ul spacing="normal">
BIER for MVPN <xref target='RFC8556'/> is used for EVPN as well. <li>
<!--The "composite tunnel" bit <xref target="RFC8317"/> of the type field <t>Tunnel Type. The same codepoint 0x0B that IANA has assigned for
can also be set. BIER for MVPN <xref target="RFC8556" format="default"/> is used for EVP
Its semantics are updated in N as well.
[I-D.draft-zzhang-bess-mvpn-evpn-composite-tunnel]. In that case, </t>
the tunnel is referred to as a BIER composite tunnel. An example of its </li>
usage is provided in Section <xref target="ar"/> of this document.--> <li>
</t> <t>Tunnel Identifier. This field contains three subfields for BIER.
<t>"Tunnel Identifier". This field contains three subfields for BIER.
The text below is exactly as in The text below is exactly as in
<xref target='RFC8556'/>. <xref target="RFC8556" format="default"/>.
<list style="format %d"> </t>
<t> <ol spacing="normal" type="1"><li>
The first subfield is a single octet, containing the sub- <t>
domain-id of the sub-domain to which the BFIR will assign the The first subfield is a single octet, containing a BIER
packets that it transmits on the PMSI identified by the sub-domain-id (see <xref target="RFC8279"/>). This indicates that
Network Layer Reachability Information (NLRI) of the IMET, packets sent on the PMSI will be sent on the specified BIER sub-domain.
S-PMSI A-D, or per-region I-PMSI A-D route that contains this PTA.
How that sub-domain is chosen is outside the scope of this How that sub-domain is chosen is outside the scope of this
document. document.
</t> </t>
<t> The second subfield is a two-octet field containing the </li>
BFR-id, in the sub-domain identified in the first subfield, of <li>
<t> The second subfield is a two-octet field containing the
BFR-id in the sub-domain identified in the first subfield of
the router that is constructing the PTA. </t> the router that is constructing the PTA. </t>
<t> </li>
<li>
<t>
The third subfield is the BFR-Prefix (see The third subfield is the BFR-Prefix (see
<xref target='RFC8279'/>) of the <xref target="RFC8279" format="default"/>) of the
originator of the route that is carrying this PTA. This will router (a BFIR) that is constructing the PTA. The BFR-Prefix will
either be a /32 IPv4 address or a /128 IPv6 address. Whether either be a /32 IPv4 address or a /128 IPv6 address. Whether
the address is IPv4 or IPv6 can be inferred from the total the address is IPv4 or IPv6 can be inferred from the total
length of the PMSI Tunnel attribute. length of the PTA.
<vspace/> </t>
<vspace/> <t>
The BFR-prefix need not be the same IP address that is carried The BFR-Prefix need not be the same IP address that is carried
in any other field of the x-PMSI A-D route, even if the BFIR in any other field of the x-PMSI A-D route, even if the BFIR
is the originating router of the x-PMSI A-D route. is the originating router of the x-PMSI A-D route.
</t> </t>
</list> </li>
<!--If the "composite tunnel" bit is set, as specified in </ol>
[I-D.draft-zzhang-bess-mvpn-evpn-composite-tunnel], <t>
a three-octet label field is added before the "Tunnel Identifier" field </t>
to indicate the IR label that this PE uses to receive IR traffic with. </li>
The three-octet label field after the Tunnel Type field is the label <li>
that this PE uses to send/receive BIER traffic with.--> <t>MPLS Label. For EVPN-MPLS <xref target="RFC7432" format="default"/
</t> >, this field contains an upstream-assigned
<t>"MPLS label". For EVPN-MPLS <xref target="RFC7432"/>, this field contain
s an upstream-assigned
MPLS label. It is assigned by the BFIR. Constraints on how the originat ing router selects this label are discussed in MPLS label. It is assigned by the BFIR. Constraints on how the originat ing router selects this label are discussed in
<xref target="label"/>. For EVPN-VXLAN/NVGRE/GENEVE <xref target="label" format="default"/>. For EVPN-VXLAN/NVGRE/GENEVE
<xref target='RFC8365'/> <xref target='RFC7348'/> <xref target='RFC7637'/ <xref target="RFC8365" format="default"/> <xref target="RFC7348" format="
> <xref target='RFC8926'/>, this field is a 24-bit default"/> <xref target="RFC7637" format="default"/> <xref target="RFC8926" form
at="default"/>, this field is a 24-bit
VNI/VSID of global significance. VNI/VSID of global significance.
</t> </t>
<t>"Flags". When the tunnel type is BIER, two of the flags in the </li>
<li>
<t>Flags. When the tunnel type is BIER, two of the flags in the
PTA Flags field are meaningful. Details about the use of these PTA Flags field are meaningful. Details about the use of these
flags can be found in <xref target="tracking"/>. flags can be found in <xref target="tracking" format="default"/>.
<list style="symbols"> </t>
<t>"Leaf Info Required per Flow (LIR-pF)" <xref target="RFC8534"/> <ul spacing="normal">
</t> <li>
<t>"Leaf Info Required Bit (LIR)" <t>Leaf Info Required per Flow (LIR-pF) <xref target="RFC8534" for
</t> mat="default"/>
</list> </t>
</t> </li>
<!--t>"Auxiliary Information". This is optional, present if the total <li>
length of the PTA is larger then the sum of lengths of the fields before <t>Leaf Info Required (LIR)
this one. It is in the form of a series of TLVs. </t>
</t--> </li>
</list> </ul>
</t> </li>
<t> </ul>
<t>
Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI A-D, Note that if a PTA specifying "BIER" is attached to an IMET, S-PMSI A-D,
or per-region I-PMSI A-D route, the route MUST NOT be distributed beyond the or per-region I-PMSI A-D route, the route <bcp14>MUST NOT</bcp14> be distribu ted beyond the
boundaries of a BIER domain. That is, any routers that receive the boundaries of a BIER domain. That is, any routers that receive the
route must be in the same BIER domain as the originator of the route. route must be in the same BIER domain as the originator of the route.
If the originator is in more than one BIER domain, the route must be If the originator is in more than one BIER domain, the route must be
distributed only within the BIER domain in which the BFR-Prefix in distributed only within the BIER domain in which the BFR-Prefix in
the PTA uniquely identifies the originator. As with all MVPN routes, the PTA uniquely identifies the originator. As with all MVPN routes,
the distribution of these routes is controlled by the provisioning of the distribution of these routes is controlled by the provisioning of
Route Targets. Route Targets.
</t> </t>
<!--section title = "Auxiliary Information"> <section anchor="php-address" numbered="true" toc="default">
<t>For the "Auxiliary Information", one TLV is defined in this document - <name>IP-Based Tunnel and BIER PHP</name>
Tunnel Encapsulation TLV. The value part of the TLV is a Tunnel TLV <t>When VXLAN/NVGRE/GENEVE is used for EVPN, by default, the outer IP he
as defined in <xref target="RFC9012"/>. ader
</t>
<t>This MAY be used when VXLAN/NVGRE/GENEVE encapsulation with an IP header
(and UDP header in the case of VXLAN/GENEVE) is the BIER payload.
Normally that is not needed with BIER, except when BIER Penultimate Hop
Popping (PHP) <xref target="I-D.ietf-bier-php"/> is used and the encap
sulation (after BIER header is
popped) between the BIER Penultimate Hop and the egress PE does not have
a way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case
the full VXLAN/NVGRE/GENEVE encapsulation with an IP header MUST be
used. The tunnel type (VXLAN/NVGRE/GENEVE), endpoint, and
some tunnel specific information MAY be specified in the Tunnel TLV
or MAY be provisioned on PEs.
The tunnel endpoint MUST be an IP multicast address and the receiving
egress PE MUST be set up to receive and process packets addressed to
the address. The same multicast address can be used for
all Bridge Domains (BDs), as the the inner VXLAN/NVGRE/GENEVE header will
be used
to identify BDs.
</t>
</section-->
<section title="IP-Based Tunnel and BIER PHP" anchor="php-address">
<t>When VXLAN/NVGRE/GENEVE is used for EVPN, by default the outer IP header
(and UDP header in the case of VXLAN/GENEVE) is not included in the BIER (and UDP header in the case of VXLAN/GENEVE) is not included in the BIER
payload, except when it is known apriori that BIER Penultimate Hop payload, except when it is known a priori that BIER Penultimate Hop
Popping (PHP) Popping (PHP)
<xref target="I-D.ietf-bier-php"/> is used in the BIER domain and <xref target="I-D.ietf-bier-php" format="default"/> is used in the BIER d omain and
the encapsulation (after the BIER header is the encapsulation (after the BIER header is
popped) between the BIER Penultimate Hop and the egress PE does not have popped) between the BIER Penultimate Hop and the egress PE does not have
a way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case a way to indicate the next header is VXLAN/NVGRE/GENEVE. In that case,
the full VXLAN/NVGRE/GENEVE encapsulation MUST be used. In the outer the full VXLAN/NVGRE/GENEVE encapsulation <bcp14>MUST</bcp14> be used. In
the outer
IP header, a well-known IP multicast address IP header, a well-known IP multicast address
(to be assigned by IANA) is used as the destination address and the (224.0.0.122 in the case of IPv4 or FF02:0:0:0:0:0:0:14 in the case of IP
egress PEs MUST be set up to receive and process packets addressed to v6) is used as the destination address, and the
the address. The address is used for all Broadcast Domains (BDs) and the egress PEs <bcp14>MUST</bcp14> be set up to receive and process packets a
inner ddressed to
the destination address. The address is used for all BDs, and the inner
VXLAN/NVGRE/GENEVE header will be used to identify BDs. VXLAN/NVGRE/GENEVE header will be used to identify BDs.
</t> </t>
</section> </section>
<section title="Explicit Tracking" anchor="tracking"> <section anchor="tracking" numbered="true" toc="default">
<t> <name>Explicit Tracking</name>
<t>
When using BIER to transport an EVPN BUM data packet through a BIER When using BIER to transport an EVPN BUM data packet through a BIER
domain, an ingress PE functions as a BFIR (see domain, an ingress PE functions as a BFIR (see
<xref target='RFC8279'/>). The <xref target="RFC8279" format="default"/>). The
BFIR must determine the set of BFERs to which the packet needs to be BFIR must determine the set of BFERs to which the packet needs to be
delivered. This can be done in either of two ways in the following delivered. This can be done in either of two ways as described in the follow ing
two sections. two sections.
</t> </t>
<section title="Using IMET/SMET routes"> <section numbered="true" toc="default">
<t>Both IMET and SMET routes provide explicit tracking functionality. <name>Using IMET/SMET Routes</name>
</t> <t>Both IMET and SMET routes provide explicit tracking functionality.
<t>For an inclusive PMSI, the set of BFERs (egress PEs) includes </t>
the originators of all IMET routes for a broadcast domain. For a selectiv <t>For an inclusive PMSI, the set of BFERs (egress PEs) includes
e the originators of all IMET routes for a BD. For a selective
PMSI, the set of BFERs (egress PEs) includes the originators PMSI, the set of BFERs (egress PEs) includes the originators
of corresponding SMET routes. of corresponding SMET routes.
</t> </t>
<t>The SMET routes do not carry a PTA. When an ingress <t>The SMET routes do not carry a PTA. When an ingress
PE sends traffic on a selective tunnel using BIER, it uses the upstream-a ssigned label that is advertised in its IMET route. PE sends traffic on a selective tunnel using BIER, it uses the upstream-a ssigned label that is advertised in its IMET route.
</t> </t>
<t>Only when selectively forwarding is for all flows and without tunnel <t>When only selective forwarding is used for all flows and without tu
nnel
segmentation, SMET routes are used without the need for S-PMSI A-D routes . segmentation, SMET routes are used without the need for S-PMSI A-D routes .
Otherwise, the procedures in the following section apply. Otherwise, the procedures in the following section apply.
</t> </t>
</section> </section>
<section title="Using S-PMSI/Leaf A-D Routes"> <section numbered="true" toc="default">
<t>There are two cases where S-PMSI/Leaf A-D routes are used as discussed <name>Using S-PMSI/Leaf A-D Routes</name>
<t>There are two cases where S-PMSI/Leaf A-D routes are used as discus
sed
in the following two sections. in the following two sections.
</t> </t>
<section title="Selective Forwarding Only for Some Flows"> <section numbered="true" toc="default">
<t>With the SMET procedure, a PE advertises an SMET route for each <name>Selective Forwarding Only for Some Flows</name>
<t>With the SMET procedure, a PE advertises a SMET route for each
(C-S, C-G) or (C-*, C-G) state that it learns on its Attachment Circuits ( ACs), and each SMET (C-S, C-G) or (C-*, C-G) state that it learns on its Attachment Circuits ( ACs), and each SMET
route is tracked by every PE in the same broadcast domain. It may be desir route is tracked by every PE in the same BD. It may be desired
ed that SMET routes are not used in order to reduce the burden of explicit tr
that SMET routes are not used, in order to reduce the burden of explicit t acking.
racking. </t>
</t> <t>In this case, most multicast traffic will follow the I-PMSI (adve
<t>In this case, most multicast traffic will follow the I-PMSI (advertised rtised
via IMET route) and only some flows follow S-PMSIs. To achieve that, via the IMET route) and only some flows will follow S-PMSIs. To achieve t
S-PMSI/Leaf A-D routes can be used, as specified in <xref hat,
target='I-D.ietf-bess-evpn-bum-procedure-updates'/>. S-PMSI/Leaf A-D routes can be used, as specified in <xref target="RFC9572
</t> " format="default"/>.
<t>The rules specified in Section 2.2.1 and Section 2.2.2 of </t>
<xref target='RFC8556'/> apply. <t>The rules specified in Sections <xref target="RFC8556" section="2
</t> .2.1" sectionFormat="bare" format="default"/> and <xref target="RFC8556" section
</section> ="2.2.2" sectionFormat="bare" format="default"/> of <xref target="RFC8556"/> app
<section title="Tunnel Segmentation"> ly.
<t>Another case where S-PMSI/Leaf A-D routes are necessary is tunnel </t>
segmentation, which is also specified in <xref </section>
target='I-D.ietf-bess-evpn-bum-procedure-updates'/>, and further <section numbered="true" toc="default">
<name>Tunnel Segmentation</name>
<t>Another case where S-PMSI/Leaf A-D routes are necessary is tunnel
segmentation, which is also specified in <xref target="RFC9572" format="d
efault"/> and further
clarified in clarified in
<xref target='I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements'/> for <xref target="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" format="defa ult"/> for
segmentation with SMET routes. This is only applicable to EVPN-MPLS. segmentation with SMET routes. This is only applicable to EVPN-MPLS.
</t> </t>
<t>The rules specified in Section 2.2.1 of <t>The rules specified in <xref target="RFC8556" section="2.2.1" sec
<xref target='RFC8556'/> apply. Section 2.2.2 of tionFormat="of" format="default"/> apply. <xref target="RFC8556" section="2.2.2"
<xref target='RFC8556'/> does not apply, because sectionFormat="of" format="default"/> does not apply, because
like in MVPN, the LIR-pF flag cannot be used with like in MVPN, the LIR-pF flag cannot be used with
segmentation. segmentation.
</t> </t>
</section> </section>
<section title="Applicability of Additional MVPN Specifications"> <section numbered="true" toc="default">
<t>As with the MVPN case, Section "3. Use of the PMSI Tunnel Attribute <name>Applicability of Additional MVPN Specifications</name>
in Leaf A-D routes" of <xref target='RFC8556'/> apply. <t>As with the MVPN case, "Use of the PMSI Tunnel Attribute
</t> in Leaf A-D Routes" (<xref target="RFC8556" format="default" sectionForma
<t>Notice that, <xref target='RFC8556'/> refers to procedures t="of" section="3"/>) applies.
specified in <xref target='RFC6625'/> and </t>
<xref target="RFC8534"/>. Those two documents <t>Notice that <xref target="RFC8556" format="default"/> refers to p
rocedures
specified in <xref target="RFC6625" format="default"/> and
<xref target="RFC8534" format="default"/>. Those two documents
were specified for MVPN but apply to IP multicast were specified for MVPN but apply to IP multicast
payload in EVPN as well. payload in EVPN as well.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section title="MPLS Label in PTA" anchor="label"> <section anchor="label" numbered="true" toc="default">
<t>Rules in section 2.1 of <xref target='RFC8556'/> apply, <name>MPLS Label in the PTA</name>
<t>Rules in <xref target="RFC8556" section="2.1" sectionFormat="of" form
at="default"/> apply,
EXCEPT the following three bullets (they do NOT apply to EVPN) in that EXCEPT the following three bullets (they do NOT apply to EVPN) in that
section: section:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
<t>
If the two routes do not have the same Address Family Identifier If the two routes do not have the same Address Family Identifier
(AFI) value, then their respective PTAs MUST contain different (AFI) value, then their respective PTAs <bcp14>MUST</bcp14> contain differ ent
MPLS label values. This ensures that when an egress PE receives a MPLS label values. This ensures that when an egress PE receives a
data packet with the given label, the egress PE can infer from the data packet with the given label, the egress PE can infer from the
label whether the payload is an IPv4 packet or an IPv6 packet. label whether the payload is an IPv4 packet or an IPv6 packet.
</t> </t>
<t> </li>
If the BFIR is an ingress PE supporting MVPN extranet (<xref target="RFC79 <li>
00"/>) <t>
If the BFIR is an ingress PE supporting MVPN extranet <xref target="RFC790
0" format="default"/>
functionality, and if the two routes originate from different VRFs functionality, and if the two routes originate from different VRFs
on this ingress PE, then the respective PTAs of the two routes on this ingress PE, then the respective PTAs of the two routes
MUST contain different MPLS label values. <bcp14>MUST</bcp14> contain different MPLS label values.
</t> </t>
<t> </li>
<li>
<t>
If the BFIR is an ingress PE supporting the "Extranet Separation" If the BFIR is an ingress PE supporting the "Extranet Separation"
feature of MVPN extranet (see Section 7.3 of <xref target="RFC7900"/>), an d if feature of MVPN extranet (see <xref target="RFC7900" section="7.3" section Format="of" format="default"/>), and if
one of the routes carries the "Extranet Separation" extended one of the routes carries the "Extranet Separation" extended
community but the other does not, then the respective PTAs of the community but the other does not, then the respective PTAs of the
two routes MUST contain different MPLS label values. two routes <bcp14>MUST</bcp14> contain different MPLS label values.
</t> </t>
</list> </li>
</t> </ul>
</section> </section>
</section> </section>
<section title="Multihoming Split Horizon" anchor="multihoming"> <section anchor="multihoming" numbered="true" toc="default">
<t>For EVPN-MPLS, <xref target="RFC7432"/> specifies the use of ESI labels t <name>Multihoming Split Horizon</name>
o identify <t>For EVPN-MPLS, <xref target="RFC7432" format="default"/> specifies the
use of ESI labels to identify
the ES from which a BUM packet originates. A PE receiving that packet the ES from which a BUM packet originates. A PE receiving that packet
from the core side will not forward it to the same ES. The procedure from the core side will not forward it to the same ES. The procedure
works for both Ingress Replication (IR) and RSVP-TE/mLDP P2MP tunnels, works for both Ingress Replication (IR) and RSVP-TE/mLDP P2MP tunnels,
using downstream- and upstream-assigned ESI labels respectively. For using downstream- and upstream-assigned ESI labels, respectively. For
EVPN-VXLAN/NVGRE/GENEVE, <xref target='RFC8365'/> specifies local bias EVPN-VXLAN/NVGRE/GENEVE, <xref target="RFC8365" format="default"/> specif
procedures, with which a PE receiving a BUM packet from the core ies local bias
side knows from encapsulation the ingress PE so it does not forward procedures, where a PE receiving a BUM packet from the core
the packet to any multihoming ESes that the ingress PE is on. This is side knows the ingress PE due to encapsulation; therefore, the PE
because the ingress PE already forwarded the packet to those ESes does not forward the packet to any multihoming ESes that the ingress PE i
s on. This is
because the ingress PE already forwarded the packet to those ESes,
regardless of whether the ingress PE is a Designated Forwarder for regardless of whether the ingress PE is a Designated Forwarder for
those ESes. those ESes.
</t> </t>
<t>With BIER, the local bias procedure still applies for EVPN-VXLAN/NVGRE/GE <t>With BIER, the local bias procedure still applies for EVPN-VXLAN/NVGRE/
NEVE GENEVE,
as the BFIR-id in the BIER header identifies the ingress PE. as the BFIR-id in the BIER header identifies the ingress PE.
For EVPN-MPLS, ESI label procedures also still apply though two upstream- For EVPN-MPLS, ESI label procedures also still apply, though two upstream
assigned labels will be used (one for identifying the broadcast domain -assigned labels will be used (one for identifying the BD
and one for identifying the ES) - the same as in the case of using and one for identifying the ES) -- the same as in the case of using
a single P2MP tunnel for multiple broadcast domains. The BFIR-id in a single P2MP tunnel for multiple BDs. The BFIR-id in
the BIER header identifies the ingress PE that assigned those the BIER header identifies the ingress PE that assigned those
two labels. two labels.
</t>
</section>
<!--section title = "Assisted Replication with BIER Composite Tunnel" anchor
="ar">
<t>With Assisted Replication (AR)
<xref target="I-D.ietf-bess-evpn-optimized-ir"/> (with IP tunnels)
an AR-leaf sends traffic to an AR-replicator via Ingress Replication (IR)
,
who will then relay the traffic to other AR-leaf and AR-replicators.
While the AR-replicator receives via IR the relay could be via BIER.
An AR-leaf may not support BIER in the forwarding path but it could still
advertise the support of BIER and rely on its upstream router to do
Penultimate Hop Popping as described in
<xref target="I-D.ietf-bier-php"/>.
To support that scenario, the procedures in
<xref target="I-D.ietf-bess-evpn-optimized-ir"/> are followed with the
following modifications:
<list style="symbols">
<t>AR-replicators must support BIER in forwarding.
It advertises a BIER tunnel in its IMET route with IR-IP as the
Originating Router's IP Address, and advertises an AR tunnel in its
IMET route with AR-IP as the Originating Router's IP Address.
</t>
<t>AR-leaves that can request BIER PHP advertise IMET route with a
BIER composite tunnel.
</t> </t>
<t>Traffic received by an AR-replicator with BIER encapsulation is not </section>
relayed. <section numbered="true" toc="default">
</t> <name>Data Plane</name>
<t>When there are Regular NVEs (RNVEs that only support the plain old <t>Like MVPN, the EVPN application plays the role of the "multicast
procedures in <xref target="RFC7432"/>), the AR-replicator will relay flow overlay" as described in <xref target="RFC8279" format="default"/>.
traffic from
RNVEs to AR-leaves that advertises BIER composite tunnel via BIER,
and relay traffic from AR-leaves to RNVEs via IR.
[question - do we need to elect an AR-replicator to relay traffic
from RNVEs?]
</t> </t>
</list> <section numbered="true" toc="default">
</t> <name>Encapsulation and Transmission</name>
<t>AR with MPLS tunnels, along with the usage of BIER composite tunnel, <t>A BFIR could be either an ingress PE or a P-tunnel segmentation point
are specified in <xref target="I-D.keyupate-bess-evpn-virtual-hub"/>. .
</t>
</section-->
<section title="Data Plane">
<t>Like MVPN, the EVPN application plays the role of the "multicast
flow overlay" as described in <xref target='RFC8279'/>.
</t>
<section title="Encapsulation and Transmission">
<t>A BFIR could be either an ingress PE or a P-tunnel segmentation point.
The procedures are slightly different as described below. The procedures are slightly different as described below.
</t> </t>
<section title="At a BFIR that is an Ingress PE" anchor="ingresspe"> <section anchor="ingresspe" numbered="true" toc="default">
<t>To transmit a BUM data packet, an ingress PE first determines the <name>At a BFIR That Is an Ingress PE</name>
<t>To transmit a BUM data packet, an ingress PE first determines the
route matched for transmission and routes for tracking leaves according route matched for transmission and routes for tracking leaves according
to the following rules. to the following rules.
<list style="numbers"> </t>
<t anchor="inclusive">If selective forwarding is not used, or it is not an I <ol spacing="normal" type="1"><li anchor="inclusive">
P Multicast packet <t>If selective forwarding is not used or is not an IP multicast p
acket
after the Ethernet header, the IMET route originated for the BD by the after the Ethernet header, the IMET route originated for the BD by the
ingress PE is the route matched for transmission. Leaf tracking routes ingress PE is the route matched for transmission. Leaf-tracking routes
are all other received IMET routes for the BD. are all other received IMET routes for the BD.
</t> </t>
<t>Otherwise, if selective forwarding is used for all IP Multicast traffic </li>
<li>
<t>Otherwise, if selective forwarding is used for all IP multicast
traffic
based on SMET routes, the IMET route originated for the BD by the ingress based on SMET routes, the IMET route originated for the BD by the ingress
PE is the route matched for transmission. Received SMET PE is the route matched for transmission. Received SMET
routes for the BD whose source and destination address fields match routes for the BD, whose source and destination address fields match
the packet's source and destination IP address the packet's source and destination IP address,
are leaf tracking routes. are leaf-tracking routes.
</t> </t>
<t>Otherwise, the route matched for transmission is the S-PMSI A-D route </li>
<li>
<t>Otherwise, the route matched for transmission is the S-PMSI A-D
route
originated by the ingress PE for the BD, originated by the ingress PE for the BD,
whose source and destination address fields match the packet's source and whose source and destination address fields match the packet's source and
destination IP address and has a PTA specifying a valid tunnel type that destination IP address and have a PTA specifying a valid tunnel type that
is not "no tunnel info". Leaf tracking routes are determined is not "no tunnel info". Leaf-tracking routes are determined
as follows: as follows:
<list style="format %d)"> </t>
<t>If the match for transmission route carries a PTA that has the LIR <ol spacing="normal" type="a"><li>
<t>If the match for the transmission route carries a PTA that
has the LIR
flag set but does not have the LIR-pF flag set, the routes matched fo r flag set but does not have the LIR-pF flag set, the routes matched fo r
tracking are Leaf A-D routes whose "route key" field is identical to tracking are Leaf A-D routes whose Route Key field is identical to
the NLRI of the S-PMSI A-D route. the NLRI of the S-PMSI A-D route.
</t> </t>
<t>If the match for transmission route carries a PTA that has the LIR-pF </li>
flag, the leaf tracking routes are Leaf A-D routes whose <li>
"route key" field is derived from the NLRI of the S-PMSI A-D <t>If the match for the transmission route carries a PTA that
route according to the procedures described in Section 5.2 of has the LIR-pF
<xref target="RFC8534"/>. flag, the leaf-tracking routes are Leaf A-D routes whose
</t> Route Key field is derived from the NLRI of the S-PMSI A-D
</list> route according to the procedures described in <xref target="RFC8534"
<vspace/> section="5.2" sectionFormat="of" format="default"/>.
<vspace/> </t>
</li>
</ol>
<t>
Note that in both cases, SMET routes may be used in lieu of Note that in both cases, SMET routes may be used in lieu of
Leaf A-D routes, as a PE may omit the Leaf A-D route in response to Leaf A-D routes, as a PE may omit the Leaf A-D route in response to
an S-PMSI A-D route with LIR or LIR-pF bit set, if an SMET route an S-PMSI A-D route with the LIR or LIR-pF bit set if a SMET route
with the corresponding Tag, Source, and Group fields is already with the corresponding Tag, Source, and Group fields is already
originated <xref target='I-D.ietf-bess-evpn-bum-procedure-updates'/>. originated <xref target="RFC9572" format="default"/>.
In particular, in the second case above, even though the SMET route In particular, in the second case above, even though the SMET route
does not have a PTA attached, it is still considered a Leaf A-D does not have a PTA attached, it is still considered a Leaf A-D
route in response to a wildcard S-PMSI A-D route with the LIR-pF bit route in response to a wildcard S-PMSI A-D route with the LIR-pF bit
set. set.
</t> </t>
<t>Otherwise, the route matched for transmission and leaf tracking routes ar </li>
e <li>
<t>Otherwise, the route matched for transmission and leaf-tracking
routes are
determined as in rule <xref target="inclusive" format="counter"/>. determined as in rule <xref target="inclusive" format="counter"/>.
</t> </t>
</list> </li>
</t> </ol>
<t>If no route is matched for transmission, the packet is not forwarded <t>If no route is matched for transmission, the packet is not forwarde
d
onto a P-tunnel. If the tunnel that the ingress determines to use onto a P-tunnel. If the tunnel that the ingress determines to use
based on the route matched for transmission (and considering based on the route matched for transmission (and considering
interworking with PEs that do not support certain tunnel types interworking with PEs that do not support certain tunnel types
per procedures in <xref target="RFC9251"/>) per procedures in <xref target="RFC9251" format="default"/>)
requires leaf tracking (e.g. Ingress Replication, RSVP-TE P2MP tunnel, requires leaf tracking (e.g., Ingress Replication, RSVP-TE P2MP tunnel,
or BIER) but there are no leaf tracking routes, or BIER) but there are no leaf-tracking routes,
the packet will not be forwarded onto a P-tunnel either. the packet will not be forwarded onto a P-tunnel either.
</t> </t>
<t>The following text assumes that BIER is the determined tunnel type. <t>The following text assumes that BIER is the determined tunnel type.
The ingress PE pushes an upstream-assigned ESI label per <xref target="RF The ingress PE pushes an upstream-assigned ESI label per <xref target="RF
C7432"/> C7432" format="default"/>
if the following conditions are all met: if the following conditions are all met:
<list style="symbols"> </t>
<t>The packet is received on a multihomed ES. <ul spacing="normal">
</t> <li>
<t>It's EVPN-MPLS. <t>The packet is received on a multihomed ES.
</t> </t>
<t>ESI label procedure is used for split-horizon. </li>
</t> <li>
</list> <t>It is EVPN-MPLS.
</t> </t>
<t>The MPLS label from the PTA of the route matched </li>
<li>
<t>The ESI label procedure is used for split horizon.
</t>
</li>
</ul>
<t>The MPLS label from the PTA of the route matched
for transmission is then pushed onto the packet's label stack for for transmission is then pushed onto the packet's label stack for
EVPN-MPLS. For EVPN-VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is pr epended to EVPN-MPLS. For EVPN-VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is pr epended to
the packet with the VNI/VSID set to the value in the PTA's label field, the packet with the VNI/VSID set to the value in the PTA's Label field,
and then an IP/UDP header is prepended if needed (e.g. for PHP purpose). and then an IP/UDP header is prepended if needed (e.g., for PHP purposes)
</t> .
<t>Then the packet is encapsulated in a BIER </t>
header and forwarded, according to the procedures of <t>Then, the packet is encapsulated in a BIER
<xref target='RFC8279'/> and <xref target='RFC8296'/>. header and forwarded according to the procedures of
See especially Section 4, "Imposing and Processing <xref target="RFC8279" format="default"/> and <xref target="RFC8296" form
the BIER Encapsulation", of <xref target='RFC8296'/>. at="default"/>.
The "Proto" field in the BIER header is set to 2 in the case of EVPN-MPLS Specifically, see "Imposing and Processing
, the BIER Encapsulation" (<xref target="RFC8296" format="default" sectionF
or a value to be assigned in the case of EVPN-VXLAN/NVGRE/GENEVE (<xref ormat="of" section="3"/>).
target="IANA"/>) when an IP header is not used, or 4/6 if an IP header is The Proto field in the BIER header is set to 2 in the case of EVPN-MPLS,
used 7/8/9 in the case of EVPN-VXLAN/NVGRE/GENEVE (<xref target="IANA" format=
"default"/>) when an IP header is not used, or 4/6 if an IP header is used
for EVPN-VXLAN/NVGRE/GENEVE. for EVPN-VXLAN/NVGRE/GENEVE.
</t> </t>
<t>To create the proper BIER header for a given packet, the <t>To create the proper BIER header for a given packet, the
BFIR must know all the BFERs that need to receive that packet. BFIR must know all the BFERs that need to receive that packet.
This is determined from the set of leaf tracking routes. This is determined from the set of leaf-tracking routes.
</t> </t>
</section> </section>
<section title="At a BFIR that is a P-tunnel Segmentation Point"> <section numbered="true" toc="default">
<t>In this case, the encapsulation for the upstream segment of the P-tunnel <name>At a BFIR That Is a P-Tunnel Segmentation Point</name>
<t>In this case, the encapsulation for the upstream segment of the P-t
unnel
includes (among other things) a label that identifies the x-PMSI or includes (among other things) a label that identifies the x-PMSI or
IMET A-D route that IMET A-D route that
is the match for reception on the upstream segment. The segmentation poin t is the match for reception on the upstream segment. The segmentation poin t
re-advertised the route into one or more downstream regions. Each re-advertised the route into one or more downstream regions. Each
instance of the re-advertised route for a downstream region has a PTA instance of the re-advertised route for a downstream region has a PTA
that specifies the tunnel for that region. For any particular downstream that specifies the tunnel for that region. For any particular downstream
region, the route matched for transmission is the re-advertised route region, the route matched for transmission is the re-advertised route,
and the leaf tracking routes are determined as follows if needed and the leaf-tracking routes are determined as follows, if needed,
for the tunnel type: for the tunnel type:
<list style="symbols"> </t>
<t>If the route matched for transmission is an x-PMSI route, it must have <ul spacing="normal">
the LIR flag set in its PTA and the leaf tracking routes are all the <li>
<t>If the route matched for transmission is an x-PMSI route, it mu
st have
the LIR flag set in its PTA, and the leaf-tracking routes are all the
matching Leaf A-D and SMET routes received in the downstream region. matching Leaf A-D and SMET routes received in the downstream region.
</t> </t>
<t>If the route matched for transmission is an IMET route, the leaf tracking </li>
<li>
<t>If the route matched for transmission is an IMET route, the lea
f-tracking
routes are all the IMET routes for the same BD received in the downstream routes are all the IMET routes for the same BD received in the downstream
region. region.
</t> </t>
</list> </li>
</t> </ul>
<t>If the downstream region uses BIER, the packet is forwarded as follows: <t>If the downstream region uses BIER, the packet is forwarded as foll
ows:
the upstream segmentation's encapsulation is removed and the the upstream segmentation's encapsulation is removed and the
above-mentioned label is swapped to the above-mentioned label is swapped to the
upstream-assigned label in the PTA of the route matched for transmission, upstream-assigned label in the PTA of the route matched for transmission,
and then a BIER header is imposed as in <xref target="ingresspe"/>. and then a BIER header is imposed as in <xref target="ingresspe" format="
</t> default"/>.
</section> </t>
</section> </section>
<section title="Disposition"> </section>
<t>The same procedures in section 4.2 of <xref target='RFC8556'/> <section numbered="true" toc="default">
are followed for EVPN-MPLS, except some EVPN specifics discussed in <name>Disposition</name>
the following two sub-sections in this document. <t>The same procedures in <xref target="RFC8556" section="4.2" sectionFo
</t> rmat="of" format="default"/>
<t>For EVPN-VXLAN/NVGRE/GENEVE, the only difference is that the payload is are followed for EVPN-MPLS, except for some EVPN specifics that are discu
ssed in
the following two subsections of this document.
</t>
<t>For EVPN-VXLAN/NVGRE/GENEVE, the only differences are that the payloa
d is
VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID
field in the VXLAN/NVGRE/GENEVE header is used to determine the correspon ding field in the VXLAN/NVGRE/GENEVE header is used to determine the correspon ding
broadcast domain. BD.
</t> </t>
<section title="At a BFER that is an Egress PE"> <section numbered="true" toc="default">
<t>Once the corresponding broadcast domain is determined from <name>At a BFER That Is an Egress PE</name>
<t>Once the corresponding BD is determined from
the upstream-assigned label or VNI/VSID, EVPN forwarding procedures per the upstream-assigned label or VNI/VSID, EVPN forwarding procedures per
<xref target="RFC7432"/> or <xref target='RFC8365'/> are followed. <xref target="RFC7432" format="default"/> or <xref target="RFC8365" forma t="default"/> are followed.
In the case of EVPN-MPLS, if there is an inner label in the label stack In the case of EVPN-MPLS, if there is an inner label in the label stack
following the BIER header, that inner label is considered the following the BIER header, that inner label is considered the
upstream-assigned ESI label for split horizon purpose. upstream-assigned ESI label for split-horizon purposes.
</t>
</section>
<section title="At a BFER that is a P-tunnel Segmentation Point">
<t>This is only applicable to EVPN-MPLS. The same procedures in
Section 4.2.2 of <xref target='RFC8556'/> are followed,
subject to multihoming procedures specified in
<xref target='I-D.ietf-bess-evpn-bum-procedure-updates'/>.
</t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests three assignments in
"BIER Next Protocol Identifiers" registry, with the following three
recommended values:
<list style="symbols">
<t>7: Payload is VXLAN encapsulated (no IP/UDP header)
</t>
<t>8: Payload is NVGRE encapsulated (no IP header)
</t> </t>
<t>9: Payload is GENEVE encapsulated (no IP/UDP header) </section>
<section numbered="true" toc="default">
<name>At a BFER That Is a P-Tunnel Segmentation Point</name>
<t>This is only applicable to EVPN-MPLS. The same procedures in
<xref target="RFC8556" section="4.2.2" sectionFormat="of" format="default
"/> are followed,
subject to multihoming procedures specified in
<xref target="RFC9572" format="default"/>.
</t> </t>
</list> </section>
</t> </section>
<t>This document requests assignments of an IPv4 and an IPv6 multicast </section>
address for the case discussed in <xref target="php-address"/>. <section anchor="IANA" numbered="true" toc="default">
Preferably this is assigned from the Local Network Control Block <name>IANA Considerations</name>
(224.0.0/24) for IPv4 and Link-Local Scope Multicast Addresses <t>Per this document, IANA has registered the following three values in th
for IPv6. The description is "NVO BUM Traffic". e
"BIER Next Protocol Identifiers" registry:
</t> </t>
<table align="center">
<name>BIER Next Protocol Identifiers Registry</name>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>7</td>
<td>Payload is VXLAN encapsulated (no IP/UDP header)</td>
<td>RFC 9624</td>
</tr>
<tr>
<td>8</td>
<td>Payload is NVGRE encapsulated (no IP header)</td>
<td>RFC 9624</td>
</tr>
<tr>
<td>9</td>
<td>Payload is GENEVE encapsulated (no IP/UDP header)</td>
<td>RFC 9624</td>
</tr>
</tbody>
</table>
<t>IANA has also assigned an IPv4 and an IPv6 multicast
address for the case discussed in <xref target="php-address" format="defau
lt"/>.</t>
<t>
The following entry has been added to the "Local Network Control Block (22
4.0.0.0 - 224.0.0.255 (224.0.0/24))" registry for IPv4:</t>
<dl spacing="compact">
<dt>Address(es):</dt><dd> 224.0.0.122</dd>
<dt>Description:</dt><dd> Network Virtualization Overlay (NVO) BUM Traffic
</dd>
<dt>Reference:</dt><dd> RFC 9624</dd>
</dl>
<t>
The following entry has been added to the "Link-Local Scope Multicast Addresses"
registry for IPv6:</t>
<dl spacing="compact">
<dt>Address(es):</dt><dd>FF02:0:0:0:0:0:0:14</dd>
<dt>Description:</dt><dd> Network Virtualization Overlay (NVO) BUM Traffic
</dd>
<dt>Reference:</dt><dd> RFC 9624</dd>
</dl>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>This document is about using BIER as provider tunnels for EVPN. <t>This document is about using BIER as provider tunnels for EVPN.
It is very similar to using BIER as MVPN provider tunnel, and It is very similar to using BIER as MVPN provider tunnels and
does not introduce additional security implications does not introduce additional security implications
beyond what have been discussed in EVPN base protocol specification beyond what have been discussed in the EVPN base protocol specification
<xref target="RFC7432"/> and MVPN using BIER <xref target="RFC8556"/>. <xref target="RFC7432" format="default"/> and MVPN using BIER <xref tar
</t> get="RFC8556" format="default"/>.
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors thank Eric Rosen for his review and suggestions.
Additionally, much of the text is borrowed verbatim from
<xref target='RFC8556'/>.
</t> </t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" to=
<?rfc include='reference.RFC.2119.xml'?> "CMCAST-ENHANCEMENTS"/>
<?rfc include='reference.RFC.8174.xml'?> <displayreference target="I-D.ietf-bier-php" to="BIER-PHP"/>
<?rfc include='reference.RFC.7900.xml'?> <references>
<?rfc include='reference.RFC.6625.xml'?> <name>References</name>
<?rfc include='reference.RFC.7432.xml'?> <references>
<?rfc include='reference.RFC.8279.xml'?> <name>Normative References</name>
<?rfc include='reference.RFC.8296.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.8556.xml'?> 119.xml"/>
<?rfc include='reference.RFC.8534.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.9251.xml'?> 174.xml"/>
<?rfc include='reference.RFC.8365.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.RFC.8926.xml'?> 900.xml"/>
<?rfc include='reference.RFC.6513.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.6514.xml'?> 625.xml"/>
<?rfc include='reference.I-D.ietf-bess-evpn-bum-procedure-updates.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</references> 432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
279.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
296.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
556.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
534.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
251.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
365.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
926.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
513.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
514.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
72.xml"/>
<references title="Informative References"> </references>
<?rfc include='reference.I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements.xml <references>
'?> <name>Informative References</name>
<?rfc include='reference.I-D.ietf-bier-php.xml'?>
<?rfc include='reference.RFC.7348.xml'?> <reference anchor="I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements" target="https:
<?rfc include='reference.RFC.7637.xml'?> //datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-
<?rfc include='reference.RFC.4875.xml'?> 04">
<?rfc include='reference.RFC.6388.xml'?> <front>
<title>MVPN/EVPN C-Multicast Routes Enhancements</title>
<author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
<organization>Juniper Networks</organization>
</author>
<author initials="R." surname="Kebler" fullname="Robert Kebler">
<organization>Juniper Networks</organization>
</author>
<author initials="W." surname="Lin" fullname="Wen Lin">
<organization>Juniper Networks</organization>
</author>
<author initials="E." surname="Rosen" fullname="Eric C. Rosen"> </author>
<date month="March" day="17" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-zzhang-bess-mvpn-evpn-cmcast-enha
ncements-04"/>
</reference>
<reference anchor="I-D.ietf-bier-php" target="https://datatracker.ietf.org/doc/h
tml/draft-ietf-bier-php-11">
<front>
<title>BIER Penultimate Hop Popping</title>
<author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
<organization>Juniper Networks</organization>
</author>
<date month="February" day="6" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bier-php-11"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
348.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
637.xml"/>
<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.6
388.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors thank <contact fullname="Eric Rosen"/> for his review and s
uggestions.
Additionally, much of the text is borrowed verbatim from
<xref target="RFC8556" format="default"/>.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 104 change blocks. 
546 lines changed or deleted 644 lines changed or added

This html diff was produced by rfcdiff 1.48.