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 " "> | ||||
<!ENTITY zwsp "​"> | ||||
<!ENTITY nbhy "‑"> | ||||
<!ENTITY wj "⁠"> | ||||
]> | ]> | |||
<?rfc toc="yes"?> | ||||
<?rfc tocompact="yes"?> | ||||
<?rfc tocdepth="3"?> | ||||
<?rfc tocindent="yes"?> | ||||
<?rfc symrefs="yes"?> | ||||
<?rfc sortrefs="yes"?> | ||||
<?rfc strict="no"?> | ||||
<?rfc rfcedstyle="yes"?> | ||||
<?rfc comments="yes"?> | ||||
<?rfc inline="yes"?> | ||||
<?rfc compact="yes"?> | ||||
<?rfc subcompact="no"?> | ||||
<rfc 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="July" 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 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. |