rfc9625xml2.original.xml | rfc9625.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="US-ASCII"?> | <?xml version='1.0' encoding='UTF-8'?> | |||
<!-- $Id: draft-ietf-bess-evpn-irb-mcast.xml,v 1.4 2020/12/23 19:26:29 zzhang | <!DOCTYPE rfc [ | |||
Exp $ --> | <!ENTITY nbsp " "> | |||
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ | <!ENTITY zwsp "​"> | |||
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | <!ENTITY nbhy "‑"> | |||
C.2119.xml"> | <!ENTITY wj "⁠"> | |||
<!ENTITY RFC3376 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.3376.xml"> | ||||
<!ENTITY RFC3810 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.3810.xml"> | ||||
<!ENTITY RFC4541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.4541.xml"> | ||||
<!ENTITY RFC3032 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.3032.xml"> | ||||
<!ENTITY RFC4360 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.4360.xml"> | ||||
<!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.4364.xml"> | ||||
<!ENTITY RFC6513 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.6513.xml"> | ||||
<!ENTITY RFC6514 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.6514.xml"> | ||||
<!ENTITY RFC6625 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.6625.xml"> | ||||
<!ENTITY RFC7153 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7153.xml"> | ||||
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7432.xml"> | ||||
<!ENTITY RFC7606 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7606.xml"> | ||||
<!ENTITY RFC7716 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7716.xml"> | ||||
<!ENTITY RFC7761 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7761.xml"> | ||||
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8174.xml"> | ||||
<!ENTITY RFC8296 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8296.xml"> | ||||
<!ENTITY RFC8584 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8584.xml"> | ||||
<!ENTITY RFC9135 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9135.xml"> | ||||
<!ENTITY RFC9136 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9136.xml"> | ||||
<!ENTITY RFC9251 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9251.xml"> | ||||
]> | ]> | |||
<?rfc toc="yes"?> | ||||
<?rfc tocompact="yes"?> | ||||
<?rfc tocdepth="6"?> | ||||
<?rfc tocindent="yes"?> | ||||
<?rfc symrefs="yes"?> | ||||
<?rfc sortrefs="yes"?> | ||||
<?rfc strict="no"?> | ||||
<?rfc rfcedstyle="yes"?> | ||||
<?rfc inline="yes"?> | ||||
<?rfc compact="yes"?> | ||||
<?rfc subcompact="no"?> | ||||
<?rfc comments="no"?> | ||||
<rfc category="std" docName="draft-ietf-bess-evpn-irb-mcast-11" ipr="trust200902 | ||||
"> | ||||
<front> | ||||
<title abbrev="evpn-irb-mcast">EVPN Optimized Inter-Subnet Multicast (OISM) | ||||
Forwarding</title> | ||||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie | ||||
tf-bess-evpn-irb-mcast-11" number="9625" consensus="true" ipr="trust200902" obso | ||||
letes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDep | ||||
th="6" symRefs="true" sortRefs="true" version="3"> | ||||
<front> | ||||
<title abbrev="EVPN OISM Forwarding">EVPN Optimized Inter-Subnet Multicast ( | ||||
OISM) Forwarding</title> | ||||
<seriesInfo name="RFC" value="9625"/> | ||||
<author fullname="Wen Lin" initials="W." surname="Lin"> | <author fullname="Wen Lin" initials="W." surname="Lin"> | |||
<organization>Juniper Networks, Inc.</organization> | <organization>Juniper Networks, Inc.</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>10 Technology Park Drive</street> | <street>10 Technology Park Drive</street> | |||
<city>Westford</city> | <city>Westford</city> | |||
<region>Massachusetts</region> | <region>MA</region> | |||
<code>01886</code> | <code>01886</code> | |||
<country>United States</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>wlin@juniper.net</email> | <email>wlin@juniper.net</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> | <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> | |||
<organization>Juniper Networks, Inc.</organization> | <organization>Juniper Networks, Inc.</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>10 Technology Park Drive</street> | <street>10 Technology Park Drive</street> | |||
<city>Westford</city> | <city>Westford</city> | |||
<region>Massachusetts</region> | <region>MA</region> | |||
<code>01886</code> | <code>01886</code> | |||
<country>United States</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>zzhang@juniper.net</email> | <email>zzhang@juniper.net</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="John Drake" initials="J." surname="Drake"> | <author fullname="John Drake" initials="J." surname="Drake"> | |||
<organization>Juniper Networks, Inc.</organization> | <organization>Juniper Networks, Inc.</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>1194 N. Mathilda Ave</street> | <street>1194 N. Mathilda Ave</street> | |||
<city>Sunnyvale</city> | <city>Sunnyvale</city> | |||
<region>CA</region> | <region>CA</region> | |||
<code>94089</code> | <code>94089</code> | |||
<country>United States</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>jdrake@juniper.net</email> | <email>jdrake@juniper.net</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Eric C. Rosen" initials="E." surname="Rosen" role="editor" | ||||
<author fullname="Eric C. Rosen" initials="E." surname="Rosen" | > | |||
role="editor"> | ||||
<organization>Juniper Networks, Inc.</organization> | <organization>Juniper Networks, Inc.</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>10 Technology Park Drive</street> | <street>10 Technology Park Drive</street> | |||
<city>Westford</city> | <city>Westford</city> | |||
<region>Massachusetts</region> | <region>MA</region> | |||
<code>01886</code> | <code>01886</code> | |||
<country>United States</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email> erosen52@gmail.com</email> | <email>erosen52@gmail.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> | |||
<postal> | <postal> | |||
<street>777 E. Middlefield Road</street> | <street>777 E. Middlefield Road</street> | |||
<city>Mountain View</city> | <city>Mountain View</city> | |||
<region>CA</region> | <region>CA</region> | |||
<code>94043</code> | <code>94043</code> | |||
<country>United States</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>jorge.rabadan@nokia.com</email> | <email>jorge.rabadan@nokia.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Ali Sajassi" initials="A." surname="Sajassi"> | <author fullname="Ali Sajassi" initials="A." surname="Sajassi"> | |||
<organization>Cisco Systems</organization> | <organization>Cisco Systems</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>170 West Tasman Drive</street> | <street>170 West Tasman Drive</street> | |||
<city>San Jose</city> | <city>San Jose</city> | |||
<region>CA</region> | <region>CA</region> | |||
<code>95134</code> | <code>95134</code> | |||
<country>United States</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>sajassi@cisco.com</email> | <email>sajassi@cisco.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date month="August" year="2024"/> | ||||
<workgroup>BESS</workgroup> | <area>RTG</area> | |||
<workgroup>bess</workgroup> | ||||
<keyword>OISM</keyword> | ||||
<keyword>PEG</keyword> | ||||
<keyword>MEG</keyword> | ||||
<keyword>SBD</keyword> | ||||
<abstract> | <abstract> | |||
<t> | <t> | |||
Ethernet VPN (EVPN) provides a service that allows a single Local | Ethernet VPN (EVPN) provides a service that allows a single Local | |||
Area Network (LAN), comprising a single IP subnet, to be divided | Area Network (LAN), comprising a single IP subnet, to be divided | |||
into multiple "segments". Each segment may be located at a | into multiple segments. Each segment may be located at a | |||
different site, and the segments are interconnected by an IP or MPLS | different site, and the segments are interconnected by an IP or MPLS | |||
backbone. Intra-subnet traffic (either unicast or multicast) always | backbone. Intra-subnet traffic (either unicast or multicast) always | |||
appears to the end users to be bridged, even when it is actually | appears to the end users to be bridged, even when it is actually | |||
carried over the IP or MPLS backbone. When a single "tenant" owns | carried over the IP or MPLS backbone. When a single tenant owns | |||
multiple such LANs, EVPN also allows IP unicast traffic to be routed | multiple such LANs, EVPN also allows IP unicast traffic to be routed | |||
between those LANs. This document specifies new procedures that | between those LANs. This document specifies new procedures that | |||
allow inter-subnet IP multicast traffic to be routed among the LANs | allow inter-subnet IP multicast traffic to be routed among the LANs | |||
of a given tenant, while still making intra-subnet IP multicast | of a given tenant while still making intra-subnet IP multicast | |||
traffic appear to be bridged. These procedures can provide optimal | traffic appear to be bridged. These procedures can provide optimal | |||
routing of the inter-subnet multicast traffic, and do not require | routing of the inter-subnet multicast traffic and do not require | |||
any such traffic to egress a given router and then ingress that same | any such traffic to egress a given router and then ingress that same | |||
router. These procedures also accommodate IP multicast traffic that | router. These procedures also accommodate IP multicast traffic that | |||
originates or is destined external to the EVPN domain. | originates or is destined to be external to the EVPN domain. | |||
</t> | </t> | |||
</abstract> | </abstract> | |||
<note title="Requirements Language"> | ||||
<t> | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | ||||
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", | ||||
"MAY", and "OPTIONAL" in this document are to be interpreted as | ||||
described in BCP 14 <xref target="RFC2119"/> <xref | ||||
target="RFC8174"/> when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
</t> | ||||
</note> | ||||
</front> | </front> | |||
<middle> | <middle> | |||
<section title="Introduction" anchor="introduction"> | <section anchor="introduction" numbered="true" toc="default"> | |||
<section title="Terminology" anchor="terminology"> | <name>Introduction</name> | |||
<t> | <section anchor="terminology" numbered="true" toc="default"> | |||
In this document we make frequent use of the following terminology: | <name>Terminology</name> | |||
<list style="symbols"> | <t> | |||
<t> | In this document, we make frequent use of the following terminology: | |||
OISM: Optimized Inter-Subnet Multicast. EVPN&nbhy;PEs that | </t> | |||
<dl newline="false" spacing="normal"> | ||||
<dt>OISM:</dt> <dd>Optimized Inter-Subnet Multicast. EVPN PEs that | ||||
follow the procedures of this document will be known as "OISM" | follow the procedures of this document will be known as "OISM" | |||
PEs. EVPN&nbhy;PEs that do not follow the procedures of this | Provider Edges (PEs). EVPN PEs that do not follow the procedures of | |||
document will be known as "non&nbhy;OISM" PEs. | this | |||
</t> | document will be known as "non-OISM" PEs. | |||
<t> | </dd> | |||
IP Multicast Packet: An IP packet whose IP Destination Address | <dt>IP Multicast Packet:</dt> <dd>An IP packet whose IP Destination | |||
field is a multicast address that is not a link&nbhy;local | Address | |||
address. (Link&nbhy;local addresses are IPv4 addresses in the | field is a multicast address that is not a link-local | |||
224/24 range and IPv6 address in the FF02/16 range.) | address. (Link-local addresses are IPv4 addresses in the | |||
</t> | 224/24 range and IPv6 addresses in the FF02/16 range.) | |||
<t> | </dd> | |||
IP Multicast Frame: An Ethernet frame whose payload is an IP | <dt>IP Multicast Frame:</dt> <dd>An Ethernet frame whose payload is | |||
an IP | ||||
multicast packet (as defined above). | multicast packet (as defined above). | |||
</t> | </dd> | |||
<t> | <dt>(S,G) Multicast Packet:</dt> <dd>An IP multicast packet whose So | |||
(S,G) Multicast Packet: An IP multicast packet whose IP Source | urce IP Address field contains S and whose IP Destination Address field contains | |||
Address field contains S and whose IP Destination Address field | G. | |||
contains G. | </dd> | |||
</t> | <dt>(S,G) Multicast Frame:</dt> <dd>An IP multicast frame whose payl | |||
<t> | oad | |||
(S,G) Multicast Frame: An IP multicast frame whose payload | contains S in its Source IP Address field and G in its IP | |||
contains S in its IP Source Address field and G in its IP | ||||
Destination Address field. | Destination Address field. | |||
</t> | </dd> | |||
<t> | <dt>EVI:</dt> <dd>EVPN Instance. An EVPN instance spanning the | |||
EVPN Instance (EVI): An EVPN instance spanning the Provid | PE devices participating in that EVPN. | |||
er Edge | </dd> | |||
(PE) devices participating in that EVPN. | <dt>BD:</dt> <dd><t>Broadcast Domain. An emulated Ethernet, such tha | |||
</t> | t two | |||
<t> | systems on the same BD will receive each other's link-local | |||
Broadcast Domain (BD): an emulated Ethernet, such that two | broadcasts.</t> | |||
systems on the same BD will receive each other's link&nbhy;local | <t> | |||
broadcasts. | Note that EVPN supports service models in which a single EVI | |||
<vspace/> | contains only one BD and service models in which | |||
<vspace/> | a single EVI contains multiple BDs. Both types of service models | |||
Note that EVPN supports service models in which a single EVPN | are supported by this document. In all models, a given BD belongs | |||
Instance contains only one BD, and service models in which | ||||
a single EVI contains multiple BDs. Both types of service model | ||||
are supported by this draft. In all models, a given BD belongs | ||||
to only one EVI. | to only one EVI. | |||
</t> | </t> | |||
<t> | </dd> | |||
Designated Forwarder (DF). As defined in <xref | <dt>DF:</dt> <dd><t>Designated Forwarder. As defined in <xref target | |||
target="RFC7432"/>, an Ethernet segment may be multi&nbhy;homed | ="RFC7432" format="default"/>, an Ethernet segment may be multihomed | |||
(attached to more than one PE). An Ethernet segment may also | (attached to more than one PE). An Ethernet segment may also | |||
contain multiple BDs, of one or more EVIs. For each such EVI, | contain multiple BDs of one or more EVIs. For each such EVI, | |||
one of the PEs attached to the segment becomes that EVI's DF for | one of the PEs attached to the segment becomes that EVI's DF for | |||
that segment. Since a BD may belong to only one EVI, we can | that segment. Since a BD may belong to only one EVI, we can | |||
speak unambiguously of the BD's DF for a given segment. | speak unambiguously of the BD's DF for a given segment. | |||
<vspace/> | ||||
<vspace/> | ||||
When the text makes it clear that we are speaking in the context | ||||
of a given BD, we will frequently use the term "a segment's | ||||
DF" to mean the given BD's DF for that segment. | ||||
</t> | </t> | |||
<t> | </dd> | |||
AC: Attachment Circuit. An AC connects the bridging function of | <dt>AC:</dt> <dd><t>Attachment Circuit. An AC connects the bridging | |||
an EVPN&nbhy;PE to an Ethernet segment of a particular BD. ACs | function of | |||
are not visible at the router (L3) layer. | an EVPN PE to an Ethernet segment of a particular BD. ACs | |||
<vspace/> | are not visible at the Layer 3. | |||
<vspace/> | </t> | |||
<t> | ||||
If a given Ethernet segment, attached to a given PE, contains n | If a given Ethernet segment, attached to a given PE, contains n | |||
BDs, we will say that the PE has n ACs to that segment. | BDs, we say that the PE has n ACs to that segment. | |||
</t> | </t> | |||
<t> | </dd> | |||
L3 Gateway: An L3 Gateway is a PE that connects an EVPN tenant | <dt>L3 Gateway:</dt> <dd>An L3 Gateway is a PE that connects an EVPN | |||
domain to an external multicast domain by performing both the | Tenant | |||
Domain to an external multicast domain by performing both the | ||||
OISM procedures and the Layer 3 multicast procedures of the | OISM procedures and the Layer 3 multicast procedures of the | |||
external domain. | external domain. | |||
</t> | </dd> | |||
<t> | <dt>PEG:</dt> <dd>PIM/EVPN Gateway. An L3 Gateway that connects an E | |||
PEG (PIM/EVPN Gateway): A L3 Gateway that connects an EVPN | VPN | |||
Tenant Domain to an external multicast domain whose Layer 3 | Tenant Domain to an external multicast domain whose Layer 3 | |||
multicast procedures are those of PIM <xref | multicast procedures are those of PIM <xref target="RFC7761" format= | |||
target="RFC7761"/>. | "default"/>. | |||
</t> | </dd> | |||
<t> | <dt>MEG:</dt> <dd>MVPN/EVPN Gateway. An L3 Gateway that connects an | |||
MEG (MVPN/EVPN Gateway): A L3 Gateway that connects an EVPN | EVPN | |||
Tenant Domain to an external multicast domain whose Layer 3 | Tenant Domain to an external multicast domain whose Layer 3 | |||
multicast procedures are those of MVPN (<xref | multicast procedures are those of Multicast VPN (MVPN) <xref target= | |||
target="RFC6513"/>, <xref target="RFC6514"/>). | "RFC6513" format="default"/> <xref target="RFC6514" format="default"/>. | |||
</t> | </dd> | |||
<t> | <dt>IPMG:</dt> <dd>IP Multicast Gateway. A PE that is used for inter | |||
IPMG (IP Multicast Gateway): A PE that is used for interworking | working | |||
OISM EVPN&nbhy;PEs with non&nbhy;OISM EVPN&nbhy;PEs. | OISM EVPN PEs with non-OISM EVPN PEs. | |||
</t> | </dd> | |||
<t> | <dt>DR:</dt> <dd>Designated Router. A PE that has special responsibi | |||
DR (Designated Router): A PE that has special responsibilities | lities | |||
for handling multicast on a given BD. | for handling multicast on a given BD. | |||
</t> | </dd> | |||
<t> | <dt>FHR:</dt> <dd>First Hop Router. The FHR is a PIM router <xref ta | |||
FHR (First Hop Router): The FHR is a PIM router <xref | rget="RFC7761" format="default"/> with special responsibilities. It is the | |||
target="RFC7761"/> with special responsibilities. It is the | ||||
first multicast router to see (S,G) packets from source S, and | first multicast router to see (S,G) packets from source S, and | |||
if G is an "Any Source Multicast (ASM)" group, the FHR is | if G is an Any-Source Multicast (ASM) group, the FHR is | |||
responsible for sending PIM Register messages to the PIM | responsible for sending PIM Register messages to the PIM | |||
Rendezvous Point for group G. | Rendezvous Point (RP) for group G. | |||
</t> | </dd> | |||
<t> | <dt>LHR:</dt> <dd>Last Hop Router. The LHR is a PIM router <xref tar | |||
LHR (Last Hop Router): The LHR is a PIM router <xref | get="RFC7761" format="default"/> with special responsibilities. Generally, it | |||
target="RFC7761"/> with special responsibilities. Generally, it | ||||
is attached to a LAN, and it determines whether there are any | is attached to a LAN, and it determines whether there are any | |||
hosts on the LAN that need to receive a given multicast flow. | hosts on the LAN that need to receive a given multicast flow. | |||
If so, it creates and sends the PIM Join messages that are | If so, it creates and sends the PIM Join messages that are | |||
necessary to receive the flow. | necessary to receive the flow. | |||
</t> | </dd> | |||
<t> | <dt>EC:</dt> <dd>Extended Community. A BGP Extended Communities att | |||
EC (Extended Community). A BGP Extended Communities attribute | ribute | |||
(<xref target="RFC4360"/>, <xref target="RFC7153"/>) is a BGP | <xref target="RFC4360" format="default"/> <xref target="RFC7153" for | |||
path attribute that consists of one or more extended | mat="default"/> is a BGP | |||
communities. | path attribute that consists of one or more Extended | |||
</t> | Communities. | |||
<t> | </dd> | |||
RT (Route Target): A Route Target is a particular kind of BGP | <dt>RT:</dt> <dd>Route Target. A Route Target is a particular kind o | |||
f BGP | ||||
Extended Community. A BGP Extended Community consists of a type | Extended Community. A BGP Extended Community consists of a type | |||
field, a sub-type field, and a value field. Certain | field, a sub-type field, and a value field. Certain | |||
type/sub-type combinations indicate that a particular Extended | type/sub-type combinations indicate that a particular Extended | |||
Community is an RT. RT1 and RT2 are considered to be the same | Community is an RT. RT1 and RT2 are considered to be the same | |||
RT if and only if they have the same type, same sub-type, and | RT if and only if they have the same type, sub-type, and | |||
same value fields. | value fields. | |||
</t> | </dd> | |||
<t> | <dt>C- prefix:</dt> <dd>In many documents on VPN | |||
Use of the "C&nbhy;" prefix. In many documents on VPN | multicast, the prefix C- appears before any address or | |||
multicast, the prefix "C&nbhy;" appears before any address or | ||||
wildcard that refers to an address or addresses in a tenant's | wildcard that refers to an address or addresses in a tenant's | |||
address space, rather than to an address of addresses in the | address space rather than to an address of addresses in the | |||
address space of the backbone network. This document omits the | address space of the backbone network. This document omits the | |||
"C&nbhy;" prefix in many cases where it is clear from the | C- prefix in many cases where it is clear from the | |||
context that the reference is to the tenant's address space. | context that the reference is to the tenant's address space. | |||
</t> | </dd> | |||
</list> | </dl> | |||
</t> | ||||
<t> | ||||
This document also assumes familiarity with the terminology of <xref | ||||
target="RFC4364"/>, <xref target="RFC6514"/>, <xref | ||||
target="RFC7432"/>, <xref target="RFC7761"/>, <xref | ||||
target="RFC9251"/>, <xref target="RFC9136"/> and <xref | ||||
target="I-D.ietf-bess-evpn-bum-procedure-updates"/>. | ||||
</t> | ||||
</section> <!-- terminology --> | ||||
<section title="Background" anchor="background"> | ||||
<t> | <t> | |||
Ethernet VPN (EVPN) <xref target="RFC7432"/> provides a Layer 2 | This document also assumes familiarity with the terminology of <xref tar | |||
get="RFC4364" format="default"/>, <xref target="RFC6514" format="default"/>, <xr | ||||
ef target="RFC7432" format="default"/>, <xref target="RFC7761" format="default"/ | ||||
>, <xref target="RFC9136" format="default"/>, <xref target="RFC9251" format="def | ||||
ault"/>, and <xref target="RFC9572" format="default"/>. | ||||
</t> | ||||
<section> | ||||
<name>Requirements Language</name> | ||||
<t> | ||||
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU | ||||
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | ||||
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14> | ||||
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | ||||
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | ||||
be interpreted as | ||||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> | ||||
when, and only when, they appear in all capitals, as shown here. | ||||
</t> | ||||
</section> | ||||
</section> | ||||
<section anchor="background" numbered="true" toc="default"> | ||||
<name>Background</name> | ||||
<t> | ||||
Ethernet VPN (EVPN) <xref target="RFC7432" format="default"/> provides | ||||
a Layer 2 | ||||
VPN (L2VPN) solution, which allows an IP or MPLS backbone provider to offer | VPN (L2VPN) solution, which allows an IP or MPLS backbone provider to offer | |||
Ethernet service to a set of customers, known as "tenants". | Ethernet service to a set of customers, known as "tenants". | |||
</t> | </t> | |||
<t> | <t> | |||
In this section (as well as in <xref target="RFC9135"/>), we | In this section (as well as in <xref target="RFC9135" format="default" />), we | |||
provide some essential background information on EVPN. | provide some essential background information on EVPN. | |||
</t> | </t> | |||
<section title="Segments, Broadcast Domains, and Tenants" | <section anchor="intro_bd" numbered="true" toc="default"> | |||
anchor="intro_bd"> | <name>Segments, Broadcast Domains, and Tenants</name> | |||
<t> | <t> | |||
One of the key concepts of EVPN is the Broadcast Domain (BD). A | One of the key concepts of EVPN is the Broadcast Domain (BD). A | |||
BD is essentially an emulated Ethernet. Each BD belongs to a | BD is essentially an emulated Ethernet. Each BD belongs to a | |||
single tenant. A BD typically consists of multiple Ethernet | single tenant. A BD typically consists of multiple Ethernet | |||
"segments", and each segment may be attached to a different EVPN | segments, and each segment may be attached to a different EVPN | |||
Provider Edge (EVPN&nbhy;PE) router. EVPN&nbhy;PE routers are | Provider Edge (EVPN PE) router. EVPN PE routers are | |||
often referred to as "Network Virtualization Endpoints" or NVEs. | often referred to as "Network Virtualization Endpoints (NVEs)". | |||
However, this document will use the term "EVPN&nbhy;PE", or, | However, this document will use the term "EVPN PE" or, | |||
when the context is clear, just "PE". | when the context is clear, just "PE". | |||
</t> | </t> | |||
<t> | <t> | |||
In this document, the term "segment" is used interchangeable with | In this document, the term "segment" is used interchangeably with | |||
the "Ethernet Segment" or "ES" in <xref target="RFC7432"/ | "Ethernet Segment" or "ES", as defined in <xref target="R | |||
>. | FC7432" format="default"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
Attached to each segment are "Tenant Systems" (TSes). A TS may | Attached to each segment are Tenant Systems (TSs). A TS may | |||
be any type of system, physical or virtual, host or router, | be any type of system, physical or virtual, host or router, | |||
etc., that can attach to an Ethernet. | etc., that can attach to an Ethernet. | |||
</t> | </t> | |||
<t> | <t> | |||
When two TSes are on the same segment, traffic between them does | When two TSs are on the same segment, traffic between them does | |||
not pass through an EVPN&nbhy;PE. When two TSes are on | not pass through an EVPN PE. When two TSs are on | |||
different segments of the same BD, traffic between them does | different segments of the same BD, traffic between them does | |||
pass through an EVPN&nbhy;PE. | pass through an EVPN PE. | |||
</t> | </t> | |||
<t> | <t> | |||
When two TSes, say TS1 and TS2 are on the same BD, then: | When two TSs, say TS1 and TS2, are on the same BD, then the followin | |||
<list style="symbols"> | g occurs: | |||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | <t> | |||
If TS1 knows the MAC address of TS2, TS1 can send unicast | If TS1 knows the Media Access Control (MAC) address of TS2, TS1 can send unicast | |||
Ethernet frames to TS2. TS2 will receive the frames | Ethernet frames to TS2. TS2 will receive the frames | |||
unaltered. | unaltered. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
If TS1 broadcasts an Ethernet frame, TS2 will receive the | If TS1 broadcasts an Ethernet frame, TS2 will receive the | |||
unaltered frame. | unaltered frame. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
If TS1 multicasts an Ethernet frame, TS2 will receive the | If TS1 multicasts an Ethernet frame, TS2 will receive the | |||
unaltered frame, as long as TS2 has been provisioned to | unaltered frame as long as TS2 has been provisioned to | |||
receive the Ethernet multicast destination MAC address. | receive the Ethernet multicast destination MAC address. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
When we say that TS2 receives an unaltered frame from TS1, we | When we say that TS2 receives an unaltered frame from TS1, we | |||
mean that the frame still contains TS1's MAC address, and that | mean that the frame still contains TS1's MAC address and that | |||
no alteration of the frame's payload (and consequently, no | no alteration of the frame's payload (and consequently, no | |||
alteration of the payload's IP header) has been made. | alteration of the payload's IP header) has been made. | |||
</t> | </t> | |||
<t> | <t> | |||
EVPN allows a single segment to be attached to multiple PE | EVPN allows a single segment to be attached to multiple PE | |||
routers. This is known as "EVPN multi&nbhy;homing". Suppose a | routers. This is known as "EVPN multihoming". Suppose a | |||
given segment is attached to both PE1 and PE2, and suppose PE1 | given segment is attached to both PE1 and PE2, and suppose PE1 | |||
receives a frame from that segment. It may be necessary for PE1 | receives a frame from that segment. It may be necessary for PE1 | |||
to send the frame over the backbone to PE2. EVPN has procedures | to send the frame over the backbone to PE2. EVPN has procedures | |||
to ensure that such a frame cannot be sent by PE2 back to its | to ensure that such a frame cannot be sent back to its | |||
originating segment. This is particularly important for | originating segment by PE2. This is particularly important for | |||
multicast, because a frame arriving at PE1 from a given segment | multicast, because a frame arriving at PE1 from a given segment | |||
will already have been seen by all the systems on that segment | will already have been seen by all the systems on that segment | |||
that need to see it. If the frame were sent back to the | that need to see it. If the frame was sent back to the | |||
originating segment by PE2, receivers on that segment would | originating segment by PE2, receivers on that segment would | |||
receive the packet twice. Even worse, the frame might be sent | receive the packet twice. Even worse, the frame might be sent | |||
back to PE1, which could cause an infinite loop. | back to PE1, which could cause an infinite loop. | |||
</t> | </t> | |||
</section> <!-- intro_bd --> | </section> | |||
<section title="Inter-BD (Inter-Subnet) IP Traffic" | <section anchor="inter_bd" numbered="true" toc="default"> | |||
anchor="inter_bd"> | <name>Inter-BD (Inter-Subnet) IP Traffic</name> | |||
<t> | <t> | |||
If a given tenant has multiple BDs, the tenant may wish to allow | If a given tenant has multiple BDs, the tenant may wish to allow | |||
IP communication among these BDs. Such a set of BDs is known as | IP communication among these BDs. Such a set of BDs is known as | |||
an "EVPN Tenant Domain" or just a "Tenant Domain". | an "EVPN Tenant Domain" or just a "Tenant Domain". | |||
</t> | </t> | |||
<t> | <t> | |||
If tenant systems TS1 and TS2 are not in the same BD, then they | If tenant systems TS1 and TS2 are not in the same BD, then they | |||
do not receive unaltered Ethernet frames from each other. In | do not receive unaltered Ethernet frames from each other. In | |||
order for TS1 to send traffic to TS2, TS1 encapsulates an IP | order for TS1 to send traffic to TS2, TS1 encapsulates an IP | |||
datagram inside an Ethernet frame, and uses Ethernet to send | datagram inside an Ethernet frame and uses Ethernet to send | |||
these frames to an IP router. The router decapsulates the IP | these frames to an IP router. The router decapsulates the IP | |||
datagram, does the IP processing and re-encapsulates the | datagram, does the IP processing, and re-encapsulates the | |||
datagram for Ethernet. The MAC source address field now has the | datagram for Ethernet. The MAC Source Address field now has the | |||
MAC address of the router, not of TS1. The TTL field of the IP | MAC address of the router, not of TS1. The TTL field of the IP | |||
datagram should be decremented by exactly 1, even if the frame | datagram should be decremented by exactly 1, even if the frame | |||
needs to be sent from one PE to another. The structure of the | needs to be sent from one PE to another. The structure of the | |||
provider's backbone is thus hidden from the tenants. | provider's backbone is thus hidden from the tenants. | |||
</t> | </t> | |||
<t> | <t> | |||
EVPN accommodates the need for inter&nbhy;BD communication | EVPN accommodates the need for inter-BD communication | |||
within a Tenant Domain by providing an integrated L2/L3 service | within a Tenant Domain by providing an integrated L2/L3 service | |||
for unicast IP traffic. EVPN's Integrated Routing and Bridging | for unicast IP traffic. EVPN's Integrated Routing and Bridging | |||
(IRB) functionality is specified in <xref target="RFC9135"/>. | (IRB) functionality is specified in <xref target="RFC9135" format="d efault"/>. | |||
Each BD in a Tenant Domain is assumed to be a single IP subnet, | Each BD in a Tenant Domain is assumed to be a single IP subnet, | |||
and each IP subnet within a given Tenant Domain is assumed to | and each IP subnet within a given Tenant Domain is assumed to | |||
be a single BD. EVPN's IRB functionality allows IP traffic to | be a single BD. EVPN's IRB functionality allows IP traffic to | |||
travel from one BD to another, and ensures that proper IP | travel from one BD to another and ensures that proper IP | |||
processing (e.g., TTL decrement) is done. | processing (e.g., TTL decrement) is done. | |||
</t> | </t> | |||
<t> | <t> | |||
A brief overview of IRB, including the notion of an "IRB | A brief overview of IRB, including the notion of an IRB | |||
interface", can be found in <xref target="irb"/>. As explained | interface, can be found in <xref target="irb" format="default"/>. A | |||
s explained | ||||
there, an IRB interface is a sort of virtual interface | there, an IRB interface is a sort of virtual interface | |||
connecting an L3 routing instance to a BD. A BD may have | connecting an L3 routing instance to a BD. A BD may have | |||
multiple attachment circuits (ACs) to a given PE, where each AC | multiple Attachment Circuits (ACs) to a given PE, where each AC | |||
connects to a different Ethernet segment of the BD. However, | connects to a different Ethernet segment of the BD. However, | |||
these ACs are not visible to the L3 routing function; from the | these ACs are not visible to the L3 routing function; from the | |||
perspective of an L3 routing instance, a PE has just one | perspective of an L3 routing instance, a PE has just one | |||
interface to each BD, viz., the IRB interface for that BD. | interface to each BD, viz., the IRB interface for that BD. | |||
</t> | </t> | |||
<t> | <t> | |||
In this document, when traffic is routed out of an IRB in terface, | In this document, when traffic is routed out of an IRB in terface, | |||
we say it is sent down the IRB interface to the BD that t he IRB is | we say it is sent down the IRB interface to the BD that t he IRB is | |||
for. In the other direction, traffic is sent up the IRB i nterface | for. In the other direction, traffic is sent up the IRB i nterface | |||
from the BD to the L3 routing instance. | from the BD to the L3 routing instance. | |||
</t> | </t> | |||
<t> | <t> | |||
The "L3 routing instance" depicted in <xref target="irb"/> is | The L3 routing instance depicted in <xref target="irb" format="defau | |||
associated with a single Tenant Domain, and may be thought of as | lt"/> is | |||
an IP&nbhy;VRF for that Tenant Domain. | associated with a single Tenant Domain and may be thought of as | |||
IP Virtual Routing and Forwarding (IP-VRF) for that Tenant Domain. | ||||
</t> | </t> | |||
</section> <!-- inter_bd --> | </section> | |||
<section title="EVPN and IP Multicast" | <section anchor="evpn_ip_mcast" numbered="true" toc="default"> | |||
anchor="evpn_ip_mcast"> | <name>EVPN and IP Multicast</name> | |||
<t> | <t> | |||
<xref target="RFC9135"/> and <xref target="RFC9136"/> | <xref target="RFC9135" format="default"/> and <xref target="RFC9136" | |||
cover inter&nbhy;subnet (inter&nbhy;BD) IP unicast forwarding, | format="default"/> | |||
but they do not cover inter&nbhy;subnet IP multicast forwarding. | cover inter-subnet (inter-BD) IP unicast forwarding, | |||
but they do not cover inter-subnet IP multicast forwarding. | ||||
</t> | </t> | |||
<t> | <t> | |||
<xref target="RFC7432"/> covers intra&nbhy;subnet | <xref target="RFC7432" format="default"/> covers intra-subnet | |||
(intra&nbhy;BD) Ethernet multicast. The intra&nbhy;subnet | (intra-BD) Ethernet multicast. The intra-subnet | |||
Ethernet multicast procedures of <xref target="RFC7432"/> are | Ethernet multicast procedures of <xref target="RFC7432" format="defa | |||
used for Ethernet Broadcast traffic, for Ethernet unicast | ult"/> are | |||
traffic whose MAC Destination Address field contains an Unknown | used for Ethernet broadcast traffic, Ethernet unicast | |||
address, and for Ethernet traffic whose MAC Destination Address | traffic whose Destination MAC Address field contains an unknown | |||
field contains an Ethernet Multicast MAC address. These three | address, and Ethernet traffic whose Destination MAC Address | |||
field contains an Ethernet multicast MAC address. These three | ||||
classes of traffic are known collectively as "BUM traffic" | classes of traffic are known collectively as "BUM traffic" | |||
(Broadcast/Unknown-Unicast/Multicast), and the procedures for | (Broadcast, Unknown Unicast, or Multicast traffic), and the procedur es for | |||
handling BUM traffic are known as "BUM procedures". | handling BUM traffic are known as "BUM procedures". | |||
</t> | </t> | |||
<t> | <t> | |||
<xref target="RFC9251"/> extends the intra&nbhy;subnet | <xref target="RFC9251" format="default"/> extends the intra-subnet | |||
Ethernet multicast procedures by adding procedures that are | Ethernet multicast procedures by adding procedures that are | |||
specific to, and optimized for, the use of IP multicast within a | specific to, and optimized for, the use of IP multicast within a | |||
subnet. However, that document does not cover inter&nbhy;subnet | subnet. However, that document does not cover inter-subnet | |||
IP multicast. | IP multicast. | |||
</t> | </t> | |||
<t> | <t> | |||
The purpose of this document is to specify procedures for EVPN | The purpose of this document is to specify procedures for EVPN | |||
that provide optimized IP multicast functionality within an EVPN | that provide optimized IP multicast functionality within an EVPN | |||
tenant domain. This document also specifies procedures that | Tenant Domain. This document also specifies procedures that | |||
allow IP multicast packets to be sourced from or destined to | allow IP multicast packets to be sourced from or destined to | |||
systems outside the Tenant Domain. We refer to the entire set of | systems outside the Tenant Domain. The entire set of | |||
these procedures as "OISM" (Optimized Inter&nbhy;Subnet | procedures are referred to as "Optimized Inter-Subnet | |||
Multicast) procedures. | Multicast (OISM)" procedures. | |||
</t> | </t> | |||
<t> | <t> | |||
In order to support the OISM procedures specified in this | In order to support the OISM procedures specified in this | |||
document, an EVPN&nbhy;PE MUST also support <xref | document, an EVPN PE <bcp14>MUST</bcp14> also support <xref target=" | |||
target="RFC9135"/> and <xref target="RFC9251"/>. (However, | RFC9135" format="default"/> and <xref target="RFC9251" format="default"/>. (How | |||
certain procedures in <xref target="RFC9251"/> are | ever, | |||
certain procedures in <xref target="RFC9251" format="default"/> are | ||||
modified when OISM is supported.) | modified when OISM is supported.) | |||
</t> | </t> | |||
</section> | ||||
</section> <!-- "evpn_ip_mcast --> | <section anchor="evpn_stuff" numbered="true" toc="default"> | |||
<name>BDs, MAC-VRFs, and EVPN Service Models</name> | ||||
<section title="BDs, MAC-VRFS, and EVPN Service Models" | ||||
anchor="evpn_stuff"> | ||||
<t> | <t> | |||
<xref target="RFC7432"/> defines the notion of "MAC&nbhy;VRF". | <xref target="RFC7432" format="default"/> defines the notion of MAC-VR | |||
A MAC&nbhy;VRF contains one or more "Bridge Tables" (see section | F (MAC Virtual Routing and Forwarding). | |||
3 of <xref target="RFC7432"/> for a discussion of this | A MAC-VRF contains one or more bridge tables (see | |||
terminology), each of which represents a single Broadcast | <xref target="RFC7432" format="default" sectionFormat="of" section=" | |||
3"/>), each of which represents a single Broadcast | ||||
Domain. | Domain. | |||
</t> | </t> | |||
<t> | <t> | |||
In the IRB model (outlined in <xref target="irb"/>), an L3 routing | In the IRB model (outlined in <xref target="irb" format="default"/>) | |||
instance has one IRB interface per BD, NOT one per MAC&nbhy;VRF. | , an L3 routing | |||
This document does not distinguish between a "Broadcast Domain" | instance has one IRB interface per BD, NOT one per MAC-VRF. | |||
and a "Bridge Table", and will use the terms interchangeably (or | This document does not distinguish between a Broadcast Domain | |||
and a bridge table; instead, it uses the terms interchangeably (or | ||||
will use the acronym "BD" to refer to either). The way the BDs | will use the acronym "BD" to refer to either). The way the BDs | |||
are grouped into MAC&nbhy;VRFs is not relevant to the procedures | are grouped into MAC-VRFs is not relevant to the procedures | |||
specified in this document. | specified in this document. | |||
</t> | </t> | |||
<t> | <t> | |||
Section 6 of <xref target="RFC7432"/> also defines several | <xref target="RFC7432" format="default" sectionFormat="of" section=" 6"/> also defines several | |||
different EVPN service models: | different EVPN service models: | |||
<list style="symbols"> | </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | <t> | |||
In the "vlan&nbhy;based service", each MAC&nbhy;VRF contains | In the vlan-based service, each MAC-VRF contains | |||
one "bridge table", where the bridge table corresponds to a | one bridge table, where the bridge table corresponds to a | |||
particular Virtual LAN (VLAN). (See section 3 of <xref | particular Virtual LAN (VLAN) (see <xref target="RFC7432" format | |||
target="RFC7432"/> for a discussion of this terminology.) | ="default" sectionFormat="of" section="3"/>). | |||
Thus, each VLAN is treated as a BD. | Thus, each VLAN is treated as a BD. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
In the "vlan bundle service", each MAC&nbhy;VRF contains one | In the vlan bundle service, each MAC-VRF contains one | |||
bridge table, where the bridge table corresponds to a set of | bridge table, where the bridge table corresponds to a set of | |||
VLANs. Thus a set of VLANs are treated as constituting a | VLANs. Thus, a set of VLANs are treated as constituting a | |||
single BD. | single BD. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
In the "vlan&nbhy;aware bundle service", each MAC&nbhy;VRF | In the vlan-aware bundle service, each MAC-VRF | |||
may contain multiple bridge tables, where each bridge table | may contain multiple bridge tables, where each bridge table | |||
corresponds to one BD. If a MAC&nbhy;VRF contains several | corresponds to one BD. If a MAC-VRF contains several | |||
bridge tables, then it corresponds to several BDs. | bridge tables, then it corresponds to several BDs. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
The procedures in this document are intended to work for all | The procedures in this document are intended to work for all | |||
these service models. | these service models. | |||
</t> | </t> | |||
</section> <!-- evpn_stuff --> | </section> | |||
</section> <!-- background --> | </section> | |||
<section anchor="need" numbered="true" toc="default"> | ||||
<section title="Need for EVPN-aware Multicast Procedures" anchor="need"> | <name>Need for EVPN-Aware Multicast Procedures</name> | |||
<t> | <t> | |||
Inter&nbhy;subnet IP multicast among a set of BDs can be achieved, | Inter-subnet IP multicast among a set of BDs can be achieved, | |||
in a non&nbhy;optimal manner, without any specific EVPN | in a non-optimal manner, without any specific EVPN | |||
procedures. For instance, if a particular tenant has n BDs among | procedures. For instance, if a particular tenant has n BDs among | |||
which he wants to send IP multicast traffic, he can simply attach | which it wants to send IP multicast traffic, it can simply attach | |||
a conventional multicast router to all n BDs. Or more generally, | a conventional multicast router to all n BDs. Or more generally, | |||
as long as each BD has at least one IP multicast router, and the | as long as each BD has at least one IP multicast router, and the | |||
IP multicast routers communicate multicast control information | IP multicast routers communicate multicast control information | |||
with each other, conventional IP multicast procedures will work | with each other, conventional IP multicast procedures will work | |||
normally, and no special EVPN functionality is needed. | normally, and no special EVPN functionality is needed. | |||
</t> | </t> | |||
<t> | <t> | |||
However, that technique does not provide optimal routing for | However, that technique does not provide optimal routing for | |||
multicast. In conventional multicast routing, for a given | multicast. In conventional multicast routing, for a given | |||
multicast flow, there is only one multicast router on each BD that | multicast flow, there is only one multicast router on each BD that | |||
is permitted to send traffic of that flow to the BD. If that BD | is permitted to send traffic of that flow to the BD. If that BD | |||
has receivers for a given flow, but the source of the flow is not | has receivers for a given flow, but the source of the flow is not | |||
on that BD, then the flow must pass through that multicast router. | on that BD, then the flow must pass through that multicast router. | |||
This leads to the "hair&nbhy;pinning" problem described (for | This leads to the hairpinning problem described (for | |||
unicast) in <xref target="irb"/>. | unicast) in <xref target="irb" format="default"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
For example, consider an (S,G) flow that is sourced by a TS S and | For example, consider an (S,G) flow that is sourced by a TS S and | |||
needs to be received by TSes R1 and R2. Suppose S is on a segment | needs to be received by TSs R1 and R2. Suppose S is on a segment | |||
of BD1, R1 is on a segment of BD2, but both are attached to PE1. | of BD1, R1 is on a segment of BD2, but both are attached to PE1. | |||
Suppose also that the tenant has a multicast router, attached to a | Also suppose that the tenant has a multicast router attached to a | |||
segment of BD1 and to a segment of BD2. However, the segments to | segment of BD1 and to a segment of BD2. However, the segments to | |||
which that router is attached are both attached to PE2. Then the | which that router is attached are both attached to PE2. Then, the | |||
flow from S to R would have to follow the path: | flow from S to R would have to follow the path: | |||
S-->PE1-->PE2-->Tenant Multicast Router-->PE2-->PE1-->R1. | S-->PE1-->PE2-->tenant multicast router-->PE2-->PE1--&g | |||
Obviously, the path S-->PE1-->R would be preferred. | t;R1. | |||
Obviously, the path S-->PE1-->R would be preferred. | ||||
</t> | </t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
<figure align="center"> | ||||
<artwork> | ||||
+---+ +---+ | +---+ +---+ | |||
|PE1+----------------------+PE2| | |PE1+----------------------+PE2| | |||
+---+-+ +-+---+ | +---+-+ +-+---+ | |||
| \ \ / / | | | \ \ / / | | |||
BD1 BD2 BD3 BD3 BD2 BD1 | BD1 BD2 BD3 BD3 BD2 BD1 | |||
| | | \ | | | | | | \ | | | |||
S R1 R2 router | S R1 R2 router | |||
]]></artwork> | ||||
</artwork> | ||||
</figure> | ||||
<t> | <t> | |||
Now suppose that there is a second receiver, R2. R2 is attached | Now suppose that there is a second receiver, R2. R2 is attached | |||
to a third BD, BD3. However, it is attached to a segment of BD3 | to a third BD, BD3. However, it is attached to a segment of BD3 | |||
that is attached to PE1. And suppose also that the Tenant | that is attached to PE1. And suppose that the tenant | |||
Multicast Router is attached to a segment of BD3 that attaches to | multicast router is attached to a segment of BD3 that attaches to | |||
PE2. In this case, the Tenant Multicast Router will make two | PE2. In this case, the tenant multicast router will make two | |||
copies of the packet, one for BD2 and one for BD3. PE2 will send | copies of the packet, one for BD2 and one for BD3. PE2 will send | |||
both copies back to PE1. Not only is the routing sub-optimal, but | both copies back to PE1. Not only is the routing sub-optimal, but | |||
also PE2 sends multiple copies of the same packet to PE1. This is a | PE2 also sends multiple copies of the same packet to PE1, which is a | |||
further sub-optimality. | further sub-optimality. | |||
</t> | </t> | |||
<t> | <t> | |||
This is only an example; many more examples of sub-optimal | This is only an example; many more examples of sub-optimal | |||
multicast routing can easily be given. To eliminate sub-optimal | multicast routing can easily be given. To eliminate sub-optimal | |||
routing and extra copies, it is necessary to have a multicast | routing and extra copies, it is necessary to have a multicast | |||
solution that is EVPN-aware, and that can use its knowledge of the | solution that is EVPN-aware and that can use its knowledge of the | |||
internal structure of a Tenant Domain to ensure that multicast | internal structure of a Tenant Domain to ensure that multicast | |||
traffic gets routed optimally. The procedures in this document | traffic gets routed optimally. The procedures in this document | |||
allow us to avoid all such sub-optimalities when routing | allow us to avoid all such sub-optimalities when routing | |||
inter&nbhy;subnet multicast traffic within a Tenant Domain. | inter-subnet multicast traffic within a Tenant Domain. | |||
</t> | </t> | |||
</section> | </section> | |||
<section title="Additional Requirements That Must be Met by the Solution" | <section anchor="requirements" numbered="true" toc="default"> | |||
anchor="requirements"> | <name>Additional Requirements That Must Be Met by the Solution</name> | |||
<t> | <t> | |||
In addition to providing optimal routing of multicast flows within a | In addition to providing optimal routing of multicast flows within a | |||
Tenant Domain, the EVPN-aware multicast solution is intended to | Tenant Domain, the EVPN-aware multicast solution is intended to | |||
satisfy the following requirements: | satisfy the following requirements: | |||
<list style="symbols"> | </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | <t> | |||
The solution must integrate well with the procedures specified | The solution must integrate well with the procedures specified | |||
in <xref target="RFC9251"/>. That is, an integrated set of | in <xref target="RFC9251" format="default"/>. That is, an integrat | |||
procedures must handle both intra&nbhy;subnet multicast and | ed set of | |||
inter&nbhy;subnet multicast. | procedures must handle both intra-subnet multicast and | |||
inter-subnet multicast. | ||||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
With regard to intra&nbhy;subnet multicast, the solution MUST | With regard to intra-subnet multicast, the solution <bcp14>MUST</b | |||
maintain the integrity of multicast Ethernet service. This | cp14> | |||
maintain the integrity of the multicast Ethernet service. This | ||||
means: | means: | |||
<list style="symbols"> | </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | <t> | |||
If a source and a receiver are on the same subnet, the MAC | If a source and a receiver are on the same subnet, the MAC | |||
source address (SA) of the multicast frame sent by the | Source Address (SA) of the multicast frame sent by the | |||
source will not get rewritten. | source will not get rewritten. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
If a source and a receiver are on the same subnet, no IP | If a source and a receiver are on the same subnet, no IP | |||
processing of the Ethernet payload is done. The IP TTL is | processing of the Ethernet payload is done. The IP TTL is | |||
not decremented, the IPv4 header checksum is not changed, no | not decremented, the IPv4 header checksum is not changed, no | |||
fragmentation is done, etc. | fragmentation is done, etc. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
On the other hand, if a source and a receiver are on different | On the other hand, if a source and a receiver are on different | |||
subnets, the frame received by the receiver will not have the | subnets, the frame received by the receiver will not have the | |||
MAC Source address of the source, as the frame will appear to | MAC Source Address of the source, as the frame will appear to | |||
have come from a multicast router. Also, proper processing of | have come from a multicast router. Also, proper processing of | |||
the IP header is done, e.g., TTL decrement by 1, header | the IP header is done, e.g., TTL decrements by 1, header | |||
checksum modification, possible fragmentation, etc. | checksum modification, possible fragmentation, etc. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
If a Tenant Domain contains several BDs, it MUST be possible | If a Tenant Domain contains several BDs, it <bcp14>MUST</bcp14> be possible | |||
for a multicast flow (even when the multicast group address is | for a multicast flow (even when the multicast group address is | |||
an "any source multicast" (ASM) address), to have sources in | an ASM address) to have sources in | |||
one of those BDs and receivers in one or more of the other | one of those BDs and receivers in one or more of the other | |||
BDs, without requiring the presence of any system performing | BDs without requiring the presence of any system performing | |||
PIM Rendezvous Point (RP) functions <xref | PIM RP functions <xref target="RFC7761" format="default"/>. | |||
target="RFC7761"/>. | ||||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
Sometimes a MAC address used by one TS on a particular BD is | Sometimes a MAC address used by one TS on a particular BD is | |||
also used by another TS on a different BD. Inter&nbhy;subnet | also used by another TS on a different BD. Inter-subnet | |||
routing of multicast traffic MUST NOT make any assumptions | routing of multicast traffic <bcp14>MUST NOT</bcp14> make any assu | |||
mptions | ||||
about the uniqueness of a MAC address across several BDs. | about the uniqueness of a MAC address across several BDs. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
If two EVPN&nbhy;PEs attached to the same Tenant Domain both | If two EVPN PEs attached to the same Tenant Domain both | |||
support the OISM procedures, each may receive | support the OISM procedures, each may receive | |||
inter&nbhy;subnet multicasts from the other, even if the | inter-subnet multicasts from the other, even if the | |||
egress PE is not attached to any segment of the BD from which | egress PE is not attached to any segment of the BD from which | |||
the multicast packets are being sourced. It MUST NOT be | the multicast packets are being sourced. It <bcp14>MUST NOT</bcp1 4> be | |||
necessary to provision the egress PE with knowledge of the | necessary to provision the egress PE with knowledge of the | |||
ingress BD. | ingress BD. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
There must be a procedure that allows EVPN&nbhy;PE | There must be a procedure that allows EVPN PE | |||
routers supporting OISM procedures to send/receive multicast | routers supporting OISM procedures to send/receive multicast | |||
traffic to/from EVPN&nbhy;PE routers that support only <xref | traffic to/from EVPN PE routers that support only <xref target="RF | |||
target="RFC7432"/>, but that do not support the OISM | C7432" format="default"/> but that does not support the OISM | |||
procedures or even the procedures of <xref | procedures or even the procedures of <xref target="RFC9135" format | |||
target="RFC9135"/>. However, when interworking with such | ="default"/>. However, when interworking with such | |||
routers (which we call "non&nbhy;OISM PE routers"), optimal | routers (which we call "non-OISM PE routers"), optimal | |||
routing may not be achievable. | routing may not be achievable. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
It MUST be possible to support scenarios in which multicast | It <bcp14>MUST</bcp14> be possible to support scenarios in which m | |||
flows with sources inside a Tenant Domain have "external" | ulticast | |||
flows with sources inside a Tenant Domain have external | ||||
receivers, i.e., receivers that are outside the domain. It | receivers, i.e., receivers that are outside the domain. It | |||
must also be possible to support scenarios where multicast | must also be possible to support scenarios where multicast | |||
flows with external sources (sources outside the Tenant | flows with external sources (sources outside the Tenant | |||
Domain) have receivers inside the domain. | Domain) have receivers inside the domain. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
This presupposes that unicast routes to multicast sources | This presupposes that unicast routes to multicast sources | |||
outside the domain can be distributed to EVPN&nbhy;PEs | outside the domain can be distributed to EVPN PEs | |||
attached to the domain, and that unicast routes to multicast | attached to the domain and that unicast routes to multicast | |||
sources within the domain can be distributed outside the | sources within the domain can be distributed outside the | |||
domain. | domain. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
Of particular importance is the scenario in which the | Of particular importance are the scenarios in which the | |||
external sources and/or receivers are reachable via | external sources and/or receivers are reachable via | |||
L3VPN/MVPN, and the scenario in which external sources and/or | L3VPN/MVPN or via IP/PIM. | |||
receivers are reachable via IP/PIM. | </t> | |||
<vspace/> | <t> | |||
<vspace/> | The solution for external interworking <bcp14>MUST</bcp14> allow f | |||
The solution for external interworking MUST allow for | or | |||
deployment scenarios in which EVPN does not need to export a | deployment scenarios in which EVPN does not need to export a | |||
host route for every multicast source. | host route for every multicast source. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
The solution for external interworking must not presuppose | The solution for external interworking must not presuppose | |||
that the same tunneling technology is used within both the | that the same tunneling technology is used within both the | |||
EVPN domain and the external domain. For example, MVPN | EVPN domain and the external domain. For example, MVPN | |||
interworking must be possible when MVPN is using MPLS P2MP | interworking must be possible when MVPN is using MPLS Point-to-Mul | |||
tunneling, and EVPN is using Ingress Replication or VXLAN | tipoint (P2MP) | |||
tunneling and when EVPN is using Ingress Replication (IR) or Virtu | ||||
al eXtensible Local Area Network (VXLAN) | ||||
tunneling. | tunneling. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
The solution must not be overly dependent on the details of a | The solution must not be overly dependent on the details of a | |||
small set of use cases, but must be adaptable to new use cases | small set of use cases but must be adaptable to new use cases | |||
as they arise. (That is, the solution must be robust.) | as they arise. (That is, the solution must be robust.) | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
</section> | </section> | |||
<section title="Model of Operation: Overview" anchor="model_overview"> | <section anchor="model_overview" numbered="true" toc="default"> | |||
<section title="Control Plane" anchor="cp_overview"> | <name>Model of Operation: Overview</name> | |||
<t> | <section anchor="cp_overview" numbered="true" toc="default"> | |||
<name>Control Plane</name> | ||||
<t> | ||||
In this section, and in the remainder of this document, we assume | In this section, and in the remainder of this document, we assume | |||
the reader is familiar with the procedures of IGMP/MLD (see <xref | the reader is familiar with the procedures of IGMP / Multicast Listene | |||
target="RFC3376"/> and <xref target="RFC3810"/>), by which hosts | r Discovery (MLD) (see <xref target="RFC3376" format="default"/> and <xref targe | |||
t="RFC3810" format="default"/>), by which hosts | ||||
announce their interest in receiving particular multicast flows. | announce their interest in receiving particular multicast flows. | |||
</t> | </t> | |||
<t> | <t> | |||
Consider a Tenant Domain consisting of a set of k BDs: | Consider a Tenant Domain consisting of a set of k BDs: | |||
BD1, ..., BDk. To support the OISM procedures, each | BD1, ..., BDk. To support the OISM procedures, each | |||
Tenant Domain must also be associated with a "Supplementary | Tenant Domain must also be associated with a Supplementary | |||
Broadcast Domain" (SBD). An SBD is treated in the control plane | Broadcast Domain (SBD). An SBD is treated in the control plane | |||
as a real BD, but it does not have any ACs. The SBD has several | as a real BD, but it does not have any ACs. The SBD has several | |||
uses; these will be described later in this document (see <xref | uses; these will be described later in this document (see Sections <xr | |||
target="sbd_intro"/> and <xref target="solution"/>). | ef target="sbd_intro" format="counter"/> and <xref target="solution" format="cou | |||
</t> | nter"/>). | |||
<t> | </t> | |||
Each PE that attaches to one or more of the BDs in a given tenant | <t> | |||
domain will be provisioned to recognize that those BDs are part of | Each PE that attaches to one or more of the BDs in a given Tenant | |||
Domain will be provisioned to recognize that those BDs are part of | ||||
the same Tenant Domain. Note that a given PE does not need to be | the same Tenant Domain. Note that a given PE does not need to be | |||
configured with all the BDs of a given Tenant Domain. In general, | configured with all the BDs of a given Tenant Domain. In general, | |||
a PE will only be attached to a subset of the BDs in a given | a PE will only be attached to a subset of the BDs in a given | |||
Tenant Domain, and will be configured only with that subset of | Tenant Domain and will be configured only with that subset of | |||
BDs. However, each PE attached to a given Tenant Domain must be | BDs. However, each PE attached to a given Tenant Domain must be | |||
configured with the SBD for that Tenant Domain. | configured with the SBD for that Tenant Domain. | |||
</t> | </t> | |||
<t> | <t> | |||
Suppose a particular segment of a particular BD is attached to | Suppose a particular segment of a particular BD is attached to | |||
PE1. <xref target="RFC7432"/> specifies that PE1 must originate an | PE1. <xref target="RFC7432" format="default"/> specifies that PE1 must | |||
Inclusive Multicast Ethernet Tag (IMET) route for that BD, and | originate an | |||
Inclusive Multicast Ethernet Tag (IMET) route for that BD and | ||||
that the IMET route must be propagated to all other PEs attached | that the IMET route must be propagated to all other PEs attached | |||
to the same BD. If the given segment contains a host that has | to the same BD. If the given segment contains a host that has | |||
interest in receiving a particular multicast flow, either an (S,G) | interest in receiving a particular multicast flow, either an (S,G) | |||
flow or a (*,G) flow, PE1 will learn of that interest by | flow or a (*,G) flow, PE1 will learn of that interest by | |||
participating in the IGMP/MLD snooping procedures, | participating in the IGMP/MLD snooping procedures, | |||
as specified in <xref target="RFC4541"/>. In this case: | as specified in <xref target="RFC4541" format="default"/>. In | |||
<list style="symbols"> | this case: | |||
<t> | </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | ||||
PE1 is interested in receiving the flow; | PE1 is interested in receiving the flow; | |||
</t> | </t> | |||
<t> | </li> | |||
The AC attaching the interested host to PE1 is also said to be | <li> | |||
interested in the flow; | <t> | |||
</t> | the AC attaching the interested host to PE1 is also said to be | |||
<t> | interested in the flow; and | |||
The BD containing an AC that is interested in a particular | </t> | |||
</li> | ||||
<li> | ||||
<t> | ||||
the BD containing an AC that is interested in a particular | ||||
flow is also said to be interested in that flow. | flow is also said to be interested in that flow. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
Once PE1 determines that it has an AC that is interested in | Once PE1 determines that it has an AC that is interested in | |||
receiving a particular flow or set of flows, it originates one or | receiving a particular flow or set of flows, it originates one or | |||
more Selective Multicast Ethernet Tag (SMET) route(s) | more Selective Multicast Ethernet Tag (SMET) routes | |||
<xref target="RFC9251"/> to advertise that interest. | <xref target="RFC9251" format="default"/> to advertise that int | |||
</t> | erest. | |||
<t> | </t> | |||
Note that each IMET or SMET route is "for" a particular BD. The | <t> | |||
notion of a route being "for" a particular BD is explained in | Note that each IMET or SMET route is for a particular BD. The | |||
<xref target="bd_route"/>. | notion of a route being for a particular BD is explained in | |||
</t> | <xref target="bd_route" format="default"/>. | |||
<t> | </t> | |||
When OISM is being supported, the procedures of <xref | <t> | |||
target="RFC9251"/>, are modified as follows: | When OISM is being supported, the procedures of <xref target="RFC9251" | |||
<list style="symbols"> | format="default"/> are modified as follows: | |||
<t> | </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | ||||
The IMET route originated by a particular PE for a particular | The IMET route originated by a particular PE for a particular | |||
BD is distributed to all other PEs attached to the Tenant | BD is distributed to all other PEs attached to the Tenant | |||
Domain containing that BD, even to those PEs that are not | Domain containing that BD, even to those PEs that are not | |||
attached to that particular BD. | attached to that particular BD. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The SMET routes originated by a particular PE are originated | The SMET routes originated by a particular PE are originated | |||
on a per-Tenant-Domain basis, rather than on a per-BD basis. | on a per-Tenant-Domain basis rather than a per-BD basis. | |||
That is, the SMET routes are considered to be for the Tenant | That is, the SMET routes are considered to be for the Tenant | |||
Domain's SBD, rather than for any of its ordinary BDs. These | Domain's SBD rather than any of its ordinary BDs. These | |||
SMET routes are distributed to all the PEs attached to the | SMET routes are distributed to all the PEs attached to the | |||
Tenant Domain. | Tenant Domain. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
In this way, each PE attached to a given Tenant Domain learns, | In this way, each PE attached to a given Tenant Domain learns, | |||
from each other PE attached to the same Tenant Domain, the set | from the other PEs attached to the same Tenant Domain, the set | |||
of flows that are of interest to each of those other PEs. | of flows that are of interest to each of those other PEs. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<!-- <t> --> | ||||
<!-- OISM PEs MUST follow the procedures of <xref --> | ||||
<!-- target="RFC9251"/>. (Though see Sections <xref --> | ||||
<!-- target="smet_adv" format="counter"/> and <xref target="external" | ||||
--> | ||||
<!-- format="counter"/> for an exception.) In this document, we exten | ||||
d --> | ||||
<!-- the procedures of <xref target="RFC9251"/> so that IMET and --> | ||||
<!-- SMET routes for a particular BD are distributed not just to PEs - | ||||
-> | ||||
<!-- that attach to that BD, but to PEs that attach to any BD in the - | ||||
-> | ||||
<!-- Tenant Domain. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Note that if some PE attached to the Tenant Domain does not --> | ||||
<!-- support <xref target="RFC9251"/>, it will be assumed to be --> | ||||
<!-- interested in all flows. Whether a particular remote PE supports | ||||
--> | ||||
<!-- <xref target="RFC9251"/> is determined by the presence of an --> | ||||
<!-- "EVPN Multicast Flags Extended Community" attached to its IMET -- | ||||
> | ||||
<!-- routes; this is specified in <xref target="RFC9251"/>. --> | ||||
<!-- </t> --> | ||||
<t> | <t> | |||
An OISM PE that is provisioned with several BDs in the same Tenant | An OISM PE that is provisioned with several BDs in the same Tenant | |||
Domain MUST originate an IMET route for each such BD. To indicate | Domain <bcp14>MUST</bcp14> originate an IMET route for each such BD. | |||
its support of <xref target="RFC9251"/>, it SHOULD attach the | To indicate | |||
its support of <xref target="RFC9251" format="default"/>, it <bcp14>SH | ||||
OULD</bcp14> attach the | ||||
EVPN Multicast Flags Extended Community | EVPN Multicast Flags Extended Community | |||
<!-- (with the RFC9251 flag --> | to each such IMET route, but it <bcp14>MUST</bcp14> attach the EC | |||
<!-- set) --> | ||||
to each such IMET route, but it MUST attach the EC | ||||
<!-- (with the --> | ||||
<!-- RFC9251 flag set) --> | ||||
to at least one such IMET route. | to at least one such IMET route. | |||
</t> | </t> | |||
<t> | <t> | |||
Suppose PE1 is provisioned with both BD1 and BD2, and is | Suppose PE1 is provisioned with both BD1 and BD2 and | |||
provisioned to consider them to be part of the same Tenant Domain. | considers them to be part of the same Tenant Domain. | |||
It is possible that PE1 will receive from PE2 both an IMET route | It is possible that PE1 will receive both an IMET route | |||
for BD1 and an IMET route for BD2. If either of these IMET routes | for BD1 and an IMET route for BD2 from PE2. If either of these IMET r | |||
has the EVPN Multicast Flags Extended Community, PE1 MUST assume | outes | |||
that PE2 is supporting the procedures of <xref | has the EVPN Multicast Flags Extended Community, PE1 <bcp14>MUST</bcp1 | |||
target="RFC9251"/> for ALL BDs in the Tenant Domain. | 4> assume | |||
</t> | that PE2 is supporting the procedures of <xref target="RFC9251" format | |||
<t> | ="default"/> for ALL BDs in the Tenant Domain. | |||
If a PE supports OISM functionality, it indicates that by setting | </t> | |||
the "OISM-supported" flag in the Multicast Flags Extended | <t> | |||
Community that it attaches to some or all of its IMET routes. An | If a PE supports OISM functionality, it indicates that, by setting | |||
OISM PE SHOULD attach this EC with the OISM-supported flag set to | the OISM-supported flag in the Multicast Flags Extended | |||
Community, it attaches to some or all of its IMET routes. An | ||||
OISM PE <bcp14>SHOULD</bcp14> attach this EC with the OISM-supported f | ||||
lag set to | ||||
all the IMET routes it originates. However, if PE1 imports IMET | all the IMET routes it originates. However, if PE1 imports IMET | |||
routes from PE2, and at least one of PE2's IMET routes indicates | routes from PE2, and at least one of PE2's IMET routes indicates | |||
that PE2 is an OISM PE, PE1 MUST assume that PE2 is following OISM | that PE2 is an OISM PE, PE1 <bcp14>MUST</bcp14> assume that PE2 is fol lowing OISM | |||
procedures. | procedures. | |||
</t> | </t> | |||
</section> <!-- control plane overview --> | </section> | |||
<section title="Data Plane" anchor="dp_overview"> | <section anchor="dp_overview" numbered="true" toc="default"> | |||
<t> | <name>Data Plane</name> | |||
Suppose PE1 has an AC to a segment in BD1, and PE1 receives from | <t> | |||
that AC an (S,G) multicast frame (as defined in <xref | Suppose PE1 has an AC to a segment in BD1 and PE1 receives an (S,G) mu | |||
target="terminology"/>). | lticast frame from | |||
</t> | that AC (as defined in <xref target="terminology" format="default"/>). | |||
<t> | </t> | |||
There may be other ACs of PE1 on which TSes have indicated an | <t> | |||
There may be other ACs of PE1 on which TSs have indicated an | ||||
interest (via IGMP/MLD) in receiving (S,G) multicast packets. PE1 | interest (via IGMP/MLD) in receiving (S,G) multicast packets. PE1 | |||
is responsible for sending the received multicast packet on those | is responsible for sending the received multicast packet on those | |||
ACs. There are two cases to consider: | ACs. There are two cases to consider: | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
Intra-Subnet Forwarding: In this case, an attachment AC with | <li> | |||
<t> | ||||
Intra-Subnet Forwarding: In this case, an AC with | ||||
interest in (S,G) is connected to a segment that is part of | interest in (S,G) is connected to a segment that is part of | |||
the source BD, BD1. If the segment is not multi&nbhy;homed, | the source BD, BD1. If the segment is not multihomed, | |||
or if PE1 is the Designated Forwarder (DF) (see <xref | or if PE1 is the Designated Forwarder (DF) (see <xref target="RFC7 | |||
target="RFC7432"/>) for that segment, PE1 sends the multicast | 432" format="default"/>) for that segment, PE1 sends the multicast | |||
frame on that AC without changing the MAC SA. The IP header is | frame on that AC without changing the MAC SA. The IP header is | |||
not modified at all; in particular, the TTL is not | not modified at all; in particular, the TTL is not | |||
decremented. | decremented. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
Inter-Subnet Forwarding: An AC with interest in (S,G) is | Inter-Subnet Forwarding: An AC with interest in (S,G) is | |||
connected to a segment of BD2, where BD2 is different than | connected to a segment of BD2, where BD2 is different than | |||
BD1. If PE1 is the DF for that segment (or if the segment is | BD1. If PE1 is the DF for that segment (or if the segment is | |||
not multi&nbhy;homed), PE1 decapsulates the IP multicast | not multihomed), PE1 decapsulates the IP multicast | |||
packet, performs any necessary IP processing (including TTL | packet, performs any necessary IP processing (including TTL | |||
decrement), then re-encapsulates the packet appropriately for | decrement), and then re-encapsulates the packet appropriately for | |||
BD2. PE1 then sends the packet on the AC. Note that after | BD2. PE1 then sends the packet on the AC. Note that after | |||
re-encapsulation, the MAC SA will be PE1's MAC address on BD2. | re-encapsulation, the MAC SA will be PE1's MAC address on BD2. | |||
The IP TTL will have been decremented by 1. | The IP TTL will have been decremented by 1. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
In addition, there may be other PEs that are interested in (S,G) | In addition, there may be other PEs that are interested in (S,G) | |||
traffic. Suppose PE2 is such a PE. Then PE1 tunnels a copy of | traffic. Suppose PE2 is such a PE. Then, PE1 tunnels a copy of | |||
the IP multicast frame (with its original MAC SA, and with no | the IP multicast frame (with its original MAC SA and with no | |||
alteration of the payload's IP header) to PE2. The tunnel | alteration of the payload's IP header) to PE2. The tunnel | |||
encapsulation contains information that PE2 can use to associate | encapsulation contains information that PE2 can use to associate | |||
the frame with an "apparent source BD". If the actual source BD | the frame with an apparent source BD. If the actual source BD | |||
of the frame is BD1, then: | of the frame is BD1, then: | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
<li> | ||||
<t> | ||||
If PE2 is attached to BD1, the tunnel encapsulation used to | If PE2 is attached to BD1, the tunnel encapsulation used to | |||
send the frame to PE2 will cause PE2 to identify BD1 as the | send the frame to PE2 will cause PE2 to identify BD1 as the | |||
apparent source BD. | apparent source BD. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
If PE2 is not attached to BD1, the tunnel encapsulation used | If PE2 is not attached to BD1, the tunnel encapsulation used | |||
to send the frame to PE2 will cause PE2 to identify the SBD as | to send the frame to PE2 will cause PE2 to identify the SBD as | |||
the apparent source BD. | the apparent source BD. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
Note that the tunnel encapsulation used for a particular BD will | Note that the tunnel encapsulation used for a particular BD | |||
have been advertised in an IMET route or S&nbhy;PMSI route <xref | will have been advertised in an IMET route or a Selective | |||
target="I-D.ietf-bess-evpn-bum-procedure-updates"/> for that BD. That | Provider Multicast Service Interface (S-PMSI) route <xref | |||
route carries a PMSI | target="RFC9572" format="default"/> for that BD. That route | |||
Tunnel attribute, which specifies how packets originating from | carries a PMSI Tunnel Attribute (PTA), which specifies how packets | |||
that BD are encapsulated. This information enables the PE | originating from that BD are encapsulated. This information | |||
receiving a tunneled packet to identify the apparent source BD as | enables the PE receiving a tunneled packet to identify the | |||
stated above. See <xref target="adv_tunnels"/> for more details. | apparent source BD as stated above. See <xref | |||
</t> | target="adv_tunnels" format="default"/> for more details. | |||
<t> | </t> | |||
<t> | ||||
When PE2 receives the tunneled frame, it will forward it on any of | When PE2 receives the tunneled frame, it will forward it on any of | |||
its ACs that have interest in (S,G). | its ACs that have interest in (S,G). | |||
</t> | </t> | |||
<t> | <t> | |||
If PE2 determines from the tunnel encapsulation that the apparent | If PE2 determines from the tunnel encapsulation that the apparent | |||
source BD is BD1, then | source BD is BD1, then: | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
For those ACs that connect PE2 to BD1, the intra&nbhy;subnet | <li> | |||
<t> | ||||
For those ACs that connect PE2 to BD1, the intra-subnet | ||||
forwarding procedure described above is used, except that it | forwarding procedure described above is used, except that it | |||
is now PE2, not PE1, carrying out that procedure. Unmodified | is now PE2, not PE1, carrying out that procedure. Unmodified | |||
EVPN procedures from <xref target="RFC7432"/> are used to | EVPN procedures from <xref target="RFC7432" format="default"/> are | |||
ensure that a packet originating from a multi&nbhy;homed | used to | |||
ensure that a packet originating from a multihomed | ||||
segment is never sent back to that segment. | segment is never sent back to that segment. | |||
</t> | </t> | |||
<t> | </li> | |||
For those ACs that do not connect to BD1, the inter&nbhy;subnet | <li> | |||
<t> | ||||
For those ACs that do not connect to BD1, the inter-subnet | ||||
forwarding procedure described above is used, except that it is | forwarding procedure described above is used, except that it is | |||
now PE2, not PE1, carrying out that procedure. | now PE2, not PE1, carrying out that procedure. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
If the tunnel encapsulation identifies the apparent source BD as | If the tunnel encapsulation identifies the apparent source BD as | |||
the SBD, PE2 applies the inter&nbhy;subnet forwarding procedures | the SBD, PE2 applies the inter-subnet forwarding procedures | |||
described above to all of its ACs that have interest in the flow. | described above to all of its ACs that have interest in the flow. | |||
</t> | </t> | |||
<t> | <t> | |||
These procedures ensure that an IP multicast frame travels from its | These procedures ensure that an IP multicast frame travels from its | |||
ingress PE to all egress PEs that are interested in receiving | ingress PE to all egress PEs that are interested in receiving | |||
it. While in transit, the frame retains its original MAC SA, and | it. While in transit, the frame retains its original MAC SA, and | |||
the payload of the frame retains its original IP header. Note that | the payload of the frame retains its original IP header. Note that | |||
in all cases, when an IP multicast packet is sent from one BD to | in all cases, when an IP multicast packet is sent from one BD to | |||
another, these procedures cause its TTL to be decremented by 1. | another, these procedures cause its TTL to be decremented by 1. | |||
</t> | </t> | |||
<t> | <t> | |||
So far we have assumed that an IP multicast packet arrives at its | So far, we have assumed that an IP multicast packet arrives at its | |||
ingress PE over an AC that belongs to one of the BDs in a given | ingress PE over an AC that belongs to one of the BDs in a given | |||
Tenant Domain. However, it is possible for a packet to arrive at | Tenant Domain. However, it is possible for a packet to arrive at | |||
its ingress PE in other ways. Since an EVPN&nbhy;PE supporting IRB | its ingress PE in other ways. Since an EVPN PE supporting IRB | |||
has an IP&nbhy;VRF, it is possible that the IP&nbhy;VRF will have a | has an IP-VRF, it is possible that the IP-VRF will have a | |||
"VRF interface" that is not an IRB interface. For example, there | VRF interface that is not an IRB interface. For example, there | |||
might be a VRF interface that is actually a physical link to an | might be a VRF interface that is actually a physical link to an | |||
external Ethernet switch, or to a directly attached host, or to a | external Ethernet switch, a directly attached host, or a | |||
router. When an EVPN&nbhy;PE, say PE1, receives a packet through | router. When an EVPN PE, say PE1, receives a packet through | |||
such means, we will say that the packet has an "external" source | such means, we will say that the packet has an external source | |||
(i.e., a source "outside the Tenant Domain"). There are also other | (i.e., a source outside the Tenant Domain). There are also other | |||
scenarios in which a multicast packet might have an external | scenarios in which a multicast packet might have an external | |||
source, e.g., it might arrive over an MVPN tunnel from an L3VPN | source, e.g., it might arrive over an MVPN tunnel from an L3VPN | |||
PE. In such cases, we will still refer to PE1 as the "ingress | PE. In such cases, we will still refer to PE1 as the "ingress | |||
EVPN&nbhy;PE". | EVPN PE". | |||
</t> | </t> | |||
<t> | <t> | |||
When an EVPN&nbhy;PE, say PE1, receives an externally sourced | When an EVPN PE, say PE1, receives an externally sourced | |||
multicast packet, and there are receivers for that packet inside | multicast packet, and there are receivers for that packet inside | |||
the Tenant Domain, it does the following: | the Tenant Domain, it does the following: | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
Suppose PE1 has an AC in BD1 that has interest in (S,G). Then | <li> | |||
<t> | ||||
Suppose PE1 has an AC in BD1 that has interest in (S,G). Then, | ||||
PE1 encapsulates the packet for BD1, filling in the MAC SA | PE1 encapsulates the packet for BD1, filling in the MAC SA | |||
field with PE1's own MAC address on BD1. It sends the | field with PE1's own MAC address on BD1. It sends the | |||
resulting frame on the AC. | resulting frame on the AC. | |||
</t> | </t> | |||
<t> | </li> | |||
Suppose some other EVPN&nbhy;PE, say PE2, has interest in | <li> | |||
<t> | ||||
Suppose some other EVPN PE, say PE2, has interest in | ||||
(S,G). PE1 encapsulates the packet for Ethernet, filling in | (S,G). PE1 encapsulates the packet for Ethernet, filling in | |||
the MAC SA field with PE1's own MAC address on the SBD. PE1 | the MAC SA field with PE1's own MAC address on the SBD. PE1 | |||
then tunnels the packet to PE2. The tunnel encapsulation will | then tunnels the packet to PE2. The tunnel encapsulation will | |||
identify the apparent source BD as the SBD. Since the apparent | identify the apparent source BD as the SBD. Since the apparent | |||
source BD is the SBD, PE2 will know to treat the frame as an | source BD is the SBD, PE2 will know to treat the frame as an | |||
inter&nbhy;subnet multicast. | inter-subnet multicast. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
When ingress replication is used to transmit IP multicast frames | When IR is used to transmit IP multicast frames | |||
from an ingress EVPN&nbhy;PE to a set of egress PEs, then | from an ingress EVPN PE to a set of egress PEs, then | |||
the ingress PE has to send multiple copies of the frame. Each copy | the ingress PE has to send multiple copies of the frame. Each copy | |||
is the original Ethernet frame; decapsulation and IP processing | is the original Ethernet frame; decapsulation and IP processing | |||
take place only at the egress PE. | take place only at the egress PE. | |||
</t> | </t> | |||
<t> | <t> | |||
If a Point-to-Multipoint (P2MP) tree or BIER <xref | If a P2MP tree or Bit Index Explicit Replication (BIER) <xref target=" | |||
target="I-D.ietf-bier-evpn"/> is used to transmit an IP multicast fram | I-D.ietf-bier-evpn" format="default"/> is used to transmit an IP multicast frame | |||
e | ||||
from an ingress PE to a set of egress PEs, then the ingress PE | from an ingress PE to a set of egress PEs, then the ingress PE | |||
only has to send one copy of the frame to each of its next hops. | only has to send one copy of the frame to each of its next hops. | |||
Again, each egress PE receives the original frame and does any | Again, each egress PE receives the original frame and does any | |||
necessary IP processing. | necessary IP processing. | |||
</t> | </t> | |||
</section> <!-- dp_overview --> | </section> | |||
</section> <!-- model_overview --> | </section> | |||
</section> <!-- Introduction --> | </section> | |||
<section anchor="model_detail" numbered="true" toc="default"> | ||||
<section title="Detailed Model of Operation" | <name>Detailed Model of Operation</name> | |||
anchor="model_detail"> | ||||
<t> | <t> | |||
The model described in <xref target="dp_overview"/> can be expressed | The model described in <xref target="dp_overview" format="default"/> can | |||
more precisely using the notion of "IRB interface" (see <xref | be expressed | |||
target="irb"/>). For a given Tenant Domain: | more precisely using the notion of IRB interface (see <xref target="irb" | |||
<list style="symbols"> | format="default"/>). For a given Tenant Domain: | |||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | <t> | |||
A given PE has one IRB interface for each BD to which it is attached . | A given PE has one IRB interface for each BD to which it is attached . | |||
This IRB interface connects L3 routing to that BD. When | This IRB interface connects L3 routing to that BD. When | |||
IP multicast packets are sent or received on the IRB interfaces, | IP multicast packets are sent or received on the IRB interfaces, | |||
the semantics of the interface is modified from the semantics | the semantics of the interface are modified from the semantics | |||
described in <xref target="irb"/>. See <xref | described in <xref target="irb" format="default"/>. See <xref targe | |||
target="ingress_irb_use"/> for the details of the modification. | t="ingress_irb_use" format="default"/> for the details of the modification. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
Each PE also has an IRB interface that connects L3 routing to | Each PE also has an IRB interface that connects L3 routing to | |||
the SBD. The semantics of this interface is different than the | the SBD. The semantics of this interface is different than the | |||
semantics of the IRB interface to the real BDs. See <xref | semantics of the IRB interface to the real BDs. See <xref target="in | |||
target="ingress_irb_use"/>. | gress_irb_use" format="default"/>. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
In this section we assume that PIM is not enabled on the IRB | In this section, we assume that PIM is not enabled on the IRB | |||
interfaces. In general, it is not necessary to enable PIM on the | interfaces. In general, it is not necessary to enable PIM on the | |||
IRB interfaces unless there are PIM routers on one of the Tenant | IRB interfaces unless there are PIM routers on one of the Tenant | |||
Domain's BDs, or unless there is some other scenario requiring a | Domain's BDs or there is some other scenario requiring a | |||
Tenant Domain's L3 routing instance to become a PIM adjacency of | Tenant Domain's L3 routing instance to become a PIM adjacency of | |||
some other system. These cases will be discussed in <xref | some other system. These cases will be discussed in <xref target="pim" | |||
target="pim"/>. | format="default"/>. | |||
</t> | </t> | |||
<section anchor="sbd_intro" numbered="true" toc="default"> | ||||
<section title="Supplementary Broadcast Domain" anchor="sbd_intro"> | <name>Supplementary Broadcast Domain</name> | |||
<t> | <t> | |||
Suppose a given Tenant Domain contains three BDs (BD1, BD2, BD3) and | Suppose a given Tenant Domain contains three BDs (BD1, BD2, and BD3) and | |||
two PEs (PE1, PE2). PE1 attaches to BD1 and BD2, while PE2 attaches | two PEs (PE1 and PE2). PE1 attaches to BD1 and BD2, while PE2 attaches | |||
to BD2 and BD3. | to BD2 and BD3. | |||
</t> | </t> | |||
<t> | <t> | |||
To carry out the procedures described above, all the PEs attached to | To carry out the procedures described above, all the PEs attached to | |||
the Tenant Domain must be provisioned with the SBD for that tenant | the Tenant Domain must be provisioned with the SBD for that Tenant | |||
domain. A Route Target (RT) must be associated with the SBD, and | Domain. A RT must be associated with the SBD and | |||
provisioned on each of those PEs. We will refer to that RT as the | provisioned on each of those PEs. We will refer to that RT as the | |||
"SBD&nbhy;RT". | "SBD-RT". | |||
</t> | </t> | |||
<t> | <t> | |||
A Tenant Domain is also configured with an IP&nbhy;VRF <xref | A Tenant Domain is also configured with an IP-VRF <xref target="RFC9135" | |||
target="RFC9135"/>, and the IP&nbhy;VRF is associated with an RT. | format="default"/>, and the IP-VRF is associated with an RT. | |||
This RT MAY be the same as the SBD&nbhy;RT. | This RT <bcp14>MAY</bcp14> be the same as the SBD-RT. | |||
</t> | </t> | |||
<t> | <t> | |||
Suppose an (S,G) multicast frame originating on BD1 has a receiver | Suppose an (S,G) multicast frame originating on BD1 has a receiver | |||
on BD3. PE1 will transmit the packet to PE2 as a frame, and the | on BD3. PE1 will transmit the packet to PE2 as a frame, and the | |||
encapsulation will identify the frame's source BD as BD1. Since PE2 | encapsulation will identify the frame's source BD as BD1. Since PE2 | |||
is not provisioned with BD1, it will treat the packet as if its | is not provisioned with BD1, it will treat the packet as if its | |||
source BD were the SBD. That is, a packet can be transmitted from | source BD were the SBD. That is, a packet can be transmitted from | |||
BD1 to BD3 even though its ingress PE is not configured for BD3, | BD1 to BD3 even though its ingress PE is not configured for BD3 | |||
and/or its egress PE is not configured for BD1. | and/or its egress PE is not configured for BD1. | |||
</t> | </t> | |||
<t> | <t> | |||
EVPN supports service models in which a given EVPN Instance (EVI) | EVPN supports service models in which a given EVI | |||
can contain only one BD. It also supports service models in which a | can contain only one BD. It also supports service models in which a | |||
given EVI can contain multiple BDs. No matter which service model | given EVI can contain multiple BDs. No matter which service model | |||
is being used for a particular tenant, it is highly RECOMMENDED that | is being used for a particular tenant, it is highly <bcp14>RECOMMENDED</ bcp14> that | |||
an EVI containing only the SBD be provisioned for that tenant. | an EVI containing only the SBD be provisioned for that tenant. | |||
</t> | </t> | |||
<t> | <t> | |||
If, for some reason, it is not feasible to provision an EVI that | If, for some reason, it is not feasible to provision an EVI that | |||
contains only the SBD, it is possible to put the SBD in an EVI that | contains only the SBD, it is possible to put the SBD in an EVI that | |||
contains other BDs. However, in that case, the SBD&nbhy;RT MUST be | contains other BDs. However, in that case, the SBD-RT <bcp14>MUST</bcp1 | |||
different than the RT associated with any other BD. Otherwise the | 4> be | |||
procedures of this document (as detailed in Sections <xref | different than the RT associated with any other BD. Otherwise, the | |||
target="bd_route" format="counter"/> and <xref target="sbd_rts" | procedures of this document (as detailed in Sections <xref target="bd_ro | |||
format="counter"/>) will not produce correct results. | ute" format="counter"/> and <xref target="sbd_rts" format="counter"/>) will not | |||
</t> | produce correct results. | |||
</section> <!-- sbd --> | </t> | |||
</section> | ||||
<section title="Detecting When a Route is For/From a Particular BD" | <section anchor="bd_route" numbered="true" toc="default"> | |||
anchor="bd_route"> | <name>Detecting When a Route is for/from a Particular BD</name> | |||
<t> | <t> | |||
In this document, we frequently say that a particular multicast | In this document, we frequently say that a particular multicast | |||
route is "from" a particular BD, or is "for" a particular BD, | route is "from" or "for" a particular BD or is "related to" or | |||
or is "related to" a particular BD, or "is | "associated with" a particular BD. These terms are used | |||
associated with" a particular BD. These terms are used | ||||
interchangeably. Subsequent sections of this document explain when | interchangeably. Subsequent sections of this document explain when | |||
various routes must be originated for particular BDs. In this | various routes must be originated for particular BDs. In this | |||
section, we explain how the PE originating a route marks the route | section, we explain how the PE originating a route marks the route | |||
to indicate which BD it is for. We also explain how a PE | to indicate which BD it is for. We also explain how a PE | |||
receiving the route determines which BD the route is for. | receiving the route determines which BD the route is for. | |||
</t> | </t> | |||
<t> | <t> | |||
In EVPN, each BD is assigned a Route Target (RT). An RT is a BGP | In EVPN, each BD is assigned a RT. An RT is a BGP | |||
extended community that can be attached to the BGP routes used by | Extended Community that can be attached to the BGP routes used by | |||
the EVPN control plane. In some EVPN service models, each BD is | the EVPN control plane. In some EVPN service models, each BD is | |||
assigned a unique RT. In other service models, a set of BDs (all in | assigned a unique RT. In other service models, a set of BDs (all in | |||
the same EVI) may be assigned the same RT. The RT that is assigned | the same EVI) may be assigned the same RT. The RT that is assigned | |||
to the SBD is called the "SBD&nbhy;RT". | to the SBD is called the "SBD-RT". | |||
</t> | </t> | |||
<t> | <t> | |||
In those service models that allow a set of BDs to share a single | In those service models that allow a set of BDs to share a single | |||
RT, each BD is assigned a non&nbhy;zero Tag ID. The Tag ID appears | RT, each BD is assigned a non-zero Tag ID. The Tag ID appears | |||
in the Network Layer Reachability Information (NLRI) of many of the | in the Network Layer Reachability Information (NLRI) of many of the | |||
BGP routes that are used by the EVPN control plane. | BGP routes that are used by the EVPN control plane. | |||
</t> | </t> | |||
<t> | <t> | |||
A given route may be for the SBD, or for an "ordinary BD" (a BD | A given route may be for the SBD or an ordinary BD (a BD | |||
that is not the SBD). An RT that has been assigned to an ordinary | that is not the SBD). An RT that has been assigned to an ordinary | |||
BD will be known as an "ordinary BD&nbhy;RT". | BD will be known as an "ordinary BD-RT". | |||
</t> | </t> | |||
<t> | <t> | |||
When constructing an IMET, SMET, S&nbhy;PMSI, or Leaf <xref target="I-D. | When constructing an IMET, SMET, S-PMSI, or Leaf <xref target="RFC9572" | |||
ietf-bess-evpn-bum-procedure-updates"/> route that is for a given BD, | format="default"/> route that is for a given BD, | |||
the following rules apply: | the following rules apply: | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
If the route is for an ordinary BD, say BD1, then | <li> | |||
<list style="symbols"> | <t> | |||
<t> | If the route is for an ordinary BD, say BD1, then: | |||
the route MUST carry the ordinary BD&nbhy;RT associated with | </t> | |||
BD1, and | <ul spacing="normal"> | |||
</t> | <li> | |||
<t> | <t> | |||
the route MUST NOT carry any RT that is associated with an | the route <bcp14>MUST</bcp14> carry the ordinary BD-RT associate | |||
d with | ||||
BD1 and | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
the route <bcp14>MUST NOT</bcp14> carry any RT that is associate | ||||
d with an | ||||
ordinary BD other than BD1. | ordinary BD other than BD1. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | </li> | |||
If the route is for the SBD, the route MUST carry the SBD&nbhy;RT, | <li> | |||
and MUST NOT carry any RT that is associated with any other BD. | <t> | |||
</t> | If the route is for the SBD, the route <bcp14>MUST</bcp14> carry the | |||
<t> | SBD-RT | |||
As detailed in subsequent sections, under certain circumstances | and <bcp14>MUST NOT</bcp14> carry any RT that is associated with any | |||
other BD. | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
As detailed in subsequent sections, under certain circumstances, | ||||
a route that is for BD1 may carry both the RT of BD1 and also | a route that is for BD1 may carry both the RT of BD1 and also | |||
the SBD&nbhy;RT. | the SBD-RT. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t>The IMET route for the SBD MUST carry a Multicast Flags Extended | <t>The IMET route for the SBD <bcp14>MUST</bcp14> carry a Multicast Flag | |||
Community, in which an "OISM SBD" flag is set. | s Extended | |||
</t> | Community in which an OISM SBD flag is set. | |||
<t>The IMET route for a BD other than the SBD SHOULD carry an EVI-RT EC | </t> | |||
as defined in <xref target="RFC9251"/>. The EC is constructed | <t>The IMET route for a BD other than the SBD <bcp14>SHOULD</bcp14> carr | |||
from the SBD&nbhy;RT, to indicate the BD's corresponding SBD. | y an EVI-RT EC | |||
as defined in <xref target="RFC9251" format="default"/>. The EC is cons | ||||
tructed | ||||
from the SBD-RT to indicate the BD's corresponding SBD. | ||||
This allows all PEs to check that they have consistent SBD provisioning | This allows all PEs to check that they have consistent SBD provisioning | |||
and allow an Assisted Replication (AR) replicator to automatically | and allows an Assisted Replication (AR) replicator to automatically | |||
determine a BD's | determine a BD's corresponding SBD without any provisioning, as explain | |||
corresponding SBD without any provisioning, as explained in | ed in | |||
<xref target="SBD-matching"/>. | <xref target="SBD-matching" format="default"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
When receiving an IMET, SMET, S&nbhy;PMSI, or Leaf route, it is necessar | When receiving an IMET, SMET, S-PMSI, or Leaf route, it is necessary | |||
y | ||||
for the receiving PE to determine the BD to which the route belongs. | for the receiving PE to determine the BD to which the route belongs. | |||
This is done by examining the RTs carried by the route, as well as | This is done by examining the RTs carried by the route, as well as | |||
the Tag ID field of the route's NLRI. There are several cases to | the Tag ID field of the route's NLRI. There are several cases to | |||
consider. Some of these cases are error cases that arise when the | consider. Some of these cases are error cases that arise when the | |||
route has not been properly constructed. | route has not been properly constructed. | |||
</t> | </t> | |||
<t> | <t> | |||
When one of the error cases is detected, the route MUST be regarded | When one of the error cases is detected, the route <bcp14>MUST</bcp14> b | |||
as a malformed route, and the "treat-as-withdraw" procedure of <xref | e regarded | |||
target="RFC7606"/> MUST be applied. Note that these error | as a malformed route, and the treat-as-withdraw procedure of <xref targe | |||
t="RFC7606" format="default"/> <bcp14>MUST</bcp14> be applied. Note that these | ||||
error | ||||
cases are only detectable by EVPN procedures at the receiving PE; | cases are only detectable by EVPN procedures at the receiving PE; | |||
BGP procedures at intermediate nodes will generally not detect the | BGP procedures at intermediate nodes will generally not detect the | |||
existence of such error cases, and in general SHOULD NOT attempt to | existence of such error cases and in general <bcp14>SHOULD NOT</bcp14> a ttempt to | |||
do so. | do so. | |||
</t> | </t> | |||
<t> | <ol spacing="normal" type="Case %d:"><li> | |||
<list style="format Case %d:"> | <t> | |||
<t> | ||||
The receiving PE recognizes more than one of the route's RTs as | The receiving PE recognizes more than one of the route's RTs as | |||
being an SBD&nbhy;RT (i.e., the route carries SBD&nbhy;RTs of | being an SBD-RT (i.e., the route carries SBD-RTs of | |||
more than one Tenant Domain). | more than one Tenant Domain). | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
This is an error case; the route has not been properly | This is an error case; the route has not been properly | |||
constructed. | constructed. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The receiving PE recognizes one of the route's RTs as being | The receiving PE recognizes one of the route's RTs as being | |||
associated with an ordinary BD, and recognizes one of the | associated with an ordinary BD and recognizes one of the | |||
route's other RTs as being associated with a different ordinary | route's other RTs as being associated with a different ordinary | |||
BD. | BD. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
This is an error case; the route has not been properly | This is an error case; the route has not been properly | |||
constructed. | constructed. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The receiving PE recognizes one of the route's RTs as being | The receiving PE recognizes one of the route's RTs as being | |||
associated with an ordinary BD in a particular Tenant Domain, | associated with an ordinary BD in a particular Tenant Domain | |||
and recognizes another of the route's RTs as being associated | and recognizes another of the route's RTs as being associated | |||
with the SBD of a different Tenant Domain. | with the SBD of a different Tenant Domain. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
This is an error case; the route has not been properly | This is an error case; the route has not been properly | |||
constructed. | constructed. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The receiving PE does not recognize any of the route's RTs as | The receiving PE does not recognize any of the route's RTs as | |||
being associated with an ordinary BD in any of its tenant | being associated with an ordinary BD in any of its Tenant | |||
domains, but does recognize one of the RTs as the SBD&nbhy;RT | Domains but does recognize one of the RTs as the SBD-RT | |||
of one of its Tenant Domains. | of one of its Tenant Domains. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
In this case, the receiving PE associates the route with the SBD of | In this case, the receiving PE associates the route with the SBD of | |||
that Tenant Domain. This association is made even if the Tag ID | that Tenant Domain. This association is made even if the Tag ID | |||
field of the route's NLRI is not the Tag ID of the SBD. | field of the route's NLRI is not the Tag ID of the SBD. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
This is a normal use case where either (a) the route is for a BD | This is a normal use case where either (a) the route is for a BD | |||
to which the receiving PE is not attached, or (b) the route is | to which the receiving PE is not attached or (b) the route is | |||
for the SBD. In either case, the receiving PE associates the | for the SBD. In either case, the receiving PE associates the | |||
route with the SBD. | route with the SBD. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The receiving PE recognizes exactly one of the RTs as an | The receiving PE recognizes exactly one of the RTs as an | |||
ordinary BD&nbhy;RT that is associated with one of the PE's | ordinary BD-RT that is associated with one of the PE's | |||
EVIs, say EVI&nbhy;1. The receiving PE also recognizes one of | EVIs, say EVI-1. The receiving PE also recognizes one of | |||
the RTs as being the SBD&nbhy;RT of the Tenant Domain containing | the RTs as being the SBD-RT of the Tenant Domain containing | |||
EVI&nbhy;1. | EVI-1. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
In this case, the route is associated with the BD in EVI&nbhy;1 | In this case, the route is associated with the BD in EVI-1 | |||
that is identified (in the context of EVI&nbhy;1) by the Tag ID | that is identified (in the context of EVI-1) by the Tag ID | |||
field of the route's NLRI. (If EVI&nbhy;1 contains only a | field of the route's NLRI. (If EVI-1 contains only a | |||
single BD, the Tag ID is likely to be zero.) | single BD, the Tag ID is likely to be zero.) | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
This is the case where the route is for a BD to which the | This is the case where the route is for a BD to which the | |||
receiving PE is attached, but the route also carries the | receiving PE is attached, but the route also carries the | |||
SBD&nbhy;RT. In this case, the receiving PE associates the route | SBD-RT. In this case, the receiving PE associates the route | |||
with the ordinary BD, not with the SBD. | with the ordinary BD, not with the SBD. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ol> | |||
<t> | <t> | |||
N.B.: According to the above rules, the mapping from BD to RT is a | Note that according to the above rules, the mapping from BD to RT is a | |||
many-to-one or one-to-one mapping. A route that an EVPN&nbhy;PE | many-to-one or one-to-one mapping. A route that an EVPN PE | |||
originates for a particular BD carries that BD's RT, and an | originates for a particular BD carries that BD's RT, and an | |||
EVPN&nbhy;PE that receives the route associates it with a BD as | EVPN PE that receives the route associates it with a BD as | |||
described above. However, RTs are not used only to help identify | described above. However, RTs are not used only to help identify | |||
the BD to which a route belongs; they may also used by BGP to | the BD to which a route belongs; they may also be used by BGP to | |||
determine the path along which the route is distributed, and to | determine the path along which the route is distributed and to | |||
determine which PEs receive the route. There may be cases where it | determine which PEs receive the route. There may be cases where it | |||
is desirable to originate a route for a particular BD, but have | is desirable to originate a route for a particular BD but have | |||
that route distributed to only some of the EVPN&nbhy;PEs attached to | that route distributed to only some of the EVPN PEs attached to | |||
that BD. Or one might want the route distributed to some | that BD. Or one might want the route distributed to some | |||
intermediate set of systems, where it might be modified or replaced | intermediate set of systems, where it might be modified or replaced | |||
before being propagated further. Such situations are outside the | before being propagated further. Such situations are outside the | |||
scope of this document. | scope of this document. | |||
</t> | </t> | |||
<t> | <t> | |||
Additionally, there may be situations where it is desirable to | Additionally, there may be situations where it is desirable to | |||
exchange routes among two or more different Tenant Domains ("EVPN | exchange routes among two or more different Tenant Domains (EVPN | |||
Extranet"). Such situations are outside the scope of this document. | Extranet). Such situations are outside the scope of this document. | |||
</t> | </t> | |||
<!-- <t> --> | ||||
<!-- A route is for a particular BD if it carries the RT that has been - | ||||
-> | ||||
<!-- assigned to that BD, and its NLRI contains the Tag ID that has been | ||||
--> | ||||
<!-- assigned to that BD. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Note that a route that is for a particular BD may also carry --> | ||||
<!-- additional RTs. --> | ||||
<!-- </t> --> | ||||
</section> | </section> | |||
<section anchor="ingress_irb_use" numbered="true" toc="default"> | ||||
<section title="Use of IRB Interfaces at Ingress PE" | <name>Use of IRB Interfaces at Ingress PE</name> | |||
anchor="ingress_irb_use"> | <t> | |||
<t> | ||||
When an (S,G) multicast frame is received from an AC belonging to a | When an (S,G) multicast frame is received from an AC belonging to a | |||
particular BD, say BD1: | particular BD, say BD1: | |||
<list style="format %d."> | </t> | |||
<t anchor="inter-PE"> | <ol spacing="normal" type="1"><li anchor="inter-PE"> | |||
The frame is sent unchanged to other EVPN&nbhy;PEs that are | <t> | |||
The frame is sent unchanged to other EVPN PEs that are | ||||
interested in (S,G) traffic. The encapsulation used to send the | interested in (S,G) traffic. The encapsulation used to send the | |||
frame to the other EVPN&nbhy;PEs depends on the tunnel type | frame to the other EVPN PEs depends on the tunnel type | |||
being used for multicast transmission. (For our purposes, we | being used for multicast transmission. (For our purposes, we | |||
consider Ingress Replication (IR), Assisted Replication (AR) and | consider IR, AR, and | |||
BIER to be "tunnel types", even though IR, AR and BIER do not | BIER to be tunnel types, even though IR, AR, and BIER do not | |||
actually use P2MP tunnels.) At the egress PE, the apparent | actually use P2MP tunnels.) At the egress PE, the apparent | |||
source BD of the frame can be inferred from the tunnel | source BD of the frame can be inferred from the tunnel | |||
encapsulation. If the egress PE is not attached to the actual | encapsulation. If the egress PE is not attached to the actual | |||
source BD, it will infer that the apparent source BD is the SBD. | source BD, it will infer that the apparent source BD is the SBD. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
Note that the the inter&nbhy;PE transmission of a multicast | Note that the inter-PE transmission of a multicast | |||
frame among EVPN&nbhy;PEs of the same Tenant Domain does NOT | frame among EVPN PEs of the same Tenant Domain does NOT | |||
involve the IRB interfaces, as long as the multicast frame was | involve the IRB interfaces as long as the multicast frame was | |||
received over an AC attached to one of the Tenant Domain's BDs. | received over an AC attached to one of the Tenant Domain's BDs. | |||
</t> | </t> | |||
<t anchor="up_IRB"> | </li> | |||
<li anchor="up_IRB"> | ||||
<t> | ||||
The frame is also sent up the IRB interface that attaches BD1 to | The frame is also sent up the IRB interface that attaches BD1 to | |||
the Tenant Domain's L3 routing instance in this PE. That is, | the Tenant Domain's L3 routing instance in this PE. That is, | |||
the L3 routing instance, behaving as if it were a multicast | the L3 routing instance, behaving as if it were a multicast | |||
router, receives the IP multicast frames that arrive at the PE | router, receives the IP multicast frames that arrive at the PE | |||
from its local ACs. The L3 routing instance decapsulates the | from its local ACs. The L3 routing instance decapsulates the | |||
frame's payload to extract the IP multicast packet, decrements | frame's payload to extract the IP multicast packet, decrements | |||
the IP TTL, adjusts the header checksum, and does any other | the IP TTL, adjusts the header checksum, and does any other | |||
necessary IP processing (e.g., fragmentation). | necessary IP processing (e.g., fragmentation). | |||
</t> | </t> | |||
<t anchor="down_IRB"> | </li> | |||
<li anchor="down_IRB"> | ||||
<t> | ||||
The L3 routing instance keeps track of which BDs have local | The L3 routing instance keeps track of which BDs have local | |||
receivers for (S,G) traffic. (A "local receiver" is a TS, | receivers for (S,G) traffic. (A local receiver is a TS, | |||
reachable via a local AC, that has expressed interest in (S,G) | reachable via a local AC, that has expressed interest in (S,G) | |||
traffic.) If the L3 routing instance has an IRB interface to | traffic.) If the L3 routing instance has an IRB interface to | |||
BD2, and it knows that BD2 has a LOCAL receiver interested in | BD2, and it knows that BD2 has a LOCAL receiver interested in | |||
(S,G) traffic, it encapsulates the packet in an Ethernet header | (S,G) traffic, it encapsulates the packet in an Ethernet header | |||
for BD2, putting its own MAC address in the MAC SA field. Then | for BD2, putting its own MAC address in the MAC SA field. Then, | |||
it sends the packet down the IRB interface to BD2. | it sends the packet down the IRB interface to BD2. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ol> | |||
<t> | <t> | |||
If a packet is sent from the L3 routing instance to a particular | If a packet is sent from the L3 routing instance to a particular | |||
BD via the IRB interface (step <xref target="down_IRB" | BD via the IRB interface (step <xref target="down_IRB" format="counter"/ | |||
format="counter"/> in the above list), and if the BD in question is | > in the above list), and if the BD in question is | |||
NOT the SBD, the packet is sent ONLY to LOCAL ACs of that BD. If | NOT the SBD, the packet is sent ONLY to LOCAL ACs of that BD. If | |||
the packet needs to go to other PEs, it has already been sent to | the packet needs to go to other PEs, it has already been sent to | |||
them in step <xref target="inter-PE" format="counter"/>. Note that | them in step <xref target="inter-PE" format="counter"/>. Note that | |||
this is a change in the IRB interface semantics from what is | this is a change in the IRB interface semantics from what is | |||
described in <xref target="RFC9135"/> and <xref target="IRB"/>. | described in <xref target="RFC9135" format="default"/> and <xref target= | |||
</t> | "IRB" format="default"/>. | |||
<t> | </t> | |||
If a given locally attached segment is multi-homed, existing EVPN | <t> | |||
If a given locally attached segment is multihomed, existing EVPN | ||||
procedures ensure that a packet is not sent by a given PE to that | procedures ensure that a packet is not sent by a given PE to that | |||
segment unless the PE is the DF for that segment. Those procedures | segment unless the PE is the DF for that segment. Those procedures | |||
also ensure that a packet is never sent by a PE to its segment of | also ensure that a packet is never sent by a PE to its segment of | |||
origin. Thus EVPN segment multi-homing is fully supported; | origin. Thus, EVPN segment multihoming is fully supported; | |||
duplicate delivery to a segment or looping on a segment are thereby | duplicate delivery to a segment or looping on a segment are thereby | |||
prevented, without the need for any new procedures to be defined in | prevented without the need for any new procedures to be defined in | |||
this document. | this document. | |||
</t> | </t> | |||
<t> | <t> | |||
What if an IP multicast packet is received from outside the tenant | What if an IP multicast packet is received from outside the Tenant | |||
domain? For instance, perhaps PE1's IP&nbhy;VRF for a particular | Domain? For instance, perhaps PE1's IP-VRF for a particular | |||
tenant domain also has a physical interface leading to an external | Tenant Domain also has a physical interface leading to an external | |||
switch, host, or router, and PE1 receives an IP multicast packet or | switch, host, or router and PE1 receives an IP multicast packet or | |||
frame on that interface. Or perhaps the packet is from an L3VPN, or | frame on that interface, or perhaps the packet is from an L3VPN or | |||
a different EVPN Tenant Domain. | a different EVPN Tenant Domain. | |||
</t> | </t> | |||
<t> | <t> | |||
Such a packet is first processed by the L3 routing instance, which | Such a packet is first processed by the L3 routing instance, which | |||
decrements TTL and does any other necessary IP processing. Then the | decrements TTL and does any other necessary IP processing. Then, the | |||
packet is sent into the Tenant Domain by sending it down the IRB | packet is sent into the Tenant Domain by sending it down the IRB | |||
interface to the SBD of that Tenant Domain. This requires | interface to the SBD of that Tenant Domain. This requires | |||
encapsulating the packet in an Ethernet header. The MAC SA field | encapsulating the packet in an Ethernet header. The MAC SA field | |||
will contain the PE's own MAC on the SBD. | will contain the PE's own MAC on the SBD. | |||
</t> | </t> | |||
<t> | <t> | |||
An IP multicast packet sent by the L3 routing instance down the IRB | An IP multicast packet sent by the L3 routing instance down the IRB | |||
interface to the SBD is treated as if it had arrived from a local | interface to the SBD is treated as if it had arrived from a local | |||
AC, and steps <xref target="inter-PE" format="counter"/>&nbhy;<xref | AC, and steps <xref target="inter-PE" format="counter"/>-<xref target="d | |||
target="down_IRB" format="counter"/> are applied. Note that the | own_IRB" format="counter"/> are applied. Note that the | |||
semantics of sending a packet down the IRB interface to the SBD are | semantics of sending a packet down the IRB interface to the SBD are | |||
thus slightly different than the semantics of sending a packet down | thus slightly different than the semantics of sending a packet down | |||
other IRB interfaces. IP multicast packets sent down the SBD's IRB | other IRB interfaces. IP multicast packets sent down the SBD's IRB | |||
interface may be distributed to other PEs, but IP multicast packets | interface may be distributed to other PEs, but IP multicast packets | |||
sent down other IRB interfaces are distributed only to local ACs. | sent down other IRB interfaces are distributed only to local ACs. | |||
</t> | </t> | |||
<t> | <t> | |||
If a PE sends a link&nbhy;local multicast packet down the SBD IRB | If a PE sends a link-local multicast packet down the SBD IRB | |||
interface, that packet will be distributed (as an Ethernet frame) to | interface, that packet will be distributed (as an Ethernet frame) to | |||
other PEs of the Tenant Domain, but will not appear on any of the | other PEs of the Tenant Domain but will not appear on any of the | |||
actual BDs. | actual BDs. | |||
</t> | </t> | |||
</section> <!-- ingress_irb_use --> | </section> | |||
<section title="Use of IRB Interfaces at an Egress PE" | <section anchor="egress_irb_use" numbered="true" toc="default"> | |||
anchor="egress_irb_use"> | <name>Use of IRB Interfaces at an Egress PE</name> | |||
<t> | <t> | |||
Suppose an egress EVPN&nbhy;PE receives an (S,G) multicast frame | Suppose an egress EVPN PE receives an (S,G) multicast frame | |||
from the frame's ingress EVPN&nbhy;PE. As described above, the | from the frame's ingress EVPN PE. As described above, the | |||
packet will arrive as an Ethernet frame over a tunnel from the | packet will arrive as an Ethernet frame over a tunnel from the | |||
ingress PE, and the tunnel encapsulation will identify the source BD | ingress PE, and the tunnel encapsulation will identify the source BD | |||
of the Ethernet frame. | of the Ethernet frame. | |||
</t> | </t> | |||
<t> | <t> | |||
We define the notion of the frame's "apparent source BD" as follows. | We define the notion of the frame's apparent source BD as follows. | |||
If the egress PE is attached to the actual source BD, the actual | If the egress PE is attached to the actual source BD, the actual | |||
source BD is the apparent source BD. If the egress PE is not | source BD is the apparent source BD. If the egress PE is not | |||
attached to the actual source BD, the SBD is the apparent source BD. | attached to the actual source BD, the SBD is the apparent source BD. | |||
</t> | </t> | |||
<t> | <t> | |||
The egress PE now takes the following steps: | The egress PE now takes the following steps: | |||
<list style="format %d."> | </t> | |||
<t> | <ol spacing="normal" type="1"><li> | |||
<t> | ||||
If the egress PE has ACs belonging to the apparent source BD of | If the egress PE has ACs belonging to the apparent source BD of | |||
the frame, it sends the frame unchanged to any ACs of that BD | the frame, it sends the frame unchanged to any ACs of that BD | |||
that have interest in (S,G) packets. The MAC SA of the frame is | that have interest in (S,G) packets. The MAC SA of the frame is | |||
not modified, and the IP header of the frame's payload is not | not modified, and the IP header of the frame's payload is not | |||
modified in any way. | modified in any way. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The frame is also sent to the L3 routing instance by being sent | The frame is also sent to the L3 routing instance by being sent | |||
up the IRB interface that attaches the L3 routing instance to | up the IRB interface that attaches the L3 routing instance to | |||
the apparent source BD. Steps <xref target="up_IRB" | the apparent source BD. Steps <xref target="up_IRB" format="counter | |||
format="counter"/> and <xref target="down_IRB" | "/> and <xref target="down_IRB" format="counter"/> listed in <xref target="ingre | |||
format="counter"/> of <xref target="ingress_irb_use"/> are then | ss_irb_use" format="default"/> are then | |||
applied. | applied. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ol> | |||
</section> <!-- egress_irb_use --> | </section> | |||
<section title="Announcing Interest in (S,G)" anchor="interest"> | <section anchor="interest" numbered="true" toc="default"> | |||
<t> | <name>Announcing Interest in (S,G)</name> | |||
<xref target="RFC9251"/> defines procedures used by an egress PE | <t> | |||
<xref target="RFC9251" format="default"/> defines procedures used by an | ||||
egress PE | ||||
to announce its interest in a multicast flow or set of flows. If an | to announce its interest in a multicast flow or set of flows. If an | |||
egress PE determines it has LOCAL receivers in a particular BD, say | egress PE determines it has LOCAL receivers in a particular BD, say | |||
BD1, that are interested in a particular set of flows, it originates | BD1, that are interested in a particular set of flows, it originates | |||
one or more SMET routes for BD1. Each SMET route specifies a | one or more SMET routes for BD1. Each SMET route specifies a | |||
particular (S,G) or (*,G) flow. By originating an SMET route for | particular (S,G) or (*,G) flow. By originating a SMET route for | |||
BD1, a PE is announcing "I have receivers for (S,G) or (*,G) in | BD1, a PE is announcing "I have receivers for (S,G) or (*,G) in | |||
BD1". Such an SMET route carries the Route Target (RT) for BD1, | BD1". Such a SMET route carries the RT for BD1, | |||
ensuring that it will be distributed to all PEs that are attached to | ensuring that it will be distributed to all PEs that are attached to | |||
BD1. | BD1. | |||
</t> | </t> | |||
<t> | <t> | |||
The OISM procedures for originating SMET routes differ slightly from | The OISM procedures for originating SMET routes differ slightly from | |||
those in <xref target="RFC9251"/>. In most cases, the SMET | those in <xref target="RFC9251" format="default"/>. In most cases, the | |||
routes are considered to be for the SBD, rather than for the BD | SMET | |||
routes are considered to be for the SBD rather than the BD | ||||
containing local receivers. These SMET routes carry the | containing local receivers. These SMET routes carry the | |||
SBD&nbhy;RT, and do not carry any ordinary BD-RT. Details on the | SBD-RT and do not carry any ordinary BD-RT. Details on the | |||
processing of SMET routes can be found in <xref target="smet_adv"/>. | processing of SMET routes can be found in <xref target="smet_adv" format | |||
</t> | ="default"/>. | |||
<t> | </t> | |||
<t> | ||||
Since the SMET routes carry the SBD-RT, every ingress PE attached to | Since the SMET routes carry the SBD-RT, every ingress PE attached to | |||
a particular Tenant Domain will learn of all other PEs (attached to | a particular Tenant Domain will learn of all other PEs (attached to | |||
the same Tenant Domain) that have interest in a particular set of | the same Tenant Domain) that have interest in a particular set of | |||
flows. Note that a PE that receives a given SMET route does not | flows. Note that a PE that receives a given SMET route does not | |||
necessarily have any BDs (other than the SBD) in common with the PE | necessarily have any BDs (other than the SBD) in common with the PE | |||
that originates that SMET route. | that originates that SMET route. | |||
</t> | </t> | |||
<t> | <t> | |||
If all the sources and receivers for a given (*,G) are in the Tenant | If all the sources and receivers for a given (*,G) are in the Tenant | |||
Domain, inter&nbhy;subnet "Any Source Multicast" traffic will be | Domain, inter-subnet ASM traffic will be | |||
properly routed without requiring any Rendezvous Points, shared | properly routed without requiring any RPs, shared | |||
trees, or other complex aspects of multicast routing infrastructure. | trees, or other complex aspects of multicast routing infrastructure. | |||
Suppose, for example, that: | Suppose, for example, that: | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
PE1 has a local receiver, on BD1, for (*,G) | <li> | |||
</t> | <t> | |||
<t> | PE1 has a local receiver, on BD1, for (*,G) and | |||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
PE2 has a local source, on BD2, for (*,G). | PE2 has a local source, on BD2, for (*,G). | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
PE1 will originate an SMET(*,G) route for the SBD, and PE2 will | PE1 will originate a SMET(*,G) route for the SBD, and PE2 will | |||
receive that route, even if PE2 is not attached to BD1. PE2 will | receive that route, even if PE2 is not attached to BD1. PE2 will | |||
thus know to forward (S,G) traffic to PE1. PE1 does not need to do | thus know to forward (S,G) traffic to PE1. PE1 does not need to do | |||
any "source discovery". (This does assume that source S does not | any source discovery. (This does assume that source S does not | |||
send the same (S,G) datagram on two different BDs, and that the | send the same (S,G) datagram on two different BDs and that the | |||
Tenant Domain does not contain two or more sources with the same IP | Tenant Domain does not contain two or more sources with the same IP | |||
address S. The use of multicast sources that have IP "anycast" | address S. The use of multicast sources that have IP anycast | |||
addresses is outside the scope of this document.) | addresses is outside the scope of this document.) | |||
</t> | </t> | |||
<t> | <t> | |||
If some PE attached to the Tenant Domain does not support | If some PE attached to the Tenant Domain does not support | |||
[RFC9251], it will be assumed to be interested in all flows. | <xref target="RFC9251"/>, it will be assumed to be interested in all flo | |||
Whether a particular remote PE supports [RFC9251] is determined | ws. | |||
Whether a particular remote PE supports <xref target="RFC9251"/> or not | ||||
is determined | ||||
by the presence of the Multicast Flags Extended Community | by the presence of the Multicast Flags Extended Community | |||
<!-- (and the --> | ||||
<!-- setting of the "IGMP Proxy" flag within the EC) --> | ||||
in its IMET route; | in its IMET route; | |||
this is specified in [RFC9251]. | this is specified in <xref target="RFC9251"/>. | |||
</t> | </t> | |||
</section> | ||||
</section> <!-- interest --> | <section anchor="tunneling" numbered="true" toc="default"> | |||
<section title="Tunneling Frames from Ingress PE to Egress PEs" | <name>Tunneling Frames from Ingress PEs to Egress PEs</name> | |||
anchor="tunneling"> | <t> | |||
<t> | <xref target="RFC7432" format="default"/> specifies the procedures for s | |||
<xref target="RFC7432"/> specifies the procedures for setting up and | etting up and | |||
using "BUM tunnels". A BUM tunnel is a tunnel used to carry traffic | using BUM tunnels. A BUM tunnel is a tunnel used to carry traffic | |||
on a particular BD if that traffic is (a) broadcast traffic, or (b) | on a particular BD if that traffic is (a) broadcast traffic, (b) | |||
unicast traffic with an unknown MAC DA, or (c) Ethernet multicast | unicast traffic with an unknown Destination MAC Address, or (c) Ethernet | |||
multicast | ||||
traffic. | traffic. | |||
</t> | </t> | |||
<t> | <t> | |||
This document allows the BUM tunnels to be used as the default | This document allows the BUM tunnels to be used as the default | |||
tunnels for transmitting IP multicast frames. It also allows a | tunnels for transmitting IP multicast frames. It also allows a | |||
separate set of tunnels to be used, instead of the BUM tunnels, as | separate set of tunnels to be used, instead of the BUM tunnels, as | |||
the default tunnels for carrying IP multicast frames. Let's call | the default tunnels for carrying IP multicast frames. Let's call | |||
these "IP Multicast Tunnels". | these "IP multicast tunnels". | |||
</t> | </t> | |||
<t> | <t> | |||
When the tunneling is done via Ingress Replication or via BIER, this | When the tunneling is done via IR or via BIER, this | |||
difference is of no significance. However, when P2MP tunnels are | difference is of no significance. However, when P2MP tunnels are | |||
used, there is a significant advantage to having separate IP | used, there is a significant advantage to having separate IP | |||
multicast tunnels. | multicast tunnels. | |||
</t> | </t> | |||
<t> | <t> | |||
Other things being equal, it is desirable for an ingress PE to | It is desirable for an ingress PE to | |||
transmit a copy of a given (S,G) multicast frame on only one P2MP | transmit a copy of a given (S,G) multicast frame on only one P2MP | |||
tunnel. All egress PEs interested in (S,G) packets then have to | tunnel. All egress PEs interested in (S,G) packets then have to | |||
join that tunnel. If the source BD and PE for an (S,G) frame are | join that tunnel. If the source BD and PE for an (S,G) frame are | |||
BD1 and PE1 respectively, and if PE2 has receivers on BD2 for (S,G), | BD1 and PE1, respectively, and if PE2 has receivers on BD2 for (S,G), | |||
then PE2 must join the P2MP LSP on which PE1 transmits the (S,G) | then PE2 must join the P2MP Label Switched Path (LSP) on which PE1 trans | |||
mits the (S,G) | ||||
frame. PE2 must join this P2MP LSP even if PE2 is not attached to | frame. PE2 must join this P2MP LSP even if PE2 is not attached to | |||
the source BD (BD1). If PE1 were transmitting the multicast frame | the source BD, BD1. If PE1 was transmitting the multicast frame | |||
on its BD1 BUM tunnel, then PE2 would have to join the BD1 BUM | on its BD1 BUM tunnel, then PE2 would have to join the BD1 BUM | |||
tunnel, even though PE2 has no BD1 attachment circuits. This would | tunnel, even though PE2 has no BD1 Attachment Circuits. This would | |||
cause PE2 to pull all the BUM traffic from BD1, most of which it | cause PE2 to pull all the BUM traffic from BD1, most of which it | |||
would just have to discard. Thus it is RECOMMENDED that the default IP | would just have to discard. Thus, it is <bcp14>RECOMMENDED</bcp14> that the default IP | |||
multicast tunnels be distinct from the BUM tunnels. | multicast tunnels be distinct from the BUM tunnels. | |||
</t> | </t> | |||
<t> | <t> | |||
Notwithstanding the above, link-local IP multicast traffic MUST | Notwithstanding the above, link-local IP multicast traffic <bcp14>MUST</ | |||
always be carried on the BUM tunnels, and ONLY on the BUM tunnels. | bcp14> | |||
link-local IP multicast traffic consists of IPv4 traffic with a | always be carried on the BUM tunnels and ONLY on the BUM tunnels. | |||
Link-local IP multicast traffic consists of IPv4 traffic with a | ||||
destination address prefix of 224/24 and IPv6 traffic with a | destination address prefix of 224/24 and IPv6 traffic with a | |||
destination address prefix of FF02/16. In this document, the terms | destination address prefix of FF02/16. In this document, the terms | |||
"IP multicast packet" and "IP multicast frame" are defined in <xref | "IP multicast packet" and "IP multicast frame" are defined in <xref targ | |||
target="terminology"/> so as to exclude link&nbhy;local traffic. | et="terminology" format="default"/> so as to exclude link-local traffic. | |||
</t> | </t> | |||
<t> | <t> | |||
Note that it is also possible to use "selective tunnels" to carry | Note that it is also possible to use selective tunnels to carry | |||
particular multicast flows (see <xref target="adv_tunnels"/>). When | particular multicast flows (see <xref target="adv_tunnels" format="defau | |||
lt"/>). When | ||||
an (S,G) frame is transmitted on a selective tunnel, it is not | an (S,G) frame is transmitted on a selective tunnel, it is not | |||
transmitted on the BUM tunnel or on the default IP Multicast tunnel. | transmitted on the BUM tunnel or on the default IP multicast tunnel. | |||
</t> | </t> | |||
</section> | ||||
</section> <!-- tunneling --> | <section anchor="adv_scen" numbered="true" toc="default"> | |||
<section title="Advanced Scenarios" anchor="adv_scen"> | <name>Advanced Scenarios</name> | |||
<t> | <t> | |||
There are some deployment scenarios that require special | There are some deployment scenarios that require special | |||
procedures: | procedures: | |||
<!-- These are discussed in detail in <xref --> | </t> | |||
<!-- target="advanced"/>. These scenarios are: --> | <ol spacing="normal" type="1"><li> | |||
<list style="format %d."> | <t> | |||
<t> | ||||
Some multicast sources or receivers are attached to PEs that | Some multicast sources or receivers are attached to PEs that | |||
support <xref target="RFC7432"/>, but do not support this | support <xref target="RFC7432" format="default"/> but do not support | |||
document or <xref target="RFC9135"/>. To interoperate with | this | |||
these "non&nbhy;OISM PEs", it is necessary to have one or more | document or <xref target="RFC9135" format="default"/>. To interoper | |||
ate with | ||||
these non-OISM PEs, it is necessary to have one or more | ||||
gateway PEs that interface the tunnels discussed in this | gateway PEs that interface the tunnels discussed in this | |||
document with the BUM tunnels of the legacy PEs. This is | document with the BUM tunnels of the legacy PEs. This is | |||
discussed in <xref target="no-OISM"/>. | discussed in <xref target="no-OISM" format="default"/>. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
Sometimes multicast traffic originates from outside the EVPN | Sometimes multicast traffic originates from outside the EVPN | |||
domain, or needs to be sent outside the EVPN domain. This is | domain or needs to be sent outside the EVPN domain. This is | |||
discussed in <xref target="external"/>. An important special case | discussed in <xref target="external" format="default"/>. An importa | |||
of this, integration with MVPN, is discussed in <xref | nt special case | |||
target="mvpn"/>. | of this, integration with MVPN, is discussed in <xref target="mvpn" | |||
</t> | format="default"/>. | |||
<t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | ||||
In some scenarios, one or more of the tenant systems is a PIM | In some scenarios, one or more of the tenant systems is a PIM | |||
router, and the Tenant Domain is used as a transit network | router, and the Tenant Domain is used as a transit network | |||
that is part of a larger multicast domain. This is discussed in | that is part of a larger multicast domain. This is discussed in | |||
<xref target="pim" format="default"/>. | ||||
<xref target="pim"/>. | </t> | |||
</t> | </li> | |||
</list> | </ol> | |||
</t> | </section> | |||
</section> <!-- adv_scen --> | </section> | |||
<section anchor="solution" numbered="true" toc="default"> | ||||
</section> <!-- model_detail --> | <name>EVPN-Aware Multicast Solution Control Plane</name> | |||
<section anchor="sbd_rts" numbered="true" toc="default"> | ||||
<section title="EVPN-aware Multicast Solution Control Plane" | <name>Supplementary Broadcast Domain (SBD) and Route Targets</name> | |||
anchor="solution"> | ||||
<section title="Supplementary Broadcast Domain (SBD) and Route Targets" | ||||
anchor="sbd_rts"> | ||||
<t> | <t> | |||
As discussed in <xref target="sbd_intro"/>, every Tenant Domain is | As discussed in <xref target="sbd_intro" format="default"/>, every Ten | |||
associated with a single Supplementary Broadcast Domain | ant Domain is | |||
(SBD). Recall that a Tenant Domain is defined to be a set of BDs | associated with a single | |||
SBD. Recall that a Tenant Domain is defined to be a set of BDs | ||||
that can freely send and receive IP multicast traffic to/from each | that can freely send and receive IP multicast traffic to/from each | |||
other. If an EVPN&nbhy;PE has one or more ACs in a BD of a | other. If an EVPN PE has one or more ACs in a BD of a | |||
particular Tenant Domain, and if the EVPN&nbhy;PE supports the | particular Tenant Domain, and if the EVPN PE supports the | |||
procedures of this document, that EVPN&nbhy;PE MUST be provisioned | procedures of this document, that EVPN PE <bcp14>MUST</bcp14> be provi | |||
sioned | ||||
with the SBD of that Tenant Domain. | with the SBD of that Tenant Domain. | |||
</t> | </t> | |||
<t> | <t> | |||
At each EVPN&nbhy;PE attached to a given Tenant Domain, there is | At each EVPN PE attached to a given Tenant Domain, there is | |||
an IRB interface leading from the L3 routing instance of that | an IRB interface leading from the L3 routing instance of that | |||
Tenant Domain to the SBD. However, the SBD has no ACs. | Tenant Domain to the SBD. However, the SBD has no ACs. | |||
</t> | </t> | |||
<t> | <t> | |||
Each SBD is provisioned with a Route Target (RT). All the | Each SBD is provisioned with a RT. All the | |||
EVPN&nbhy;PEs supporting a given SBD are provisioned with that RT | EVPN PEs supporting a given SBD are provisioned with that RT | |||
as an import RT. That RT MUST NOT be the same as the RT | as an import RT. That RT <bcp14>MUST NOT</bcp14> be the same as the R | |||
T | ||||
associated with any other BD. | associated with any other BD. | |||
</t> | </t> | |||
<t> | <t> | |||
We will use the term "SBD&nbhy;RT" to denote the RT that has been | We will use the term "SBD-RT" to denote the RT that has been | |||
assigned to the SBD. Routes carrying this RT will be propagated | assigned to the SBD. Routes carrying this RT will be propagated | |||
to all EVPN&nbhy;PEs in the same Tenant Domain as the originator. | to all EVPN PEs in the same Tenant Domain as the originator. | |||
</t> | </t> | |||
<t> | <t> | |||
<xref target="bd_route"/> specifies the rules by which an | <xref target="bd_route" format="default"/> specifies the rules by whic | |||
EVPN&nbhy;PE that receives a route determines whether a received | h an | |||
route "belongs to" a particular ordinary BD or SBD. | EVPN PE that receives a route determines whether a received | |||
route belongs to a particular ordinary BD or SBD. | ||||
</t> | </t> | |||
<t> | <t> | |||
<xref target="bd_route"/> also specifies additional rules that | <xref target="bd_route" format="default"/> also specifies additional r ules that | |||
must be followed when constructing routes that belong to a | must be followed when constructing routes that belong to a | |||
particular BD, including the SBD. | particular BD, including the SBD. | |||
</t> | </t> | |||
<t> | <t> | |||
The SBD SHOULD be in an EVPN Instance (EVI) of its own. Even if | The SBD <bcp14>SHOULD</bcp14> be in an EVI of its own. Even if | |||
the SBD is not in an EVI of its own, the SBD&nbhy;RT MUST be | the SBD is not in an EVI of its own, the SBD-RT <bcp14>MUST</bcp14> be | |||
different than the RT associated with any other BD. This | different than the RT associated with any other BD. This | |||
restriction is necessary in order for the rules of Sections <xref | restriction is necessary in order for the rules of Sections <xref targ | |||
target="bd_route" format="counter"/> and <xref target="sbd_rts" | et="bd_route" format="counter"/> and <xref target="sbd_rts" format="counter"/> t | |||
format="counter"/> to work correctly. | o work correctly. | |||
</t> | </t> | |||
<t> | <t> | |||
Note that an SBD, just like any other BD, is associated on each | Note that an SBD, just like any other BD, is associated on each | |||
EVPN&nbhy;PE with a MAC&nbhy;VRF. Per <xref target="RFC7432"/>, | EVPN PE with a MAC-VRF. Per <xref target="RFC7432" format="default"/> | |||
each MAC&nbhy;VRF is associated with a Route Distinguisher (RD). | , | |||
When constructing a route that is "for" an SBD, an EVPN&nbhy;PE | each MAC-VRF is associated with a Route Distinguisher (RD). | |||
will place the RD of the associated MAC&nbhy;VRF in the "Route | When constructing a route that is for an SBD, an EVPN PE | |||
Distinguisher" field of the NLRI. (If the Tenant Domain has | will place the RD of the associated MAC-VRF in the Route | |||
several MAC&nbhy;VRFs on a given PE, the EVPN&nbhy;PE has a choice | Distinguisher field of the NLRI. (If the Tenant Domain has | |||
several MAC-VRFs on a given PE, the EVPN PE has a choice | ||||
of which RD to use.) | of which RD to use.) | |||
</t> | </t> | |||
<t> | <t> | |||
If Assisted Replication (AR, see <xref target="I-D.ietf-bess-evpn-opti | If AR <xref target="RFC9574" format="default"/> is | |||
mized-ir"/>) is | used, each AR-REPLICATOR for a given Tenant Domain must be | |||
used, each AR&nbhy;REPLICATOR for a given Tenant Domain must be | ||||
provisioned with the SBD of that Tenant Domain, even if the | provisioned with the SBD of that Tenant Domain, even if the | |||
AR&nbhy;REPLICATOR does not have any L3 routing instance. | AR-REPLICATOR does not have any L3 routing instances. | |||
</t> | </t> | |||
</section> <!-- sbd_rts --> | </section> | |||
<section title="Advertising the Tunnels Used for IP Multicast" | <section anchor="adv_tunnels" numbered="true" toc="default"> | |||
anchor="adv_tunnels"> | <name>Advertising the Tunnels Used for IP Multicast</name> | |||
<t> | <t> | |||
The procedures used for advertising the tunnels that carry IP | The procedures used for advertising the tunnels that carry IP | |||
multicast traffic depend upon the type of tunnel being used. If | multicast traffic depend upon the type of tunnel being used. If | |||
the tunnel type is neither Ingress Replication, Assisted | the tunnel type is neither IR, AR, | |||
Replication, nor BIER, there are procedures for advertising both | nor BIER, there are procedures for advertising both | |||
"inclusive tunnels" and "selective tunnels". | inclusive tunnels and selective tunnels. | |||
</t> | </t> | |||
<t> | <t> | |||
When IR, AR or BIER are used to transmit IP multicast packets | When IR, AR, or BIER are used to transmit IP multicast packets | |||
across the core, there are no P2MP tunnels. Once an ingress | across the core, there are no P2MP tunnels. Once an ingress | |||
EVPN&nbhy;PE determines the set of egress EVPN&nbhy;PEs for a | EVPN PE determines the set of egress EVPN PEs for a | |||
given flow, the IMET routes contain all the information needed to | given flow, the IMET routes contain all the information needed to | |||
transport packets of that flow to the egress PEs. | transport packets of that flow to the egress PEs. | |||
</t> | </t> | |||
<t> | <t> | |||
If AR is used, the ingress EVPN&nbhy;PE is also an AR&nbhy;LEAF | If AR is used, the ingress EVPN PE is also an AR-LEAF, | |||
and the IMET route coming from the selected AR&nbhy;REPLICATOR | and the IMET route coming from the selected AR-REPLICATOR | |||
contains the information needed. The AR&nbhy;REPLICATOR will | contains the information needed. The AR-REPLICATOR will | |||
behave as an ingress EVPN&nbhy;PE when sending a flow to the | behave as an ingress EVPN PE when sending a flow to the | |||
egress EVPN&nbhy;PEs. | egress EVPN PEs. | |||
</t> | </t> | |||
<t> | <t> | |||
If the tunneling technique requires P2MP tunnels to be set up | If the tunneling technique requires P2MP tunnels to be set up | |||
(e.g., RSVP&nbhy;TE P2MP, mLDP, PIM), some of the tunnels may be | (e.g., RSVP-TE P2MP, Multipoint LDP (mLDP), or PIM), some of the tunne ls may be | |||
selective tunnels and some may be inclusive tunnels. | selective tunnels and some may be inclusive tunnels. | |||
</t> | </t> | |||
<t> | <t> | |||
Selective P2MP tunnels are always advertised by the ingress PE | Selective P2MP tunnels are always advertised by the ingress PE | |||
using S&nbhy;PMSI A&nbhy;D routes <xref target="I-D.ietf-bess-evpn-bum -procedure-updates"/>. | using S-PMSI Auto-Discovery (A-D) routes <xref target="RFC9572" format ="default"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
For inclusive tunnels, there is a choice between using a BD's | For inclusive tunnels, there is a choice between using a BD's | |||
ordinary "BUM tunnel" <xref target="RFC7432"/> as the default | ordinary BUM tunnel as the default | |||
inclusive tunnel for carrying IP multicast traffic, or using a | inclusive tunnel for carrying IP multicast traffic or using a | |||
separate IP multicast tunnel as the default inclusive tunnel for | separate IP multicast tunnel as the default inclusive tunnel for | |||
carrying IP multicast. In the former case, the inclusive tunnel is | carrying IP multicast. In the former case, the inclusive tunnel is | |||
advertised in an IMET route. In the latter case, the inclusive | advertised in an IMET route. In the latter case, the inclusive | |||
tunnel is advertised in a (C&nbhy;*,C&nbhy;*) S&nbhy;PMSI A&nbhy;D | tunnel is advertised in a (C-*,C-*) S-PMSI A-D | |||
route <xref target="I-D.ietf-bess-evpn-bum-procedure-updates"/>. Deta | route <xref target="RFC9572" format="default"/>. Details may be found | |||
ils may be found in | in | |||
subsequent sections. | subsequent sections. | |||
</t> | </t> | |||
<section anchor="sbd-routes" numbered="true" toc="default"> | ||||
<section title="Constructing Routes for the SBD" | <name>Constructing Routes for the SBD</name> | |||
anchor="sbd-routes"> | ||||
<t> | <t> | |||
There are situations in which an EVPN&nbhy;PE needs to originate | There are situations in which an EVPN PE needs to originate | |||
IMET, SMET, and/or SPMSI routes for the SBD. Throughout this | IMET, SMET, and/or S-PMSI routes for the SBD. Throughout this | |||
document, we will refer to such routes respectively as | document, we will refer to such routes respectively as | |||
"SBD&nbhy;IMET routes", "SBD&nbhy;SMET routes", and | "SBD-IMET routes", "SBD-SMET routes", and | |||
"SBD&nbhy;SPMSI routes". Subsequent sections detail the | "SBD-SPMSI routes". Subsequent sections detail the | |||
conditions under which these routes need to be originated. | conditions under which these routes need to be originated. | |||
</t> | </t> | |||
<t> | <t> | |||
When an EVPN&nbhy;PE needs to originate an SBD&nbhy;IMET, | When an EVPN PE needs to originate an SBD-IMET, | |||
SBD&nbhy;SMET, or SBD&nbhy;SPMSI route, it constructs the route | SBD-SMET, or SBD-SPMSI route, it constructs the route | |||
as follows: | as follows: | |||
<list style="symbols"> | </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | <t> | |||
the RD field of the route's NLRI is set to the RD of the | The RD field of the route's NLRI is set to the RD of the | |||
MAC&nbhy;VRF that is associated with the SBD; | MAC-VRF that is associated with the SBD. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
the SBD&nbhy;RT is attached to the route; | The SBD-RT is attached to the route. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
the "Tag ID" field of the route's NLRI is set to the Tag | The Tag ID field of the route's NLRI is set to the Tag | |||
ID that has been assigned to the SBD. This is most likely | ID that has been assigned to the SBD. This is most likely | |||
0 if a VLAN&nbhy;based or VLAN&nbhy;bundle service is | 0 if a VLAN-based or VLAN-bundle service is | |||
being used, but non-zero if a VLAN-aware bundle service is | being used but non-zero if a VLAN-aware bundle service is | |||
being used. | being used. | |||
</t> | </t> | |||
</list> | </li> | |||
</ul> | ||||
</section> | ||||
<section anchor="imet-ir" numbered="true" toc="default"> | ||||
<name>Ingress Replication</name> | ||||
<t> | ||||
When IR is used to transport IP | ||||
multicast frames of a given Tenant Domain, each EVPN PE | ||||
attached to that Tenant Domain <bcp14>MUST</bcp14> originate an SB | ||||
D-IMET | ||||
route (see <xref target="sbd-routes" format="default"/>). | ||||
</t> | </t> | |||
</section> <!-- sbd-routes --> | ||||
<section title="Ingress Replication" anchor="imet-ir"> | ||||
<t> | <t> | |||
When Ingress Replication (IR) is used to transport IP | The SBD-IMET route <bcp14>MUST</bcp14> carry a | |||
multicast frames of a given Tenant Domain, each EVPN&nbhy;PE | PTA, and the MPLS Label field of the PTA <bcp14>MUST</bcp14> speci | |||
attached to that Tenant Domain MUST originate an SBD&nbhy;IMET | fy a | |||
route (see <xref target="sbd-routes"/>). | ||||
</t> | ||||
<t> | ||||
The SBD&nbhy;IMET route MUST carry a PMSI Tunnel attribute | ||||
(PTA), and the MPLS label field of the PTA MUST specify a | ||||
downstream-assigned MPLS label that maps uniquely (in the | downstream-assigned MPLS label that maps uniquely (in the | |||
context of the originating EVPN&nbhy;PE) to the SBD. | context of the originating EVPN PE) to the SBD. | |||
</t> | </t> | |||
<t> | <t> | |||
Following the procedures of <xref target="RFC7432"/>, an | Following the procedures of <xref target="RFC7432" format="default | |||
EVPN&nbhy;PE MUST also originate an IMET route for each BD to | "/>, an | |||
EVPN PE <bcp14>MUST</bcp14> also originate an IMET route for each | ||||
BD to | ||||
which it is attached. Each of these IMET routes carries a PTA | which it is attached. Each of these IMET routes carries a PTA | |||
specifying a downstream&nbhy;assigned label that maps | specifying a downstream-assigned label that maps | |||
uniquely, in the context of the originating EVPN&nbhy;PE, to | uniquely, in the context of the originating EVPN PE, to | |||
the BD in question. These IMET routes need not carry the | the BD in question. These IMET routes need not carry the | |||
SBD&nbhy;RT. | SBD-RT. | |||
</t> | </t> | |||
<t> | <t> | |||
When an ingress EVPN&nbhy;PE needs to use IR to send an IP | When an ingress EVPN PE needs to use IR to send an IP | |||
multicast frame from a particular source BD to an egress | multicast frame from a particular source BD to an egress | |||
EVPN&nbhy;PE, the ingress PE determines whether the egress PE | EVPN PE, the ingress PE determines whether or not the egress PE | |||
has originated an IMET route for that BD. If so, that IMET | has originated an IMET route for that BD. If so, that IMET | |||
route contains the MPLS label that the egress PE has assigned | route contains the MPLS label that the egress PE has assigned | |||
to the source BD. The ingress PE uses that label when | to the source BD. The ingress PE uses that label when | |||
transmitting the packet to the egress PE. Otherwise, the | transmitting the packet to the egress PE. Otherwise, the | |||
ingress PE uses the label that the egress PE has assigned to | ingress PE uses the label that the egress PE has assigned to | |||
the SBD (in the SBD&nbhy;IMET route originated by the egress). | the SBD (in the SBD-IMET route originated by the egress). | |||
</t> | </t> | |||
<t> | <t> | |||
Note that the set of IMET routes originated by a given egress | Note that the set of IMET routes originated by a given egress | |||
PE, and installed by a given ingress PE, may change over time. | PE, and installed by a given ingress PE, may change over time. | |||
If the egress PE withdraws its IMET route for the source BD, | If the egress PE withdraws its IMET route for the source BD, | |||
the ingress PE MUST stop using the label carried in that IMET | the ingress PE <bcp14>MUST</bcp14> stop using the label carried in | |||
route, and instead MUST use the label carried in the | that IMET | |||
SBD&nbhy;IMET route from that egress PE. Implementors must | route and instead <bcp14>MUST</bcp14> use the label carried in the | |||
SBD-IMET route from that egress PE. Implementors must | ||||
also take into account that an IMET route from a particular PE | also take into account that an IMET route from a particular PE | |||
for a particular BD may arrive after that PE's SBD&nbhy;IMET | for a particular BD may arrive after that PE's SBD-IMET | |||
route. | route. | |||
</t> | </t> | |||
</section> | ||||
</section> <!-- imet-ir --> | <section anchor="imet-ar" numbered="true" toc="default"> | |||
<section title="Assisted Replication" anchor="imet-ar"> | <name>Assisted Replication</name> | |||
<t> | <t> | |||
When Assisted Replication is used to transport IP multicast | When AR is used to transport IP multicast | |||
frames of a given Tenant Domain, each EVPN&nbhy;PE (including | frames of a given Tenant Domain, each EVPN PE (including | |||
the AR&nbhy;REPLICATOR) attached to the Tenant Domain MUST | the AR-REPLICATOR) attached to the Tenant Domain <bcp14>MUST</bcp1 | |||
originate an SBD&nbhy;IMET route (see <xref | 4> | |||
target="sbd-routes"/>). | originate an SBD-IMET route (see <xref target="sbd-routes" format= | |||
</t> | "default"/>). | |||
<t> | </t> | |||
An AR&nbhy;REPLICATOR attached to a given Tenant Domain is | <t> | |||
considered to be an EVPN&nbhy;PE of that Tenant Domain. It is | An AR-REPLICATOR attached to a given Tenant Domain is | |||
considered to be an EVPN PE of that Tenant Domain. It is | ||||
attached to all the BDs in the Tenant Domain, but it does not | attached to all the BDs in the Tenant Domain, but it does not | |||
necessarily have L3 routing instances. | necessarily have L3 routing instances. | |||
</t> | </t> | |||
<t> | <t> | |||
As with Ingress Replication, the SBD&nbhy;IMET route carries a | As with IR, the SBD-IMET route carries a | |||
PTA where the MPLS label field specifies the | PTA where the MPLS Label field specifies the | |||
downstream-assigned MPLS label that identifies the | downstream-assigned MPLS label that identifies the | |||
SBD. However, the AR&nbhy;REPLICATOR and AR&nbhy;LEAF | SBD. However, the AR-REPLICATOR and AR-LEAF | |||
EVPN&nbhy;PEs will set the PTA's flags differently, as per | EVPN PEs will set the PTA's flags differently, as per | |||
<xref target="I-D.ietf-bess-evpn-optimized-ir"/>. | <xref target="RFC9574" format="default"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
In addition, each EVPN&nbhy;PE originates an IMET route for | In addition, each EVPN PE originates an IMET route for | |||
each BD to which it is attached. As in the case of Ingress | each BD to which it is attached. As in the case of IR, | |||
Replication, these routes carry the downstream-assigned MPLS | these routes carry the downstream-assigned MPLS | |||
labels that identify the BDs and do not carry the SBD&nbhy;RT. | labels that identify the BDs and do not carry the SBD-RT. | |||
</t> | </t> | |||
<t> | <t> | |||
When an ingress EVPN&nbhy;PE, acting as AR&nbhy;LEAF, needs to | When an ingress EVPN PE, acting as AR-LEAF, needs to | |||
send an IP multicast frame from a particular source BD to an | send an IP multicast frame from a particular source BD to an | |||
egress EVPN&nbhy;PE, the ingress PE determines whether there | egress EVPN PE, the ingress PE determines whether or not there | |||
is any AR&nbhy;REPLICATOR that originated an IMET route for | is any AR-REPLICATOR that originated an IMET route for | |||
that BD. After the AR&nbhy;REPLICATOR selection (if there are | that BD. After the AR-REPLICATOR selection (if there are | |||
more than one), the AR&nbhy;LEAF uses the label contained in | more than one), the AR-LEAF uses the label contained in | |||
the IMET route of the AR&nbhy;REPLICATOR when transmitting | the IMET route of the AR-REPLICATOR when transmitting | |||
packets to it. The AR&nbhy;REPLICATOR receives the packet and, | packets to it. The AR-REPLICATOR receives the packet and, | |||
based on the procedures specified in <xref target="I-D.ietf-bess-e | based on the procedures specified in <xref target="RFC9574" format | |||
vpn-optimized-ir"/> | ="default"/> | |||
and in <xref target="imet-ir"/> of this document, | and in <xref target="imet-ir" format="default"/> of this document, | |||
transmits the packets to the egress EVPN&nbhy;PEs using the | transmits the packets to the egress EVPN PEs using the | |||
labels contained in the received IMET routes for either the | labels contained in the received IMET routes for either the | |||
source BD or the SBD. | source BD or the SBD. | |||
</t> | </t> | |||
<t> | <t> | |||
If an ingress AR&nbhy;LEAF for a given BD has not received any | If an ingress AR-LEAF for a given BD has not received any | |||
IMET route for that BD from an AR&nbhy;REPLICATOR, the ingress | IMET route for that BD from an AR-REPLICATOR, the ingress | |||
AR&nbhy;LEAF follows the procedures in <xref | AR-LEAF follows the procedures in <xref target="imet-ir" format="d | |||
target="imet-ir"/>. | efault"/>. | |||
</t> | </t> | |||
<section title = "Automatic SBD Matching" anchor="SBD-matching"> | <section anchor="SBD-matching" numbered="true" toc="default"> | |||
<t>Each PE needs to know a BD's | <name>Automatic SBD Matching</name> | |||
<t>Each PE needs to know a BD's | ||||
corresponding SBD. Configuring that information in each BD | corresponding SBD. Configuring that information in each BD | |||
is one way but it requires repetitive configuration and | is one way, but it requires repetitive configuration and | |||
consistency checking (to make sure that all the BDs of the same | consistency checking (to make sure that all the BDs of the same | |||
tenant are configured with the same SBD). A better way is to | tenant are configured with the same SBD). A better way is to | |||
configure the SBD info in the L3 routing instance so that all | configure the SBD info in the L3 routing instance so that all | |||
related BDs will derive the SBD information. | related BDs will derive the SBD information. | |||
</t> | </t> | |||
<t>An AR-replicator also needs to know same information, though | <t>An AR-REPLICATOR also needs to know the same information, though | |||
it does not necessarily have an L3 routing instance. | it does not necessarily have an L3 routing instance. | |||
However, from the EVI-RT EC in a BD's IMET route, an AR-replicator | However, from the EVI-RT EC in a BD's IMET route, an AR-REPLICATOR | |||
can derive the corresponding SBD of that BD without any configurati on. | can derive the corresponding SBD of that BD without any configurati on. | |||
</t> | </t> | |||
</section> | </section> | |||
</section> <!-- imet-ar --> | </section> | |||
<section title="BIER" anchor="imet-bier"> | <section anchor="imet-bier" numbered="true" toc="default"> | |||
<t> | <name>BIER</name> | |||
<t> | ||||
When BIER is used to transport multicast packets of a given | When BIER is used to transport multicast packets of a given | |||
Tenant Domain, and a given EVPN&nbhy;PE attached to that | Tenant Domain, and a given EVPN PE attached to that | |||
Tenant Domain is a possible ingress EVPN&nbhy;PE for traffic | Tenant Domain is a possible ingress EVPN PE for traffic | |||
originating outside that Tenant Domain, the given EVPN&nbhy;PE | originating outside that Tenant Domain, the given EVPN PE | |||
MUST originate an SBD&nbhy;IMET route, (see <xref | <bcp14>MUST</bcp14> originate an SBD-IMET route (see <xref target= | |||
target="sbd-routes"/>). | "sbd-routes" format="default"/>). | |||
</t> | </t> | |||
<t> | <t> | |||
In addition, IMET routes that are originated for other BDs in | In addition, IMET routes that are originated for other BDs in | |||
the Tenant Domain MUST carry the SBD&nbhy;RT. | the Tenant Domain <bcp14>MUST</bcp14> carry the SBD-RT. | |||
</t> | </t> | |||
<t> | <t> | |||
Each IMET route (including but not limited to the | Each IMET route (including but not limited to the | |||
SBD&nbhy;IMET route) MUST carry a PMSI Tunnel attribute (PTA). | SBD-IMET route) <bcp14>MUST</bcp14> carry a PTA. | |||
The MPLS label field of the PTA MUST specify an | The MPLS Label field of the PTA <bcp14>MUST</bcp14> specify an | |||
upstream-assigned MPLS label that maps uniquely (in the | upstream-assigned MPLS label that maps uniquely (in the | |||
context of the originating EVPN&nbhy;PE) to the BD for which | context of the originating EVPN PE) to the BD for which | |||
the route is originated. | the route is originated. | |||
</t> | </t> | |||
<t> | <t> | |||
Suppose an ingress EVPN&nbhy;PE, PE1, needs to use BIER to | Suppose an ingress EVPN PE, say PE1, needs to use BIER to | |||
tunnel an IP multicast frame to a set of egress | tunnel an IP multicast frame to a set of egress | |||
EVPN&nbhy;PEs. And suppose the frame's source BD is BD1. The | EVPN PEs. And suppose the frame's source BD is BD1. The | |||
frame is encapsulated as follows: | frame is encapsulated as follows: | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
A four-octet MPLS label stack entry <xref | <li> | |||
target="RFC3032"/> is prepended to the | <t> | |||
A four-octet MPLS label stack entry <xref target="RFC3032" for | ||||
mat="default"/> is prepended to the | ||||
frame. The Label field is set to the upstream-assigned | frame. The Label field is set to the upstream-assigned | |||
label that PE1 has assigned to BD1. | label that PE1 has assigned to BD1. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The resulting MPLS packet is then encapsulated in a BIER | The resulting MPLS packet is then encapsulated in a BIER | |||
encapsulation <xref target="RFC8296"/>, <xref | encapsulation <xref target="RFC8296" format="default"/> <xref | |||
target="I-D.ietf-bier-evpn"/>. The BIER BitString is set to | target="I-D.ietf-bier-evpn" format="default"/>. The BIER BitString is set to | |||
identify the egress EVPN&nbhy;PEs. The BIER "proto" field | identify the egress EVPN PEs. The BIER Proto field | |||
is set to the value for "MPLS packet with | is set to the value for "MPLS packet with an | |||
upstream&nbhy;assigned label at top of stack". | upstream-assigned label at top of the stack". | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
Note: It is possible that the packet being tunneled from PE1 | Note: It is possible that the packet being tunneled from PE1 | |||
originated outside the Tenant Domain. In this case, the | originated outside the Tenant Domain. In this case, the | |||
actual source BD (BD1) is considered to be the SBD, and the | actual source BD, BD1, is considered to be the SBD, and the | |||
upstream&nbhy;assigned label it carries will be the label that | upstream-assigned label it carries will be the label that | |||
PE1 assigned to the SBD, and advertised in its SBD&nbhy;IMET | PE1 assigned to the SBD and advertised in its SBD-IMET | |||
route. | route. | |||
</t> | </t> | |||
<t> | <t> | |||
Suppose an egress PE, PE2, receives such a BIER packet. The | Suppose an egress PE, say PE2, receives such a BIER packet. The | |||
BFIR&nbhy;id field of the BIER header allows PE2 to determine | BFIR-id field of the BIER header allows PE2 to determine | |||
that the ingress PE is PE1. There are then two cases to | that the ingress PE is PE1. There are then two cases to | |||
consider: | consider: | |||
<list style="numbers"> | </t> | |||
<t> | <ol spacing="normal" type="1"><li> | |||
<t> | ||||
PE2 has received and installed an IMET route for BD1 from | PE2 has received and installed an IMET route for BD1 from | |||
PE1. | PE1. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
In this case, the BIER packet will be carrying the | In this case, the BIER packet will be carrying the | |||
upstream&nbhy;assigned label that is specified in the PTA | upstream-assigned label that is specified in the PTA | |||
of that IMET route. This enables PE2 to determine the | of that IMET route. This enables PE2 to determine the | |||
"apparent source BD" (as defined in <xref | apparent source BD (as defined in <xref target="egress_irb_use | |||
target="egress_irb_use"/>). | " format="default"/>). | |||
<!-- that --> | </t> | |||
<!-- BD1 is the source BD of the IP multicast frame carried by | </li> | |||
--> | <li> | |||
<!-- the BIER packet. --> | <t> | |||
</t> | ||||
<t> | ||||
PE2 has not received and installed an IMET route for BD1 | PE2 has not received and installed an IMET route for BD1 | |||
from PE1. | from PE1. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
In this case, PE2 will not recognize the | In this case, PE2 will not recognize the | |||
upstream&nbhy;assigned label carried in the BIER | upstream-assigned label carried in the BIER | |||
packet. PE2 MUST discard the packet. | packet. PE2 <bcp14>MUST</bcp14> discard the packet. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ol> | |||
<t> | <t> | |||
Further details on the use of BIER to support EVPN can be | Further details on the use of BIER to support EVPN can be | |||
found in <xref target="I-D.ietf-bier-evpn"/>. | found in <xref target="I-D.ietf-bier-evpn" format="default"/>. | |||
</t> | </t> | |||
</section> | ||||
</section> <!-- imet-bier --> | <section anchor="adv_incl" numbered="true" toc="default"> | |||
<name>Inclusive P2MP Tunnels</name> | ||||
<section title="Inclusive P2MP Tunnels" anchor="adv_incl"> | <section anchor="ip_bum" numbered="true" toc="default"> | |||
<section title="Using the BUM Tunnels as IP Multicast Inclusive | <name>Using the BUM Tunnels as IP Multicast Inclusive Tunnels</name> | |||
Tunnels" | ||||
anchor="ip_bum"> | ||||
<t> | <t> | |||
The procedures in this section apply only when | The procedures in this section apply only when: | |||
<list style="format (%c)"> | </t> | |||
<ol spacing="normal" type="%c)"><li> | ||||
<t> | <t> | |||
it is desired to use the BUM tunnels to carry IP multicast | it is desired to use the BUM tunnels to carry IP multicast | |||
traffic across the backbone, and | traffic across the backbone and | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
the BUM tunnels are P2MP tunnels (i.e., neither IR, AR, | the BUM tunnels are P2MP tunnels (i.e., neither IR, AR, | |||
nor BIER are being used to transport the BUM traffic). | nor BIER are being used to transport the BUM traffic). | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ol> | |||
<t> | <t> | |||
In this case, an IP multicast frame (whether inter&nbhy;subnet | In this case, an IP multicast frame (whether inter-subnet | |||
or intra&nbhy;subnet) will be carried across the backbone in | or intra-subnet) will be carried across the backbone in | |||
the BUM tunnel belonging to its source BD. Each EVPN&nbhy;PE | the BUM tunnel belonging to its source BD. Each EVPN PE | |||
attached to a given Tenant Domain needs to join the BUM | attached to a given Tenant Domain needs to join the BUM | |||
tunnels for every BD in the Tenant Domain, even those BDs to | tunnels for every BD in the Tenant Domain, even those BDs to | |||
which the EVPN&nbhy;PE is not locally attached. This ensures | which the EVPN PE is not locally attached. This ensures | |||
that an IP multicast packet from any source BD can reach all | that an IP multicast packet from any source BD can reach all | |||
PEs attached to the Tenant Domain. | PEs attached to the Tenant Domain. | |||
</t> | </t> | |||
<t> | <t> | |||
Note that this will cause all the BUM traffic from a given BD | Note that this will cause all the BUM traffic from a given BD | |||
in a Tenant Domain to be sent to all PEs that attach to that | in a Tenant Domain to be sent to all PEs that attach to that | |||
Tenant Domain, even the PEs that don't attach to the given BD. | Tenant Domain, even the PEs that don't attach to the given BD. | |||
To avoid this, it is RECOMMENDED that the BUM tunnels not be | To avoid this, it is <bcp14>RECOMMENDED</bcp14> that the BUM tunne | |||
used as IP Multicast inclusive tunnels, and that the | ls not be | |||
procedures of <xref target="wc_spmsi"/> be used instead. | used as IP multicast inclusive tunnels and that the | |||
procedures of <xref target="wc_spmsi" format="default"/> be used i | ||||
nstead. | ||||
</t> | </t> | |||
<t> | <t> | |||
If a PE is a possible ingress EVPN&nbhy;PE for traffic | If a PE is a possible ingress EVPN PE for traffic | |||
originating outside the Tenant Domain, the PE MUST originate | originating outside the Tenant Domain, the PE <bcp14>MUST</bcp14> | |||
an SBD&nbhy;IMET route (see <xref target="sbd-routes"/>). | originate | |||
This route MUST carry a PTA specifying the P2MP tunnel used | an SBD-IMET route (see <xref target="sbd-routes" format="default"/ | |||
>). | ||||
This route <bcp14>MUST</bcp14> carry a PTA specifying the P2MP tun | ||||
nel used | ||||
for transmitting IP multicast packets that originate outside | for transmitting IP multicast packets that originate outside | |||
the tenant domain. All EVPN&nbhy;PEs of the Tenant Domain | the Tenant Domain. All EVPN PEs of the Tenant Domain | |||
MUST join the tunnel specified in the PTA of an SBD&nbhy;IMET | <bcp14>MUST</bcp14> join the tunnel specified in the PTA of an SBD | |||
-IMET | ||||
route: | route: | |||
<list style="symbols"> | </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | <t> | |||
If the tunnel is an RSVP-TE P2MP tunnel, the originator of | If the tunnel is an RSVP-TE P2MP tunnel, the originator of | |||
the route MUST use RSVP-TE P2MP procedures to add each PE | the route <bcp14>MUST</bcp14> use RSVP-TE P2MP procedures to a dd each PE | |||
of the Tenant Domain to the tunnel, even PEs that have not | of the Tenant Domain to the tunnel, even PEs that have not | |||
originated an SBD&nbhy;IMET route. | originated an SBD-IMET route. | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
If the tunnel is an mLDP or PIM tunnel, each PE importing | If the tunnel is an mLDP or PIM tunnel, each PE importing | |||
the SBD&nbhy;IMET route MUST add itself to the tunnel, | the SBD-IMET route <bcp14>MUST</bcp14> add itself to the tunne l, | |||
using mLDP or PIM procedures, respectively. | using mLDP or PIM procedures, respectively. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
Whether or not a PE originates an SBD&nbhy;IMET route, it will | Whether or not a PE originates an SBD-IMET route, it will | |||
of course originate an IMET route for each BD to which it is | of course originate an IMET route for each BD to which it is | |||
attached. Each of these IMET routes MUST carry the | attached. Each of these IMET routes <bcp14>MUST</bcp14> carry the | |||
SBD&nbhy;RT, as well as the RT for the BD to which it belongs. | SBD-RT, as well as the RT for the BD to which it belongs. | |||
</t> | </t> | |||
<t> | <t> | |||
If a received IMET route is not the SBD&nbhy;IMET route, it | If a received IMET route is not the SBD-IMET route, it | |||
will also be carrying the RT for its source BD. The route's | will also be carrying the RT for its source BD. The route's | |||
NLRI will carry the Tag ID for the source BD. From the RT and | NLRI will carry the Tag ID for the source BD. From the RT and | |||
the Tag ID, any PE receiving the route can determine the | the Tag ID, any PE receiving the route can determine the | |||
route's source BD. | route's source BD. | |||
</t> | </t> | |||
<t> | <t> | |||
If the MPLS label field of the PTA contains zero, the | If the MPLS Label field of the PTA contains zero, the | |||
specified P2MP tunnel is used only to carry frames of a single | specified P2MP tunnel is used only to carry frames of a single | |||
source BD. | source BD. | |||
</t> | </t> | |||
<t> | <t> | |||
If the MPLS label field of the PTA does not contain zero, it | If the MPLS Label field of the PTA does not contain zero, it | |||
MUST contain an upstream-assigned MPLS label that maps | <bcp14>MUST</bcp14> contain an upstream-assigned MPLS label that m | |||
uniquely (in the context of the originating EVPN&nbhy;PE) to | aps | |||
the source BD (or, in the case of an SBD&nbhy;IMET route, to | uniquely (in the context of the originating EVPN PE) to | |||
the source BD (or in the case of an SBD-IMET route, to | ||||
the SBD). The tunnel may then be used to carry frames of | the SBD). The tunnel may then be used to carry frames of | |||
multiple source BDs. The apparent source BD of a particular | multiple source BDs. The apparent source BD of a particular | |||
packet is inferred from the label carried by the packet. | packet is inferred from the label carried by the packet. | |||
</t> | </t> | |||
<t> | <t> | |||
IP multicast traffic originating outside the Tenant Domain is | IP multicast traffic originating outside the Tenant Domain is | |||
transmitted with the label corresponding to the SBD, as | transmitted with the label corresponding to the SBD, as | |||
specified in the ingress EVPN&nbhy;PE's SBD&nbhy;IMET route. | specified in the ingress EVPN PE's SBD-IMET route. | |||
</t> | </t> | |||
</section> <!-- ip_bum --> | </section> | |||
<section title="Using Wildcard S&nbhy;PMSI A-D Routes to Advertise | <section anchor="wc_spmsi" numbered="true" toc="default"> | |||
Inclusive Tunnels Specific to IP Multicast" | <name>Using Wildcard S-PMSI A-D Routes to Advertise | |||
anchor="wc_spmsi"> | Inclusive Tunnels Specific to IP Multicast</name> | |||
<t> | <t> | |||
The procedures of this section apply when (and only when) it is | The procedures of this section apply when (and only when) it is | |||
desired to transmit IP multicast traffic on an inclusive tunnel, | desired to transmit IP multicast traffic on an inclusive tunnel | |||
but not on the same tunnel used to transmit BUM traffic. | but not on the same tunnel used to transmit BUM traffic. | |||
</t> | </t> | |||
<t> | <t> | |||
However, these procedures do NOT apply when the tunnel type is | However, these procedures do NOT apply when the tunnel type is | |||
Ingress Replication or BIER, EXCEPT in the case where it is | IR or BIER, EXCEPT in the case where it is | |||
necessary to interwork between non&nbhy;OISM PEs and OISM PEs, | necessary to interwork between non-OISM PEs and OISM PEs, | |||
as specified in <xref target="no-OISM"/>. | as specified in <xref target="no-OISM" format="default"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
Each EVPN&nbhy;PE attached to the given Tenant Domain MUST | Each EVPN PE attached to the given Tenant Domain <bcp14>MUST</bcp14 | |||
originate an SBD&nbhy;SPMSI A&nbhy;D route. The NLRI of that | > | |||
route MUST contain (C&nbhy;*,C&nbhy;*) (see <xref | originate an SBD-SPMSI A-D route. The NLRI of that | |||
target="RFC6625"/>). Additional rules for constructing that | route <bcp14>MUST</bcp14> contain (C-*,C-*) (see <xref target="RFC6 | |||
route are given in <xref target="sbd-routes"/>. | 625" format="default"/>). Additional rules for constructing that | |||
</t> | route are given in <xref target="sbd-routes" format="default"/>. | |||
<t> | </t> | |||
In addition, an EVPN&nbhy;PE MUST originate an S&nbhy;PMSI | <t> | |||
A&nbhy;D route containing (C&nbhy;*,C&nbhy;*) in its NLRI for | In addition, an EVPN PE <bcp14>MUST</bcp14> originate an S-PMSI | |||
A-D route containing (C-*,C-*) in its NLRI for | ||||
each of the other BDs, in the given Tenant Domain, to which it | each of the other BDs, in the given Tenant Domain, to which it | |||
is attached. All such routes MUST carry the SBD&nbhy;RT. This | is attached. All such routes <bcp14>MUST</bcp14> carry the SBD-RT. | |||
ensures that those routes are imported by all EVPN&nbhy;PEs | This | |||
ensures that those routes are imported by all EVPN PEs | ||||
attached to the Tenant Domain. | attached to the Tenant Domain. | |||
</t> | ||||
<t> | ||||
A PE receiving these routes follows the procedures of <xref | ||||
target="bd_route"/> to determine which BD the route is for. | ||||
<!-- The route carrying the PTA will also be carrying the RT for -- | ||||
> | ||||
<!-- that source BD, and the route's NLRI will contain the Tag ID - | ||||
-> | ||||
<!-- for that source BD. This allows any PE receiving the route to | ||||
--> | ||||
<!-- determine the source BD associated with the route. --> | ||||
</t> | </t> | |||
<t> | <t> | |||
If the MPLS label field of the PTA contains zero, the | A PE receiving these routes follows the procedures of <xref target= | |||
"bd_route" format="default"/> to determine which BD the route is for. | ||||
</t> | ||||
<t> | ||||
If the MPLS Label field of the PTA contains zero, the | ||||
specified tunnel is used only to carry frames of a single | specified tunnel is used only to carry frames of a single | |||
source BD. | source BD. | |||
</t> | </t> | |||
<t> | <t> | |||
If the MPLS label field of the PTA does not contain zero, it | If the MPLS Label field of the PTA does not contain zero, it | |||
MUST specify an upstream-assigned MPLS label that maps | <bcp14>MUST</bcp14> specify an upstream-assigned MPLS label that m | |||
uniquely (in the context of the originating EVPN&nbhy;PE) to | aps | |||
uniquely (in the context of the originating EVPN PE) to | ||||
the source BD. The tunnel may be used to carry frames of | the source BD. The tunnel may be used to carry frames of | |||
multiple source BDs, and the apparent source BD for a | multiple source BDs, and the apparent source BD for a | |||
particular packet is inferred from the label carried by the | particular packet is inferred from the label carried by the | |||
packet. | packet. | |||
</t> | </t> | |||
<t> | <t> | |||
The EVPN&nbhy;PE advertising these S&nbhy;PMSI A&nbhy;D route | The EVPN PE advertising these S-PMSI A-D | |||
routes is specifying the default tunnel that it will use (as | routes is specifying the default tunnel that it will use (as | |||
ingress PE) for transmitting IP multicast packets. The | ingress PE) for transmitting IP multicast packets. The | |||
upstream-assigned label allows an egress PE to determine the | upstream-assigned label allows an egress PE to determine the | |||
apparent source BD of a given packet. | apparent source BD of a given packet. | |||
</t> | </t> | |||
</section> <!-- wc-spmsi --> | </section> | |||
</section> | ||||
<!-- <section title="RSVP-TE P2MP" anchor="wc-rsvp"> --> | <section anchor="adv_secl" numbered="true" toc="default"> | |||
<!-- <t> --> | <name>Selective Tunnels</name> | |||
<!-- When RSVP-TE P2MP is used to transport multicast packets of a | <t> | |||
--> | An ingress EVPN PE for a given multicast flow or set of flows | |||
<!-- given Tenant Domain on an inclusive tunnel, and it is desired | ||||
--> | ||||
<!-- to avoid using the BUM tunnels, then each EVPN&nbhy;PE | ||||
attached to --> | ||||
<!-- that Tenant Domain MUST originate an SBD&nbhy;SPMSI A-D | ||||
route. The --> | ||||
<!-- NLRI of that route MUST contain (C&nbhy;*,C&nbhy;*) (see | ||||
<xref --> | ||||
<!-- target="RFC625"/>). Additional rules for constructing that -- | ||||
> | ||||
<!-- route are given in <xref target="sbd-spmsi"/>. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- In addition, an EVPN&nbhy;PE MUST originate an S&nbhy;PMSI A-D | ||||
route --> | ||||
<!-- containing (C&nbhy;*,C&nbhy;*) in its NLRI for each of the | ||||
other BDs in --> | ||||
<!-- the Tenant Domain to which it is attached. All such route -- | ||||
> | ||||
<!-- MUST carry the SBD&nbhy;RT. This ensures that those routes | ||||
are --> | ||||
<!-- imported by all EVPN&nbhy;PEs attached to the Tenant | ||||
Domain. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Each S&nbhy;PMSI A-D route (including but not limited to the | ||||
--> | ||||
<!-- SBD&nbhy;SPMSI route) MUST carry a PMSI Tunnel attribute | ||||
(PTA). --> | ||||
<!-- The MPLS label field of the PTA MUST specify an --> | ||||
<!-- upstream-assigned MPLS label that maps uniquely (in the --> | ||||
<!-- context of the originating EVPN&nbhy;PE) to the SBD. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- The EVPN&nbhy;PE advertising these S&nbhy;PMSI A-D route routes i | ||||
s | ||||
--> | ||||
<!-- specifying the default tunnel that it will use (as ingress PE | ||||
) --> | ||||
<!-- for transmitting IP multicast packets. The upstream-assigned | ||||
--> | ||||
<!-- label allows an egress PE to determine the source BD of a --> | ||||
<!-- given packet. --> | ||||
<!-- </t> --> | ||||
<!-- </section> <!-\- wc-rsvp -\-> --> | ||||
<!-- <section title="mLDP or PIM" anchor="wc-recv"> --> | ||||
<!-- <t> --> | ||||
<!-- When either mLDP or PIM (or any other protocol that uses a -- | ||||
> | ||||
<!-- receiver-driven technique to build P2MP or MP2MP trees) is -- | ||||
> | ||||
<!-- used to transport multicast packets of a given Tenant Domain | ||||
--> | ||||
<!-- on an inclusive tunnel, and it is desired to avoid using the | ||||
--> | ||||
<!-- BUM tunnels, the procedures of this section apply. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- then each, --> | ||||
<!-- an EVPN&nbhy;PE attached to that Tenant Domain MUST NOT | ||||
originate --> | ||||
<!-- an SBD&nbhy;IMET route. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- However, IMET routes that are originated for other BDs in the | ||||
--> | ||||
<!-- Tenant Domain MUST carry the SBD&nbhy;RT. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Each IMET route MUST carry a PMSI Tunnel attribute (PTA), and | ||||
--> | ||||
<!-- the MPLS label field of the PTA MUST specify an --> | ||||
<!-- upstream-assigned MPLS label that maps uniquely (in the --> | ||||
<!-- context of the originating EVPN&nbhy;PE) to a particular | ||||
BD. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- The EVPN&nbhy;PE advertising these IMET routes is specifying | ||||
the --> | ||||
<!-- default tunnel that it will use (as ingress PE) for --> | ||||
<!-- transmitting IP multicast packets. The upstream-assigned --> | ||||
<!-- label allows an egress PE to determine the source BD of a --> | ||||
<!-- given packet. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- The procedures of this section <xref target="imet-recv"/> --> | ||||
<!-- apply whenever the tunnel technology is based on the --> | ||||
<!-- construction of the multicast trees in a "receiver-driven" -- | ||||
> | ||||
<!-- manner; mLDP and PIM are two ways of constructing trees in a | ||||
--> | ||||
<!-- receiver-driven manner. --> | ||||
<!-- </t> --> | ||||
<!-- </section> <!-\- wc-recv -\-> --> | ||||
</section> <!-- wc_spmsi--> | ||||
<section title="Selective Tunnels" anchor="adv_secl"> | ||||
<t> | ||||
An ingress EVPN&nbhy;PE for a given multicast flow or set of flows | ||||
can always assign the flow to a particular P2MP tunnel by | can always assign the flow to a particular P2MP tunnel by | |||
originating an S&nbhy;PMSI A&nbhy;D route whose NLRI identifies | originating an S-PMSI A-D route whose NLRI identifies | |||
the flow or set of flows. The NLRI of the route could be | the flow or set of flows. The NLRI of the route could be | |||
(C&nbhy;*,C&nbhy;G), or (C&nbhy;S,C&nbhy;G). The S&nbhy;PMSI | (C-*,C-G) or (C-S,C-G). The S-PMSI | |||
A&nbhy;D route MUST carry the SBD&nbhy;RT, so that it is imported | A-D route <bcp14>MUST</bcp14> carry the SBD-RT so that it is imported | |||
by all EVPN&nbhy;PEs attached to the Tenant Domain. | by all EVPN PEs attached to the Tenant Domain. | |||
</t> | </t> | |||
<!-- <t> --> | ||||
<!-- <cref source=" ECR"> --> | ||||
<!-- Any need for (C&nbhy;S,C&nbhy;*)? --> | ||||
<!-- </cref> --> | ||||
<!-- </t> --> | ||||
<t> | <t> | |||
An S&nbhy;PMSI A&nbhy;D route is "for" a particular source BD. It | An S-PMSI A-D route is for a particular source BD. It | |||
MUST carry the RT associated with that BD, and it MUST have the | <bcp14>MUST</bcp14> carry the RT associated with that BD, and it <bcp1 | |||
4>MUST</bcp14> have the | ||||
Tag ID for that BD in its NLRI. | Tag ID for that BD in its NLRI. | |||
</t> | </t> | |||
<t> | <t> | |||
When an EVPN&nbhy;PE imports an S&nbhy;PMSI A&nbhy;D route, it | When an EVPN PE imports an S-PMSI A-D route, it | |||
applies the rules of <xref target="bd_route"/> to associate the | applies the rules of <xref target="bd_route" format="default"/> to ass | |||
ociate the | ||||
route with a particular BD. | route with a particular BD. | |||
</t> | </t> | |||
<t> | <t> | |||
Each such route MUST contain a PTA, as specified in <xref | Each such route <bcp14>MUST</bcp14> contain a PTA, as specified in <xr | |||
target="wc_spmsi"/>. | ef target="wc_spmsi" format="default"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
An egress EVPN&nbhy;PE interested in the specified flow or flows | An egress EVPN PE interested in the specified flow or flows | |||
MUST join the specified tunnel. Procedures for joining the | <bcp14>MUST</bcp14> join the specified tunnel. Procedures for joining | |||
the | ||||
specified tunnel are specific to the tunnel type. (Note that if | specified tunnel are specific to the tunnel type. (Note that if | |||
the tunnel type is RSVP&nbhy;TE P2MP LSP, the Leaf Information | the tunnel type is RSVP-TE P2MP LSP, the Leaf Information | |||
Required (LIR) flag of the PTA SHOULD NOT be set. An ingress OISM | Required (LIR) flag of the PTA <bcp14>SHOULD NOT</bcp14> be set. An i | |||
PE knows which OISM EVPN PEs are interested in any given flow, and | ngress OISM | |||
hence can add them to the RSVP&nbhy;TE P2MP tunnel that carries | PE knows which OISM EVPN PEs are interested in any given flow and | |||
hence can add them to the RSVP-TE P2MP tunnel that carries | ||||
such flows.) | such flows.) | |||
<!-- If the tunnel is an --> | </t> | |||
<!-- RSVP-TE P2MP LSP, joining the tunnel will require the sending of | <t> | |||
--> | ||||
<!-- Leaf A-D routes, as discussed in <xref target="I-D.ietf-bess-evpn | ||||
-bum-procedure-updates"/>. --> | ||||
</t> | ||||
<t> | ||||
If the PTA does not specify a non-zero MPLS label, the apparent | If the PTA does not specify a non-zero MPLS label, the apparent | |||
source BD of any packets that arrive on that tunnel is considered | source BD of any packets that arrive on that tunnel is considered | |||
to be the BD associated with the route that carries the PTA. If | to be the BD associated with the route that carries the PTA. If | |||
the PTA does specify a non-zero MPLS label, the apparent source BD | the PTA does specify a non-zero MPLS label, the apparent source BD | |||
of any packets that arrive on that tunnel carrying the specified | of any packets that arrive on that tunnel carrying the specified | |||
label is considered to be the BD associated with the route that | label is considered to be the BD associated with the route that | |||
carries the PTA. | carries the PTA. | |||
</t> | </t> | |||
<t> | <t> | |||
It should be noted that when either IR or BIER is used, there is | It should be noted that, when either IR or BIER is used, there is | |||
no need for an ingress PE to use S&nbhy;PMSI A&nbhy;D routes to | no need for an ingress PE to use S-PMSI A-D routes to | |||
assign specific flows to selective tunnels. The procedures of | assign specific flows to selective tunnels. The procedures of | |||
<xref target="smet_adv"/>, along with the procedures of <xref | <xref target="smet_adv" format="default"/>, along with the procedures | |||
target="imet-ir"/>, <xref target="imet-ar"/>, or <xref | of Sections <xref target="imet-ir" format="counter"/>, <xref target="imet-ar" fo | |||
target="imet-bier"/>, provide the functionality of selective | rmat="counter"/>, and <xref target="imet-bier" format="counter"/>, provide the f | |||
tunnels without the need to use S&nbhy;PMSI A&nbhy;D routes. | unctionality of selective | |||
</t> | tunnels without the need to use S-PMSI A-D routes. | |||
</t> | ||||
</section> <!-- adv_secl --> | </section> | |||
</section> <!-- adv_incl --> | </section> | |||
<section anchor="smet_adv" numbered="true" toc="default"> | ||||
<section title="Advertising SMET Routes" anchor="smet_adv"> | <name>Advertising SMET Routes</name> | |||
<t> | <t> | |||
<xref target="RFC9251"/> allows an egress EVPN&nbhy;PE to express | <xref target="RFC9251" format="default"/> allows an egress EVPN PE to ex | |||
press | ||||
its interest in a particular multicast flow or set of flows by | its interest in a particular multicast flow or set of flows by | |||
originating an SMET route. The NLRI of the SMET route identifies | originating a SMET route. The NLRI of the SMET route identifies | |||
the flow or set of flows as (C&nbhy;*,C&nbhy;*) or | the flow or set of flows as (C-*,C-*), | |||
(C&nbhy;*,C&nbhy;G) or (C&nbhy;S,C&nbhy;G). | (C-*,C-G), or (C-S,C-G). | |||
</t> | </t> | |||
<t> | <t> | |||
Each SMET route belongs to a particular BD. The Tag ID for the BD | Each SMET route belongs to a particular BD. The Tag ID for the BD | |||
appears in the NLRI of the route, and the route carries the RT | appears in the NLRI of the route, and the route carries the RT | |||
associated with that BD. From this <RT, tag> pair, other | associated with that BD. From this <RT, tag> pair, other | |||
EVPN&nbhy;PEs can identify the BD to which a received SMET route | EVPN PEs can identify the BD to which a received SMET route | |||
belongs. (Remember though that the route may be carrying multiple | belongs. (Remember though that the route may be carrying multiple | |||
RTs.) | RTs.) | |||
</t> | </t> | |||
<t> | <t> | |||
There are three cases to consider: | There are three cases to consider: | |||
<list style="symbols"> | </t> | |||
<t> | <ol spacing="normal" type="Case %d:"> | |||
Case 1: It is known that no BD of a Tenant Domain contains a | <li> | |||
<t> | ||||
It is known that no BD of a Tenant Domain contains a | ||||
multicast router. | multicast router. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
In this case, an egress PE advertises its interest in a flow or | In this case, an egress PE advertises its interest in a flow or | |||
set of flows by originating an SMET route that belongs to the | set of flows by originating a SMET route that belongs to the | |||
SBD. We refer to this as an SBD&nbhy;SMET route. The | SBD. We refer to this as an SBD-SMET route. The | |||
SBD&nbhy;SMET route carries the SBD&nbhy;RT, and has the Tag ID | SBD-SMET route carries the SBD-RT and has the Tag ID | |||
for the SBD in its NLRI. SMET routes for the individual BDs are | for the SBD in its NLRI. SMET routes for the individual BDs are | |||
not needed, because there is no need for a PE that receives an | not needed, because there is no need for a PE that receives a | |||
SMET route to send a corresponding IGMP/MLD Join message on any of | SMET route to send a corresponding IGMP/MLD Join message on any of | |||
its ACs. | its ACs. | |||
</t> | </t> | |||
<t> | </li> | |||
Case 2: It is known that more than one BD of a Tenant Domain may | <li> | |||
<t> | ||||
It is known that more than one BD of a Tenant Domain may | ||||
contain a multicast router. | contain a multicast router. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
This is very like Case 1. An egress PE advertises its interest | This is much like Case 1. An egress PE advertises its interest | |||
in a flow or set of flows by originating an SBD&nbhy;SMET route. | in a flow or set of flows by originating an SBD-SMET route. | |||
The SBD&nbhy;SMET route carries the SBD&nbhy;RT, and has the Tag | The SBD-SMET route carries the SBD-RT and has the Tag | |||
ID for the SBD in its NLRI. | ID for the SBD in its NLRI. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
In this case, it is important to be sure that SMET routes for | In this case, it is important to be sure that SMET routes for | |||
the individual BDs are not originated. Suppose, for example, | the individual BDs are not originated. For example, suppose | |||
that PE1 had local receivers for a given flow on both BD1 and | that PE1 had local receivers for a given flow on both BD1 and | |||
BD2, and that it originated SMET routes for both those BDs. | BD2 and that it originated SMET routes for both those BDs. | |||
Then PEs receiving those SMET routes might send IGMP/MLD Joins on | Then, PEs receiving those SMET routes might send IGMP/MLD Joins on | |||
both those BDs. This could cause externally sourced multicast | both those BDs. This could cause externally sourced multicast | |||
traffic to enter the Tenant Domain at both BDs, which could | traffic to enter the Tenant Domain at both BDs, which could | |||
result in duplication of data. | result in duplication of data. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
Note that if it is possible that more than one BD contains a tenant | Note that if it is possible that more than one BD contains a tenant | |||
multicast router, then in order to receive multicast data | multicast router, then in order to receive multicast data | |||
originating from outside EVPN, the PEs MUST follow the | originating from outside EVPN, the PEs <bcp14>MUST</bcp14> follow th | |||
procedures of <xref target="external"/>. | e | |||
</t> | procedures of <xref target="external" format="default"/>. | |||
<t> | </t> | |||
Case 3: It is known that only a single BD of a Tenant Domain | </li> | |||
<li> | ||||
<t> | ||||
It is known that only a single BD of a Tenant Domain | ||||
contains a multicast router. | contains a multicast router. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
Suppose that an egress PE is attached to a BD on which there | Suppose that an egress PE is attached to a BD on which there | |||
might be a tenant multicast router. (The tenant router is not | might be a tenant multicast router. (The tenant router is not | |||
necessarily on a segment that is attached to that PE.) And | necessarily on a segment that is attached to that PE.) And | |||
suppose that the PE has one or more ACs attached to that BD | suppose that the PE has one or more ACs attached to that BD, | |||
which are interested in a given multicast flow. In this case, | which are interested in a given multicast flow. In this case, | |||
in addition to the SMET route for the SBD, the egress PE MAY | in addition to the SMET route for the SBD, the egress PE <bcp14>MAY< | |||
originate an SMET route for that BD. This will enable the | /bcp14> | |||
originate a SMET route for that BD. This will enable the | ||||
ingress PE(s) to send IGMP/MLD messages on ACs for the BD, as | ingress PE(s) to send IGMP/MLD messages on ACs for the BD, as | |||
specified in <xref target="RFC9251"/>. As long as that is | specified in <xref target="RFC9251" format="default"/>. As long as that is | |||
the only BD on which there is a tenant multicast router, there | the only BD on which there is a tenant multicast router, there | |||
is no possibility of duplication of data. | is no possibility of duplication of data. | |||
<!-- <vspace/> --> | </t> | |||
<!-- <vspace/> --> | </li> | |||
<!-- If an SMET route is not an SBD&nbhy;SMET route, and if the SMET | </ol> | |||
--> | <t> | |||
<!-- route is for (C&nbhy;S,C&nbhy;G) (i.e., no wildcard source), an | ||||
d --> | ||||
<!-- if the EVPN&nbhy;PE originating it knows the source BD of --> | ||||
<!-- C&nbhy;S, it MAY put only the RT for that BD on the route. --> | ||||
<!-- Otherwise, the route MUST carry the SBD&nbhy;RT, so that it get | ||||
s --> | ||||
<!-- distributed to all the EVPN&nbhy;PEs attached to the tenant --> | ||||
<!-- domain. --> | ||||
<!-- <vspace/> --> | ||||
<!-- <vspace/> --> | ||||
</t> | ||||
</list> | ||||
</t> | ||||
<t> | ||||
This document does not specify procedures for dynamically | This document does not specify procedures for dynamically | |||
determining which of the three cases applies to a given deployment; | determining which of the three cases applies to a given deployment; | |||
the PEs of a given Tenant Domain MUST be provisioned to know which | the PEs of a given Tenant Domain <bcp14>MUST</bcp14> be provisioned to k now which | |||
case applies. | case applies. | |||
</t> | </t> | |||
<t> | ||||
<t> | As detailed in <xref target="RFC9251"/>, a SMET route carries fla | |||
As detailed in [RFC9251], an SMET route carries flags indicating | gs indicating whether IGMP (v1, v2, or v3) or MLD (v1 or v2) messages should be | |||
whether IGMP (v1, v2 or v3) or MLD (v1 or v2) messages should be triggered on th | triggered on the ACs of the BD to which the SMET route belongs. For IGMP v3 and | |||
e ACs of the BD to which the SMET route belongs. For IGMP v3 and MLD v2, the IE | MLD v2, the Include/Exclude (IE) flag also indicates whether the source informat | |||
flag also indicates whether the source information in the SMET route is of an In | ion in the SMET route is of an Include Group type or Exclude Group type. If an S | |||
clude Group type or Exclude Group type. If an SBD PE needs to generate IGMP/MLD | BD PE needs to generate IGMP/MLD reports (as it is the case in <xref target="ext | |||
reports as it is the case in section 6.2), or the route is for an (S, G) state, | ernal_pim_router"/>) or the route is for an (S, G) state, the value of the flags | |||
the value of the flags MUST be set according to the rules in [RFC9251]. Otherwis | <bcp14>MUST</bcp14> be set according to the rules in <xref target="RFC9251"/>. | |||
e, the flags SHOULD be set to 0. | Otherwise, the flags <bcp14>SHOULD</bcp14> be set to 0. | |||
</t> | </t> | |||
<t> | <t> | |||
Note that a PE only needs to originate the set of SBD&nbhy;SMET | Note that a PE only needs to originate the set of SBD-SMET | |||
routes that are needed to receive multicast traffic in which it is | routes that are needed in order to receive multicast traffic that the PE | |||
interested. Suppose PE1 has ACs attached to BD1 that are interested | is | |||
in (C&nbhy;*,C&nbhy;G) traffic, and ACs attached to BD2 that are | interested in. Suppose PE1 has ACs attached to BD1 that are interested | |||
interested in (C&nbhy;S,C&nbhy;G) traffic. A single SBD&nbhy;SMET | in (C-*,C-G) traffic and ACs attached to BD2 that are | |||
route specifying (C&nbhy;*,C&nbhy;G) will attract all the necessary | interested in (C-S,C-G) traffic. A single SBD-SMET | |||
route specifying (C-*,C-G) will attract all the necessary | ||||
flows. | flows. | |||
</t> | </t> | |||
<t> | <t> | |||
As another example, suppose the ACs attached to BD1 are interested | As another example, suppose the ACs attached to BD1 are interested | |||
in (C&nbhy;*,C&nbhy;G) but not in (C&nbhy;S,C&nbhy;G), while the ACs | in (C-*,C-G) but not in (C-S,C-G), while the ACs | |||
attached to BD2 are interested in (C&nbhy;S,C&nbhy;G). A single | attached to BD2 are interested in (C-S,C-G). A single | |||
SBD&nbhy;SMET route specifying (C&nbhy;*,C&nbhy;G) will pull in all | SBD-SMET route specifying (C-*,C-G) will pull in all | |||
the necessary flows. | the necessary flows. | |||
</t> | </t> | |||
<t> | <t> | |||
In other words, to determine the set of SBD&nbhy;SMET routes that | In other words, to determine the set of SBD-SMET routes that | |||
have to be sent for a given C&nbhy;G, the PE has to merge the | have to be sent for a given C-G, the PE has to merge the | |||
IGMP/MLD state for all the BDs (of the given Tenant Domain) to which | IGMP/MLD state for all the BDs (of the given Tenant Domain) to which | |||
it is attached. | it is attached. | |||
</t> | </t> | |||
<t> | <t> | |||
Per <xref target="RFC9251"/>, importing an SMET route for a | Per <xref target="RFC9251" format="default"/>, importing a SMET route fo | |||
particular BD will cause IGMP/MLD state to be instantiated for the | r a | |||
IRB interface to that BD. This applies as well when the BD is the | particular BD will cause the IGMP/MLD state to be instantiated for the | |||
IRB interface to that BD. This also applies when the BD is the | ||||
SBD. | SBD. | |||
</t> | </t> | |||
<t> | <t> | |||
However, traffic that originates in one of the actual BDs of a | However, traffic that originates in one of the actual BDs of a | |||
particular Tenant Domain MUST NOT be sent down the IRB interface | particular Tenant Domain <bcp14>MUST NOT</bcp14> be sent down the IRB in terface | |||
that connects the L3 routing instance of that Tenant Domain to the | that connects the L3 routing instance of that Tenant Domain to the | |||
SBD. That would cause duplicate delivery of traffic, since such | SBD. That would cause duplicate delivery of traffic, since such | |||
traffic will have already been distributed throughout the Tenant | traffic will have already been distributed throughout the Tenant | |||
Domain. Therefore, when setting up the IGMP/MLD state based on | Domain. Therefore, when setting up the IGMP/MLD state based on | |||
SBD&nbhy;SMET routes, care must be taken to ensure that the IRB | SBD-SMET routes, care must be taken to ensure that the IRB | |||
interface to the SBD is not added to the Outgoing Interface (OIF) | interface to the SBD is not added to the Outgoing Interface (OIF) | |||
list if the traffic originates within the Tenant Domain. | list if the traffic originates within the Tenant Domain. | |||
</t> | </t> | |||
<t> | <t> | |||
There are some multicast scenarios that make use of "anycast | There are some multicast scenarios that make use of anycast | |||
sources". For example, two different sources may share the same | sources. For example, two different sources may share the same | |||
anycast IP address, say S1, and each may transmit an (S1,G) | anycast IP address, say S1, and each may transmit an (S1,G) | |||
multicast flow. In such a scenario, the two (S1,G) flows are | multicast flow. In such a scenario, the two (S1,G) flows are | |||
typically identical. Ordinary PIM procedures will cause only one | typically identical. Ordinary PIM procedures will cause only one of | |||
the flows to be delivered to each receiver that has expressed | the flows to be delivered to each receiver that has expressed | |||
interest in either (*,G) or (S1,G). However, the OISM procedures | interest in either (*,G) or (S1,G). However, the OISM procedures | |||
described in this document will result in both of the (S1,G) flows | described in this document will result in both of the (S1,G) flows | |||
being distributed in the Tenant Domain, and duplicate delivery will | being distributed in the Tenant Domain, and duplicate delivery will | |||
result. Therefore, if there are receivers for (*,G) in a given | result. Therefore, if there are receivers for (*,G) in a given | |||
Tenant Domain, there MUST NOT be anycast sources for G within that | Tenant Domain, there <bcp14>MUST NOT</bcp14> be anycast sources for G wi thin that | |||
Tenant Domain. (This restriction could be lifted by defining | Tenant Domain. (This restriction could be lifted by defining | |||
additional procedures; however that is outside the scope of this | additional procedures; however, that is outside the scope of this | |||
document.) | document.) | |||
</t> | </t> | |||
</section> | ||||
</section> <!-- smet_adv --> | </section> | |||
</section> <!-- adv_tunnels --> | <section anchor="mcast_state" numbered="true" toc="default"> | |||
<name>Constructing Multicast Forwarding State</name> | ||||
<section title="Constructing Multicast Forwarding State" | <section anchor="l2_state" numbered="true" toc="default"> | |||
anchor="mcast_state"> | <name>Layer 2 Multicast State</name> | |||
<section title="Layer 2 Multicast State" anchor="l2_state"> | ||||
<t> | <t> | |||
An EVPN&nbhy;PE maintains "layer 2 multicast state" for each BD to | An EVPN PE maintains Layer 2 multicast state for each BD to | |||
which it is attached. Note that this is used for forwarding IP | which it is attached. Note that this is used for forwarding IP | |||
multicast frames based on the inner IP header. The state is | multicast frames based on the inner IP header. The state is | |||
learned through IGMP/MLD snooping <xref target="RFC4541"/> | learned through IGMP/MLD snooping <xref target="RFC4541" format ="default"/> | |||
and procedures in this document. | and procedures in this document. | |||
</t> | </t> | |||
<t> | <t> | |||
Let PE1 be an EVPN&nbhy;PE, and BD1 be a BD to which it is | Let PE1 be an EVPN PE and BD1 be a BD to which it is | |||
attached. At PE1, BD1's layer 2 multicast state for a given | attached. At PE1, BD1's Layer 2 multicast state for a given | |||
(C&nbhy;S,C&nbhy;G) or (C&nbhy;*,C&nbhy;G) governs the disposition | (C-S,C-G) or (C-*,C-G) governs the disposition | |||
of an IP multicast packet that is received by BD1's layer 2 | of an IP multicast packet that is received by BD1's Layer 2 | |||
multicast function on an EVPN&nbhy;PE. | multicast function on an EVPN PE. | |||
</t> | </t> | |||
<t> | <t> | |||
An IP multicast (S,G) packet is considered to have been received | An IP multicast (S,G) packet is considered to have been received | |||
by BD1's layer 2 multicast function in PE1 in the following | by BD1's Layer 2 multicast function in PE1 in the following | |||
cases: | cases: | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
<li> | ||||
<t> | ||||
The packet is the payload of an Ethernet frame received by PE1 | The packet is the payload of an Ethernet frame received by PE1 | |||
from an AC that attaches to BD1. | from an AC that attaches to BD1. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The packet is the payload of an Ethernet frame whose | The packet is the payload of an Ethernet frame whose | |||
apparent source BD is BD1, and which is received by the PE1 | apparent source BD is BD1, which is received by the PE1 | |||
over a tunnel from another EVPN&nbhy;PE. | over a tunnel from another EVPN PE. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The packet is received from BD1's IRB interface (i.e., has | The packet is received from BD1's IRB interface (i.e., has | |||
been transmitted by PE1's L3 routing instance down BD1's IRB | been transmitted by PE1's L3 routing instance down BD1's IRB | |||
interface). | interface). | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
According to the procedures of this document, all transmission of | According to the procedures of this document, all transmissions of | |||
IP multicast packets from one EVPN&nbhy;PE to another is done at | IP multicast packets from one EVPN PE to another are done at | |||
layer 2. That is, the packets are transmitted as Ethernet frames, | Layer 2. That is, the packets are transmitted as Ethernet frames, | |||
according to the layer 2 multicast state. | according to the Layer 2 multicast state. | |||
</t> | </t> | |||
<t> | <t> | |||
Each layer 2 multicast state (S,G) or (*,G) contains a set of "output | Each Layer 2 multicast state (S,G) or (*,G) contains a set of outgoing | |||
interfaces" (OIF list). The disposition of an (S,G) multicast | interfaces (an OIF list). The disposition of an (S,G) multicast | |||
frame received by BD1's layer 2 multicast function is determined | frame received by BD1's Layer 2 multicast function is determined | |||
as follows: | as follows: | |||
<list style="symbols"> | </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | <t> | |||
The OIF list is taken from BD1's layer 2 (S,G) state, or if | The OIF list is taken from BD1's Layer 2 (S,G) state, or if | |||
there is no such (S,G) state, then from BD1's (*,G) state. | there is no such (S,G) state, then it is taken from BD1's (*,G) st | |||
ate. | ||||
(If neither state exists, the OIF list is considered to be | (If neither state exists, the OIF list is considered to be | |||
null.) | null.) | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | <t> | |||
The rules of <xref target="iif_oif"/> are applied to the OIF | The rules of <xref target="iif_oif" format="default"/> are applied to the OIF | |||
list. This will generally result in the frame being | list. This will generally result in the frame being | |||
transmitted to some, but not all, elements of the OIF list. | transmitted to some, but not all, elements of the OIF list. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
Note that there is no Reverse Path Forwarding (RPF) check at layer 2. | Note that there is no Reverse Path Forwarding (RPF) check at Layer 2. | |||
<!-- In EVPN multicast, it --> | ||||
<!-- is assumed that a given IP source address appears on only a singl | ||||
e --> | ||||
<!-- segment at any one time, therefore no RPF check is --> | ||||
<!-- necessary. However, the OIF list used by a particular PE for a -- | ||||
> | ||||
<!-- particular (S,G) frame depends on the way that the frame was --> | ||||
<!-- received. --> | ||||
</t> | </t> | |||
<section title="Constructing the OIF List" | <section anchor="oif_construct" numbered="true" toc="default"> | |||
anchor="oif_construct"> | <name>Constructing the OIF List</name> | |||
<t> | <t> | |||
In this document, we have extended the procedures of <xref | In this document, we have extended the procedures of <xref target="R | |||
target="RFC9251"/> so that IMET and SMET routes for a | FC9251" format="default"/> so that IMET and SMET routes for a | |||
particular BD are distributed not just to PEs that attach to | particular BD are distributed not just to PEs that attach to | |||
that BD, but to PEs that attach to any BD in the Tenant Domain. | that BD but to PEs that attach to any BD in the Tenant Domain. | |||
In this way, each PE attached to a given Tenant Domain learns, | In this way, each PE attached to a given Tenant Domain learns, | |||
from other PE attached to the same Tenant Domain, the set | from another PE attached to the same Tenant Domain, the set | |||
of flows that are of interest to each of those other PEs. (If | of flows that are of interest to each of those other PEs. (If | |||
some PE attached to the Tenant Domain does not support <xref | some PE attached to the Tenant Domain does not support <xref target= | |||
target="RFC9251"/>, it will be assumed to be interested in | "RFC9251" format="default"/>, it will be assumed to be interested in | |||
all flows. Whether a particular remote PE supports <xref | all flows. Whether or not a particular remote PE supports <xref tar | |||
target="RFC9251"/> is determined by the presence of an | get="RFC9251" format="default"/> is determined by the presence of an | |||
Extended Community in its IMET route; this is specified in <xref | Extended Community in its IMET route; this is specified in <xref tar | |||
target="RFC9251"/>.) If a set of remote PEs are interested | get="RFC9251" format="default"/>.) If a set of remote PEs are interested | |||
in a particular flow, the tunnels used to reach those PEs are | in a particular flow, the tunnels used to reach those PEs are | |||
added to the OIF list of the multicast states corresponding to | added to the OIF list of the multicast states corresponding to | |||
that flow. | that flow. | |||
</t> | </t> | |||
<t> | <t> | |||
An EVPN&nbhy;PE may run IGMP/MLD snooping procedures | An EVPN PE may run IGMP/MLD snooping procedures | |||
<xref target="RFC4541"/> on each of its ACs, | <xref target="RFC4541" format="default"/> on each of its | |||
ACs | ||||
in order to determine the set of flows of interest to each AC. | in order to determine the set of flows of interest to each AC. | |||
(An AC is said to be interested in a given flow if it connects | (An AC is said to be interested in a given flow if it connects | |||
to a segment that has tenant systems interested in that flow.) | to a segment that has tenant systems interested in that flow.) | |||
If IGMP/MLD procedures are not being run on a given AC, that AC | If IGMP/MLD procedures are not being run on a given AC, that AC | |||
is considered to be interested in all flows. For each BD, the | is considered to be interested in all flows. For each BD, the | |||
set of ACs interested in a given flow is determined, and the ACs | set of ACs interested in a given flow is determined, and the ACs | |||
of that set are added to the OIF list of that BD's multicast | of that set are added to the OIF list of that BD's multicast | |||
state for that flow. | state for that flow. | |||
</t> | </t> | |||
<t> | <t> | |||
The OIF list for each multicast state must also contain the | The OIF list for each multicast state must also contain the | |||
IRB interface for the BD to which the state belongs. | IRB interface for the BD to which the state belongs. | |||
<!-- However, a given frame will be sent up only one --> | ||||
<!-- IRB interface, depending upon the source BD of the frame. This | ||||
--> | ||||
<!-- is explained further in <xref target="iif_oif"/>. - | ||||
-> | ||||
</t> | </t> | |||
<t> | <t> | |||
Implementors should note that the OIF list of a multicast state | Implementors should note that the OIF list of a multicast state | |||
will change from time to time as ACs and/or remote PEs either | will change from time to time as ACs and/or remote PEs either | |||
become interested in, or lose interest in, particular multicast | become interested in or lose interest in particular multicast | |||
flows. | flows. | |||
</t> | </t> | |||
</section> <!-- oif_construct --> | </section> | |||
<section anchor="iif_oif" numbered="true" toc="default"> | ||||
<section title="Data Plane: Applying the OIF List to an (S,G) Frame" | <name>Data Plane: Applying the OIF List to an (S,G) Frame</name> | |||
anchor="iif_oif"> | <t> | |||
<t> | When an (S,G) multicast frame is received by the Layer 2 | |||
When an (S,G) multicast frame is received by the layer 2 | multicast function of a given EVPN PE, say PE1, its | |||
multicast function of a given EVPN&nbhy;PE, say PE1, its | disposition depends upon (a) the way it was received, (b) the | |||
disposition depends (a) on the way it was received, (b) upon the | OIF list of the corresponding multicast state (see <xref target="oif | |||
OIF list of the corresponding multicast state (see <xref | _construct" format="default"/>), (c) the eligibility of an AC | |||
target="oif_construct"/>), (c) upon the "eligibility" of an AC | to receive a given frame (see <xref target="ac_eligibility" format=" | |||
to receive a given frame (see <xref target="ac_eligibility"/>) | default"/>), | |||
and (d) upon its apparent source BD (see <xref | and (d) its apparent source BD (see <xref target="adv_tunnels" forma | |||
target="adv_tunnels"/> for information about determining the | t="default"/> for information about determining the | |||
apparent source BD of a frame received over a tunnel from | apparent source BD of a frame received over a tunnel from | |||
another PE). | another PE). | |||
</t> | </t> | |||
<section title="Eligibility of an AC to Receive a Frame" | <section anchor="ac_eligibility" numbered="true" toc="default"> | |||
anchor="ac_eligibility"> | <name>Eligibility of an AC to Receive a Frame</name> | |||
<t> | <t> | |||
A given (S,G) multicast frame is eligible to be transmitted by a | A given (S,G) multicast frame is eligible to be transmitted by a | |||
given PE, say PE1, on a given AC, say AC1, only if one of the | given PE, say PE1, on a given AC, say AC1, only if one of the | |||
following conditions holds: | following conditions holds: | |||
<list style="format %d."> | </t> | |||
<t> | <ol spacing="normal" type="1"><li> | |||
ESI labels are being used, PE1 is the DF for the segment to | <t> | |||
Ethernet Segment Identifier (ESI) labels are being used, PE1 is | ||||
the DF for the segment to | ||||
which AC1 is connected, and the frame did not originate from | which AC1 is connected, and the frame did not originate from | |||
that same segment (as determined by the ESI label), or | that same segment (as determined by the ESI label). | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The ingress PE for the frame is a remote PE, say PE2, | The ingress PE for the frame is a remote PE, say PE2, | |||
local bias is being used, and PE2 is not connected to | local bias is being used, and PE2 is not connected to | |||
the same segment as AC1. | the same segment as AC1. | |||
</t> | </t> | |||
<!-- <t> --> | </li> | |||
<!-- <cref source=" ECR"> --> | </ol> | |||
<!-- Of course, if the frame has no ingress EVPN&nbhy;PE --> | </section> | |||
<!-- (maybe it comes from MVPN) or if we can't tell who --> | <section anchor="oif_apply" numbered="true" toc="default"> | |||
<!-- the ingress EVPN&nbhy;PE is, this won't work. --> | <name>Applying the OIF List</name> | |||
<!-- </cref> --> | <t> | |||
<!-- </t> --> | ||||
</list> | ||||
</t> | ||||
</section> <!-- ac_eligibility --> | ||||
<section title="Applying the OIF List" anchor="oif_apply"> | ||||
<t> | ||||
Assume a given (S,G) multicast frame has been received by a given | Assume a given (S,G) multicast frame has been received by a given | |||
PE, say PE1. PE1 determines the apparent source BD of the frame, | PE, say PE1. PE1 determines the apparent source BD of the frame, | |||
finds the layer 2 (S,G) state for that BD (or the (*,G) | finds the Layer 2 (S,G) state for that BD (or the (*,G) | |||
state if there is no (S,G) state), and uses the OIF list from | state if there is no (S,G) state), and uses the OIF list from | |||
that state. (Note that if PE1 is not attached to the actual | that state. (Note that if PE1 is not attached to the actual | |||
source BD, the apparent source BD will be the SBD.) | source BD, the apparent source BD will be the SBD.) | |||
</t> | </t> | |||
<t> | <t> | |||
Suppose PE1 has determined the frame's apparent source BD to be | If PE1 has determined the frame's apparent source BD to be | |||
BD1 (which may or may not be the SBD.) There are the following | BD1 (which may or may not be the SBD), then the following | |||
cases to consider: | cases should be considered: | |||
<list style="format %d."> | </t> | |||
<t> | <ol spacing="normal" type="1"><li> | |||
<t> | ||||
The frame was received by PE1 from a local AC, say AC1, that | The frame was received by PE1 from a local AC, say AC1, that | |||
attaches to BD1. | attaches to BD1. | |||
<list style="format %c."> | </t> | |||
<t> | <ol spacing="normal" type="a"><li> | |||
The frame MUST be sent on all local ACs of BD1 that | <t> | |||
The frame <bcp14>MUST</bcp14> be sent on all local ACs of BD1 | ||||
that | ||||
appear in the OIF list, except for AC1 itself. | appear in the OIF list, except for AC1 itself. | |||
<!-- (a) AC1 itself, and (b) any AC --> | </t> | |||
<!-- that is attached to the same segment as AC1. --> | </li> | |||
</t> | <li> | |||
<t> | <t> | |||
The frame MUST also be delivered to any other | The frame <bcp14>MUST</bcp14> also be delivered to any other | |||
EVPN&nbhy;PEs that have interest in it. This is achieved | EVPN PEs that have interest in it. This is achieved | |||
as follows: | as follows: | |||
<list style="format %i."> | </t> | |||
<t> | <ol spacing="normal" type="i"><li> | |||
If (a) AR is being used, and (b) PE1 is an | <t> | |||
AR&nbhy;LEAF, and (c) the OIF list is non&nbhy;null, | If (a) AR is being used, (b) PE1 is an | |||
PE1 MUST send the frame to the AR&nbhy;REPLICATOR. | AR-LEAF, and (c) the OIF list is non-null, | |||
</t> | PE1 <bcp14>MUST</bcp14> send the frame to the AR-REPLICAT | |||
<t> | OR. | |||
Otherwise the frame MUST be sent on all tunnels in | </t> | |||
</li> | ||||
<li> | ||||
<t> | ||||
Otherwise, the frame <bcp14>MUST</bcp14> be sent on all t | ||||
unnels in | ||||
the OIF list. | the OIF list. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ol> | |||
<t> | </li> | |||
The frame MUST be sent to the local L3 routing instance | <li> | |||
by being sent up the IRB interface of BD1. It MUST NOT | <t> | |||
The frame <bcp14>MUST</bcp14> be sent to the local L3 routing | ||||
instance | ||||
by being sent up the IRB interface of BD1. It <bcp14>MUST NO | ||||
T</bcp14> | ||||
be sent up any other IRB interfaces. | be sent up any other IRB interfaces. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ol> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The frame was received by PE1 over a tunnel from another PE. | The frame was received by PE1 over a tunnel from another PE. | |||
(See <xref target="adv_tunnels"/> for the rules to determine | (See <xref target="adv_tunnels" format="default"/> for the rules to determine | |||
the apparent source BD of a packet received from another PE. | the apparent source BD of a packet received from another PE. | |||
Note that if PE1 is not attached to the source BD, it will | Note that if PE1 is not attached to the source BD, it will | |||
regard the SBD as the apparent source BD.) | regard the SBD as the apparent source BD.) | |||
<list style="format %c."> | </t> | |||
<t> | <ol spacing="normal" type="a"><li> | |||
The frame MUST be sent on all local ACs in the OIF list that | <t> | |||
connect to BD1 and that are eligible (per <xref | The frame <bcp14>MUST</bcp14> be sent on all local ACs in the | |||
target="ac_eligibility"/>) to receive the frame. | OIF list that | |||
</t> | connect to BD1 and that are eligible (per <xref target="ac_el | |||
<t> | igibility" format="default"/>) to receive the frame. | |||
The frame MUST be sent up the IRB interface of the | </t> | |||
</li> | ||||
<li> | ||||
<t> | ||||
The frame <bcp14>MUST</bcp14> be sent up the IRB interface of | ||||
the | ||||
apparent source BD. (Note that this may be the SBD.) The | apparent source BD. (Note that this may be the SBD.) The | |||
frame MUST NOT be sent up any other IRB interfaces. | frame <bcp14>MUST NOT</bcp14> be sent up any other IRB interf | |||
</t> | aces. | |||
<t> | </t> | |||
If PE1 is not an AR&nbhy;REPLICATOR, it MUST NOT send the | </li> | |||
frame to any other EVPN&nbhy;PEs. However, if PE1 is an | <li> | |||
AR&nbhy;REPLICATOR, it MUST send the frame to all tunnels | <t> | |||
If PE1 is not an AR-REPLICATOR, it <bcp14>MUST NOT</bcp14> se | ||||
nd the | ||||
frame to any other EVPN PEs. However, if PE1 is an | ||||
AR-REPLICATOR, it <bcp14>MUST</bcp14> send the frame to all t | ||||
unnels | ||||
in the OIF list, except for the tunnel over which the | in the OIF list, except for the tunnel over which the | |||
frame was received. | frame was received. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ol> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The frame was received by PE1 from the BD1 IRB interface | The frame was received by PE1 from the BD1 IRB interface | |||
(i.e., the frame has been transmitted by PE1's L3 routing | (i.e., the frame has been transmitted by PE1's L3 routing | |||
instance down the BD1 IRB interface), and BD1 is NOT the | instance down the BD1 IRB interface), and BD1 is NOT the | |||
SBD. | SBD. | |||
<list style="format %c."> | </t> | |||
<t> | <ol spacing="normal" type="a"><li> | |||
The frame MUST be sent on all local ACs in the OIF list | <t> | |||
that are eligible, as per <xref target="ac_eligibility"/>, | The frame <bcp14>MUST</bcp14> be sent on all local ACs in the | |||
OIF list | ||||
that are eligible, as per <xref target="ac_eligibility" forma | ||||
t="default"/>, | ||||
to receive the frame. | to receive the frame. | |||
</t> | </t> | |||
<t> | </li> | |||
The frame MUST NOT be sent to any other EVPN&nbhy;PEs. | <li> | |||
</t> | <t> | |||
<t> | The frame <bcp14>MUST NOT</bcp14> be sent to any other EVPN P | |||
The frame MUST NOT be sent up any IRB interfaces. | Es. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | <li> | |||
<t> | <t> | |||
The frame <bcp14>MUST NOT</bcp14> be sent up any IRB interfac | ||||
es. | ||||
</t> | ||||
</li> | ||||
</ol> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
The frame was received from the SBD IRB interface (i.e., has | The frame was received from the SBD IRB interface (i.e., has | |||
been transmitted by PE1's L3 routing instance down the SBD | been transmitted by PE1's L3 routing instance down the SBD | |||
IRB interface). | IRB interface). | |||
<list style="format %c."> | </t> | |||
<t> | <ol spacing="normal" type="a"><li> | |||
The frame MUST be sent on all tunnels in the OIF list. | <t> | |||
The frame <bcp14>MUST</bcp14> be sent on all tunnels in the O | ||||
IF list. | ||||
This causes the frame to be delivered to any other | This causes the frame to be delivered to any other | |||
EVPN&nbhy;PEs that have interest in it. | EVPN PEs that have interest in it. | |||
</t> | </t> | |||
<t> | </li> | |||
The frame MUST NOT be sent on any local ACs. | <li> | |||
</t> | <t> | |||
<t> | The frame <bcp14>MUST NOT</bcp14> be sent on any local ACs. | |||
The frame MUST NOT be sent up any IRB interfaces. | </t> | |||
</t> | </li> | |||
</list> | <li> | |||
</t> | <t> | |||
</list> | The frame <bcp14>MUST NOT</bcp14> be sent up any IRB interfac | |||
</t> | es. | |||
</section> <!-- oif_apply --> | </t> | |||
</section> <!-- iif_oif --> | </li> | |||
</ol> | ||||
<!-- <section title="OIF List and Tunnels to other EVPN&nbhy;PEs" | </li> | |||
--> | </ol> | |||
<!-- anchor="oif_tunnels"> --> | </section> | |||
<!-- <t> --> | </section> | |||
<!-- When using MPLS to tunnel an IP multicast frame from one PE to | </section> | |||
--> | <section anchor="rpf" numbered="true" toc="default"> | |||
<!-- another, the frame will always carry a label that is specific t | <name>Layer 3 Forwarding State</name> | |||
o --> | <t> | |||
<!-- a BD. We will refer to this as the "BD label". In order to -- | If an EVPN PE is performing IGMP/MLD procedures on the ACs of a | |||
> | given BD, it processes those messages at Layer 2 to help form the | |||
<!-- tunnel the packet, one first pushes on the ESI label, then the | Layer 2 multicast state. It also sends those messages up that BD's | |||
--> | IRB interface to the L3 routing instance of a particular Tenant | |||
<!-- BD label. These labels will be examined by the egress PE(s). - | Domain. This causes the (C-S,C-G) or | |||
-> | (C-*,C-G) L3 state to be created/updated. | |||
<!-- Then one pushes on whatever additional labels are needed to --> | </t> | |||
<!-- transport the packet to the egress PE(s). --> | <t> | |||
<!-- </t> --> | A Layer 3 multicast state has both an Input Interface (IIF) and an | |||
<!-- <t> --> | ||||
<!-- <cref source=" ECR"> --> | ||||
<!-- Did I get the ESI order right? --> | ||||
<!-- </cref> --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- This section specifies how the proper BD label is chosen for -- | ||||
> | ||||
<!-- each type of tunnel. It also discusses other procedures that - | ||||
-> | ||||
<!-- are specific to particular tunnel types. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- <cref source=" ECR"> --> | ||||
<!-- I guess we should also say how to do this with VXLAN. --> | ||||
<!-- </cref> --> | ||||
<!-- </t> --> | ||||
<!-- <section title="Ingress Replication" anchor="oif_ir"> --> | ||||
<!-- <t> --> | ||||
<!-- This section applies when Ingress Replication is the techniqu | ||||
e --> | ||||
<!-- used to tunnel IP multicast frames to other EVPN&nbhy;PEs of a | ||||
--> | ||||
<!-- Tenant Domain. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- When an ingress EVPN&nbhy;PE builds its L2 forwarding state for | ||||
--> | ||||
<!-- (S,G), it needs to determine all the egress EVPN&nbhy;PEs that | ||||
are --> | ||||
<!-- interested in (S,G). How it does this is discussed in <xref | ||||
--> | ||||
<!-- target="cp_overview"/> and in <xref target="interest"/>. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Then for each egress EVPN&nbhy;PE, the ingress PE needs to --> | ||||
<!-- encapsulate the frame in an MPLS packet. It first pushes on | ||||
--> | ||||
<!-- the ESI label. It pushes on a BD label that was assigned by | ||||
--> | ||||
<!-- the egress PE. This label will have been advertised in a PTA | ||||
--> | ||||
<!-- attached to an IMET route originated by that egress PE. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- To find the proper BD label, the ingress PE needs to examine | ||||
--> | ||||
<!-- the IMET routes received from the egress PE. There are two - | ||||
-> | ||||
<!-- cases to consider: --> | ||||
<!-- <list style="numbers"> --> | ||||
<!-- <t> --> | ||||
<!-- There is an installed IMET route from the egress PE for | ||||
--> | ||||
<!-- the source BD of the IP multicast frame. In this case, | ||||
--> | ||||
<!-- the label is taken from the PTA of that route. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- There is no installed IMET route from the egress PE for | ||||
--> | ||||
<!-- the source BD of the IP multicast frame. In this case, | ||||
--> | ||||
<!-- there should be an installed IMET route from the egress | ||||
--> | ||||
<!-- PE for the SBD. The label is taken from the PTA of tha | ||||
t --> | ||||
<!-- route. --> | ||||
<!-- </t> --> | ||||
<!-- </list> --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- If neither case holds, there is an error, and the egress PE - | ||||
-> | ||||
<!-- in question will not receive the (S,G) frame. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- The OIF list for a given multicast state must be constructed | ||||
--> | ||||
<!-- such that a copy of the frame is sent to each interested --> | ||||
<!-- egress PE, with the proper BD label for that egress PE. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- When a frame is received by a given PE over an MPLS ingress - | ||||
-> | ||||
<!-- replication tunnel, its top label will be label that was --> | ||||
<!-- assigned by the receiving PE to a specific BD (possibly the - | ||||
-> | ||||
<!-- SBD). The receiving PE can thus infer the source BD of the - | ||||
-> | ||||
<!-- frame. --> | ||||
<!-- </t> --> | ||||
<!-- </section> <!-\- oif_ir -\-> --> | ||||
<!-- <section title="BIER" anchor="oif_bier"> --> | ||||
<!-- <t> --> | ||||
<!-- Please refer to <xref target="I-D.ietf-bier-evpn"/> for detai | ||||
ls. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- <cref source=" ECR"> --> | ||||
<!-- I'm assuming that everything is covered in that draft, and | ||||
--> | ||||
<!-- we don't have to say anything in this draft. What do you - | ||||
-> | ||||
<!-- think? --> | ||||
<!-- </cref> --> | ||||
<!-- </t> --> | ||||
<!-- </section> <!-\- oif_bier -\-> --> | ||||
<!-- <section title="P2MP LSPs" anchor="oif_p2mp"> --> | ||||
<!-- <section title="RSVP-TE P2MP" anchor="oif_rsvp"> --> | ||||
<!-- <t> --> | ||||
<!-- The procedure for using RSVP-TE P2MP to set up an inclusive --> | ||||
<!-- tunnel is as follows. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- In case of RSVP-TE P2MP, the source NVE establishes a --> | ||||
<!-- P2MP tunnel to all remote NVEs found through the SBD's IMET --> | ||||
<!-- routes and advertises the tunnel in the IMET route for the --> | ||||
<!-- source subnet. If tunnel aggregation is not used, a remote NVE | ||||
--> | ||||
<!-- attached to the source subnet binds the incoming tunnel branch | ||||
--> | ||||
<!-- to the source subnet, and a remote NVE that is not attached to | ||||
--> | ||||
<!-- the source subnet binds the incoming tunnel branch to the SBD. | ||||
--> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- In case of BIER, or if tunnel aggregation is used for --> | ||||
<!-- mLDP/RSVP-TE P2MP, a remote NVE binds the upstream allocated -- | ||||
> | ||||
<!-- label in the IMET route for a source subnet to that subnet if i | ||||
t --> | ||||
<!-- is present on the NVE. Otherwise it binds the label to the SBD. | ||||
--> | ||||
<!-- </t> --> | ||||
<!-- </section> <!-\- oif_rsvp -\-> --> | ||||
<!-- <section title="PIM or mLDP" anchor="oif_pim_mldp"> --> | ||||
<!-- <t> --> | ||||
<!-- In case of PIM/mLDP, a remote NVE joins the tunnel advertised i | ||||
n --> | ||||
<!-- the IMET route for a source subnet. If tunnel aggregation is no | ||||
t --> | ||||
<!-- used, a remote NVE attached to the source subnet binds the --> | ||||
<!-- incoming tunnel branch to the source subnet, and a remote NVE - | ||||
-> | ||||
<!-- that is not attached to the source subnet binds the incoming -- | ||||
> | ||||
<!-- tunnel branch to the SBD. --> | ||||
<!-- </t> --> | ||||
<!-- </section> <!-\- oif-pim_mldp -\-> --> | ||||
<!-- </section> <!-\- oif_p2mp -\-> --> | ||||
<!-- </section> <!-\- oif_tunnels -\-> --> | ||||
</section> <!-- l2_mcast_state --> | ||||
<section title="Layer 3 Forwarding State" anchor="rpf"> | ||||
<t> | ||||
If an EVPN&nbhy;PE is performing IGMP/MLD procedures on the ACs of a | ||||
given BD, it processes those messages at layer 2 to help form the | ||||
layer 2 multicast state. It also sends those messages up that BD's | ||||
IRB interface to the L3 routing instance of a particular tenant | ||||
domain. This causes (C&nbhy;S,C&nbhy;G) or | ||||
(C&nbhy;*,C&nbhy;G) L3 state to be created/updated. | ||||
</t> | ||||
<t> | ||||
A layer 3 multicast state has both an Input Interface (IIF) and an | ||||
OIF list. | OIF list. | |||
</t> | </t> | |||
<t> | <t> | |||
For a (C&nbhy;S,C&nbhy;G) state, if the source BD is present on the PE, | For a (C-S,C-G) state, if the source BD is present on the PE, | |||
the IIF is set to the IRB | the IIF is set to the IRB | |||
interface that attaches to that BD. Otherwise the IIF is set to the | interface that attaches to that BD. Otherwise, the IIF is set to the | |||
SBD IRB interface. | SBD IRB interface. | |||
</t> | </t> | |||
<!--t> | ||||
<cref source=" ECR"> | ||||
And if S is an unknown address? No one else seems bothered by the | ||||
fact that we might need to do an RPF check against an unknown | ||||
address, is there something I am not understanding? | ||||
</cref> | ||||
</t--> | ||||
<t> | <t> | |||
For (C&nbhy;*,C&nbhy;G) states, traffic can arrive from any BD, so | For (C-*,C-G) states, traffic can arrive from any BD, so | |||
the IIF needs to be set to a wildcard value meaning "any IRB | the IIF needs to be set to a wildcard value meaning "any IRB | |||
interface". | interface". | |||
</t> | </t> | |||
<t> | <t> | |||
The OIF list of these states includes one or more of the IRB | The OIF list of these states includes one or more of the IRB | |||
interfaces of the Tenant Domain. In general, maintenance of the OIF | interfaces of the Tenant Domain. In general, maintenance of the OIF | |||
list does not require any EVPN-specific procedures. However, there | list does not require any EVPN-specific procedures. However, there | |||
is one EVPN-specific rule: | is one EVPN-specific rule: | |||
<list> | </t> | |||
<t> | <t indent="3"> | |||
If the IIF is one of the IRB interfaces (or the wild card | If the IIF is one of the IRB interfaces (or the wildcard | |||
meaning "any IRB interface"), then the SBD IRB interface MUST | meaning "any IRB interface"), then the SBD IRB interface <bcp14>MUST | |||
NOT be added to the OIF list. Traffic originating from within a | NOT</bcp14> be added to the OIF list. Traffic originating from with | |||
in a | ||||
particular EVPN Tenant Domain must not be sent down the SBD IRB | particular EVPN Tenant Domain must not be sent down the SBD IRB | |||
interface, as such traffic has already been distributed to all | interface, as such traffic has already been distributed to all | |||
EVPN&nbhy;PEs attached to that Tenant Domain. | EVPN PEs attached to that Tenant Domain. | |||
</t> | </t> | |||
</list> | <t> | |||
</t> | Please also see <xref target="gen_prin" format="default"/>, which states | |||
<t> | a | |||
Please also see <xref target="gen_prin"/>, which states a | ||||
modification of this rule for the case where OISM is interworking | modification of this rule for the case where OISM is interworking | |||
with external Layer 3 multicast routing. | with external Layer 3 multicast routing. | |||
</t> | </t> | |||
</section> | ||||
</section> <!-- rpf --> | </section> | |||
</section> <!-- mcast_state --> | <section anchor="no-OISM" numbered="true" toc="default"> | |||
<name>Interworking with Non-OISM EVPN PEs</name> | ||||
<section title="Interworking with non&nbhy;OISM EVPN&nbhy;PEs" anchor="no-OISM"> | <t> | |||
<t> | ||||
It is possible that a given Tenant Domain will be attached to both OISM | It is possible that a given Tenant Domain will be attached to both OISM | |||
PEs and non&nbhy;OISM PEs. Inter&nbhy;subnet IP multicast should be | PEs and non-OISM PEs. Inter-subnet IP multicast should be | |||
possible and fully functional even if not all PEs attaching to a Tenant | possible and fully functional even if not all PEs attaching to a Tenant | |||
Domain can be upgraded to support OISM functionality. | Domain can be upgraded to support OISM functionality. | |||
</t> | ||||
<t> | ||||
Note that the non&nbhy;OISM PEs are not required to have IRB support, or | ||||
support for <xref target="RFC9251"/>. It is however advantageous for | ||||
the non&nbhy;OISM PEs to support <xref target="RFC9251"/>. | ||||
</t> | ||||
<t> | ||||
In this section, we will use the following terminology: | ||||
<list style="symbols"> | ||||
<t> | ||||
PE&nbhy;S: the ingress PE for an (S,G) flow. | ||||
</t> | </t> | |||
<t> | <t> | |||
PE&nbhy;R: an egress PE for an (S,G) flow. | Note that the non-OISM PEs are not required to have IRB support or | |||
support for <xref target="RFC9251" format="default"/>. However, it is advan | ||||
tageous for | ||||
the non-OISM PEs to support <xref target="RFC9251" format="default"/>. | ||||
</t> | </t> | |||
<t> | <t> | |||
BD&nbhy;S: the source BD for an (S,G) flow. PE&nbhy;S must have one | In this section, we will use the following terminology: | |||
or more ACs attached BD&nbhy;S, at least one of which attaches to | ||||
host S. | ||||
</t> | </t> | |||
<dl spacing="normal" newline="false"> | ||||
<dt>PE-S:</dt> <dd>The ingress PE for an (S,G) flow.</dd> | ||||
<dt>PE-R:</dt> <dd>An egress PE for an (S,G) flow.</dd> | ||||
<dt>BD-S:</dt> <dd>The source BD for an (S,G) flow. PE-S must have on | ||||
e | ||||
or more ACs attached to BD-S, at least one of which attaches to | ||||
host S.</dd> | ||||
<dt>BD-R:</dt> <dd>A BD that contains a host interested in the flow. | ||||
The | ||||
host is attached to PE-R via an AC that belongs to BD-R.</dd> | ||||
</dl> | ||||
<t> | <t> | |||
BD&nbhy;R: a BD that contains a host interested in the flow. The | To allow OISM PEs to interwork with non-OISM PEs, a given Tenant | |||
host is attached to PE&nbhy;R via an AC that belongs to BD&nbhy;R. | Domain needs to contain one or more IP Multicast Gateways (IPMGs). An | |||
</t> | ||||
</list> | ||||
</t> | ||||
<t> | ||||
To allow OISM PEs to interwork with non&nbhy;OISM PEs, a given Tenant | ||||
Domain needs to contain one or more "IP Multicast Gateways" (IPMGs). An | ||||
IPMG is an OISM PE with special responsibilities regarding the | IPMG is an OISM PE with special responsibilities regarding the | |||
interworking between OISM and non&nbhy;OISM PEs. | interworking between OISM and non-OISM PEs. | |||
</t> | </t> | |||
<t> | <t> | |||
If a PE is functioning as an IPMG, it MUST signal this fact by setting | If a PE is functioning as an IPMG, it <bcp14>MUST</bcp14> signal this fact b | |||
the "IPMG" flag in the Multicast Flags EC that it attaches to its IMET | y setting | |||
routes. An IPMG SHOULD attach this EC, with the IPMG flag set, to all | the IPMG flag in the Multicast Flags EC that it attaches to its IMET | |||
routes. An IPMG <bcp14>SHOULD</bcp14> attach this EC, with the IPMG flag se | ||||
t, to all | ||||
IMET routes it originates. Furthermore, if PE1 imports any IMET route from | IMET routes it originates. Furthermore, if PE1 imports any IMET route from | |||
PE2 that has the EC present with the "IPMG" flag set, then the PE1 will | PE2 that has the EC present with the IPMG flag set, then the PE1 will | |||
assume that PE2 is an IPMG. | assume that PE2 is an IPMG. | |||
</t> | </t> | |||
<t> | ||||
An IPMG Designated Forwarder (IPMG&nbhy;DF) selection procedure is used | ||||
to ensure that, at any given time, there is exactly one active | ||||
IPMG&nbhy;DF for any given BD. Details of the IPMG&nbhy;DF selection | ||||
procedure are in <xref target="ipmg-df"/>. The IPMG&nbhy;DF for a given | ||||
BD, say BD&nbhy;S, has special functions to perform when it receives | ||||
(S,G) frames on that BD: | ||||
<list style="symbols"> | ||||
<t> | <t> | |||
If the frames are from a non&nbhy;OISM PE&nbhy;S: | An IPMG Designated Forwarder (IPMG-DF) selection procedure is used | |||
<list style="symbols"> | to ensure that there is exactly one active | |||
IPMG-DF for any given BD at any given time. Details of the IPMG-DF selection | ||||
procedure are in <xref target="ipmg-df" format="default"/>. The IPMG-DF for | ||||
a given | ||||
BD, say BD-S, has special functions to perform when it receives | ||||
(S,G) frames on that BD: | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | <t> | |||
The IPMG&nbhy;DF forwards them to OISM PEs that do not attach to | If the frames are from a non-OISM PE-S: | |||
BD&nbhy;S but have interest in (S,G). | ||||
<vspace/> | ||||
<vspace/> | ||||
Note that OISM PEs that do attach to BD&nbhy;S will have | ||||
received the frames on the BUM tunnel from the non&nbhy;OISM | ||||
PE&nbhy;S. | ||||
</t> | </t> | |||
<t> | <ul spacing="normal"> | |||
The IPMG&nbhy;DF forwards them to non&nbhy;OISM PEs that have | <li> | |||
interest in (S,G) on ACs that do not belong to BD&nbhy;S. | <t> | |||
<vspace/> | The IPMG-DF forwards them to OISM PEs that do not attach to | |||
<vspace/> | BD-S but have interest in (S,G). | |||
Note that if a non&nbhy;OISM PE has multiple BDs (other than | </t> | |||
BD&nbhy;S) with interest in (S,G), it will receive one copy of | <t> | |||
Note that OISM PEs that do attach to BD-S will have | ||||
received the frames on the BUM tunnel from the non-OISM | ||||
PE-S. | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
The IPMG-DF forwards them to non-OISM PEs that have | ||||
interest in (S,G) on ACs that do not belong to BD-S. | ||||
</t> | ||||
<t> | ||||
Note that if a non-OISM PE has multiple BDs (other than | ||||
BD-S) with interest in (S,G), it will receive one copy of | ||||
the frame for each such BD. This is necessary because the | the frame for each such BD. This is necessary because the | |||
non&nbhy;OISM PEs cannot move IP multicast traffic from one BD | non-OISM PEs cannot move IP multicast traffic from one BD | |||
to another. | to another. | |||
</t> | ||||
</li> | ||||
</ul> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
If the frames are from an OISM PE, the IPMG-DF forwards them to | ||||
non-OISM PEs that have interest in (S,G) on ACs that do not | ||||
belong to BD-S. | ||||
</t> | </t> | |||
</list> | <t> | |||
</t> | If a non-OISM PE has interest in (S,G) on an AC belonging to | |||
BD-S, it will have received a copy of the (S,G) frame, | ||||
encapsulated for BD-S, from the OISM PE-S (see <xref target="imet-ir" fo | ||||
rmat="default"/>). If the non-OISM PE has interest in (S,G) | ||||
on one or more ACs belonging to BD-R1,...,BD-Rk where the | ||||
BD-Ri are distinct from BD-S, the IPMG-DF needs to | ||||
send it a copy of the frame for each BD-Ri. | ||||
</t> | ||||
</li> | ||||
</ul> | ||||
<t> | <t> | |||
If the frames are from an OISM PE, the IPMG&nbhy;DF forwards them to | ||||
non&nbhy;OISM PEs that have interest in (S,G) on ACs that do not | ||||
belong to BD&nbhy;S. | ||||
<vspace/> | ||||
<vspace/> | ||||
If a non&nbhy;OISM PE has interest in (S,G) on an AC belonging to | ||||
BD&nbhy;S, it will have received a copy of the (S,G) frame, | ||||
encapsulated for BD&nbhy;S, from the OISM PE&nbhy;S. (See <xref | ||||
target="imet-ir"/>.) If the non&nbhy;OISM PE has interest in (S,G) | ||||
on one or more ACs belonging to BD&nbhy;R1,...,BD&nbhy;Rk where the | ||||
BD&nbhy;Ri are distinct from BD&nbhy;S, the IPMG&nbhy;DF needs to | ||||
send it a copy of the frame for each BD&nbhy;Ri. | ||||
</t> | ||||
</list> | ||||
</t> | ||||
<t> | ||||
If an IPMG receives a frame on a BD for which it is not the | If an IPMG receives a frame on a BD for which it is not the | |||
IPMG&nbhy;DF, it just follows normal OISM procedures. | IPMG-DF, it just follows normal OISM procedures. | |||
</t> | ||||
<t> | ||||
This section specifies several sets of procedures: | ||||
<list style="symbols"> | ||||
<t> | ||||
the procedures that the IPMG&nbhy;DF for a given BD needs to follow | ||||
when receiving, on that BD, an IP multicast frame from a | ||||
non&nbhy;OISM PE; | ||||
</t> | </t> | |||
<t> | <t> | |||
the procedures that the IPMG&nbhy;DF for a given BD needs to follow | This section specifies several sets of procedures: | |||
when receiving, on that BD, an IP multicast frame from an OISM PE; | ||||
</t> | </t> | |||
<t> | <ul spacing="normal"> | |||
<li> | ||||
<t> | ||||
the procedures that the IPMG-DF for a given BD needs to follow | ||||
when receiving, on that BD, an IP multicast frame from a | ||||
non-OISM PE; | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
the procedures that the IPMG-DF for a given BD needs to follow | ||||
when receiving, on that BD, an IP multicast frame from an OISM PE; and | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
the procedures that an OISM PE needs to follow when receiving, on a | the procedures that an OISM PE needs to follow when receiving, on a | |||
given BD, an IP multicast frame from a non&nbhy;OISM PE, when the | given BD, an IP multicast frame from a non-OISM PE, when the | |||
OISM PE is not the IPMG&nbhy;DF for that BD. | OISM PE is not the IPMG-DF for that BD. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
To enable OISM/non&nbhy;OISM interworking in a given Tenant Domain, the | To enable OISM/non-OISM interworking in a given Tenant Domain, the | |||
Tenant Domain MUST have some EVPN&nbhy;PEs that can function as IPMGs. | Tenant Domain <bcp14>MUST</bcp14> have some EVPN PEs that can function as IP | |||
MGs. | ||||
An IPMG must be configured with the SBD. It must also be configured | An IPMG must be configured with the SBD. It must also be configured | |||
with every BD of the Tenant Domain that exists on any of the | with every BD of the Tenant Domain that exists on any of the | |||
non&nbhy;OISM PEs of that domain. (Operationally, it may be simpler to | non-OISM PEs of that domain. (Operationally, it may be simpler to | |||
configure the IPMG with all the BDs of the Tenant Domain.) | configure the IPMG with all the BDs of the Tenant Domain.) | |||
</t> | </t> | |||
<t> | <t> | |||
A non&nbhy;OISM PE of course only needs to be configured with BDs for | Of course, a non-OISM PE only needs to be configured with BDs for | |||
which it has ACs. An OISM PE that is not an IPMG only needs to be | which it has ACs. An OISM PE that is not an IPMG only needs to be | |||
configured with the SBD and with the BDs for which it has ACs. | configured with the SBD and with the BDs for which it has ACs. | |||
</t> | </t> | |||
<t> | <t> | |||
An IPMG MUST originate a wildcard SMET route (with (C&nbhy;*,C&nbhy;*) | An IPMG <bcp14>MUST</bcp14> originate a wildcard SMET route (with (C-*,C-*) | |||
in the NLRI) for each BD in the Tenant Domain. This will cause it to | in the NLRI) for each BD in the Tenant Domain. This will cause it to | |||
receive all the IP multicast traffic that is sourced in the Tenant | receive all the IP multicast traffic that is sourced in the Tenant | |||
Domain. Note that non&nbhy;OISM nodes that do not support <xref | Domain. Note that non-OISM nodes that do not support <xref target="RFC9251" | |||
target="RFC9251"/> will send all the multicast traffic from a given | format="default"/> will send all the multicast traffic from a given | |||
BD to all PEs attached to that BD, even if those PEs do not originate an | BD to all PEs attached to that BD, even if those PEs do not originate a | |||
SMET route. | SMET route. | |||
</t> | </t> | |||
<t> | <t> | |||
The interworking procedures vary somewhat depending upon whether packets | The interworking procedures vary somewhat depending upon whether packets | |||
are transmitted from PE to PE via Ingress Replication (IR) or via | are transmitted from PE to PE via IR or via | |||
Point-to-Multipoint (P2MP) tunnels. We do not consider the use of BIER | P2MP tunnels. In this section, we do not consider the use of BIER | |||
in this section, due to the low likelihood of there being a | due to the low likelihood of there being a | |||
non&nbhy;OISM PE that supports BIER. | non-OISM PE that supports BIER. | |||
</t> | </t> | |||
<section title="IPMG Designated Forwarder" anchor="ipmg-df"> | <section anchor="ipmg-df" numbered="true" toc="default"> | |||
<!-- <t> --> | <name>IPMG Designated Forwarder</name> | |||
<!-- Each IPMG for a given Tenant Domain MUST be configured with an "IPMG | ||||
--> | ||||
<!-- Ethernet Segment" for that domain. This is an Ethernet Segment that | ||||
--> | ||||
<!-- has no ACs. Conceptually, it represents the set of non-OISM PEs --> | ||||
<!-- contained in the Tenant Domain. In the control plane, this Ethernet | ||||
--> | ||||
<!-- Segment is identified by an ESI of Type 0; thus the ESI is an --> | ||||
<!-- arbitrary 9-octet value, managed and configured by the operator. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- EVPN supports a number of procedures that can be used to select the - | ||||
-> | ||||
<!-- Designated Forwarder (DF) for a particular BD on a particular Etherne | ||||
t --> | ||||
<!-- segment. Some of the possible procedures can be found, e.g., in <xre | ||||
f --> | ||||
<!-- target="RFC7432"/>, <xref target="EVPN-DF-NEW"/>, and <xref --> | ||||
<!-- target="I-D.ietf-bess-evpn-pref-df"/>. Whatever procedure is in use | ||||
in a given --> | ||||
<!-- deployment can be adapted to select an IPMG&nbhy;DF for a given BD, a | ||||
s --> | ||||
<!-- follows. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Each IPMG will originate an Ethernet Segment route for the IPMG dummy | ||||
--> | ||||
<!-- Ethernet segment. It MUST carry an ES-Import Route Target whose valu | ||||
e --> | ||||
<!-- is set to the high-order 6-octets of the IPMG ESI. Thus only IPMGs - | ||||
-> | ||||
<!-- will import the route. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Once the set of IPMGs is known, it is also possible to determine the | ||||
--> | ||||
<!-- set of BDs supported by each IPMG. The DF selection procedure can -- | ||||
> | ||||
<!-- then be used to choose a DF for each BD. (The conditions under which | ||||
--> | ||||
<!-- the IPMG&nbhy;DF for a given BD changes depends upon the DF selection | ||||
--> | ||||
<!-- algorithm that is in use.) --> | ||||
<!-- </t> --> | ||||
<t> | <t> | |||
Every PE that is eligible for selection as an IPMG&nbhy;DF for a | Every PE that is eligible for selection as an IPMG-DF for a | |||
particular BD originates both an IMET route for that BD and an | particular BD originates both an IMET route for that BD and an | |||
SBD&nbhy;IMET route. As stated in <xref target="no-OISM"/>, these | SBD-IMET route. As stated in <xref target="no-OISM" format="default"/>, t | |||
SBD&nbhy;IMET routes carry a Multicast Flags EC with the IPMG Flag | hese | |||
SBD-IMET routes carry a Multicast Flags EC with the IPMG flag | ||||
set. | set. | |||
</t> | ||||
<t> | ||||
These SBD&nbhy;IMET routes SHOULD also carry a DF Election EC. The DF | ||||
Election EC and its use is specified in <xref | ||||
target="RFC8584"/>. When the route is originated, the | ||||
AC&nbhy;DF bit in the DF Election EC SHOULD not be set. This bit | ||||
is not used when selecting an IPMSG&nbhy;DF, i.e., it MUST be ignored | ||||
by the receiver of an SBD&nbhy;IMET route. | ||||
</t> | ||||
<t> | ||||
In the context of a given Tenant Domain, to select the IPMG&nbhy;DF | ||||
for a particular BD, say BD1, the IPMGs of the Tenant Domain perform | ||||
the following procedure: | ||||
<list style="symbols"> | ||||
<t> | ||||
From the set of received SBD&nbhy;IMET routes for the given tenant | ||||
domain, determine the candidate set of PEs that support IPMG | ||||
functionality for that domain. | ||||
</t> | </t> | |||
<t> | <t> | |||
Eliminate from that candidate set any PEs from which an IMET route | These SBD-IMET routes <bcp14>SHOULD</bcp14> also carry a DF Election EC. | |||
for BD1 has not been received. | The DF | |||
Election EC and its use is specified in <xref target="RFC8584" format="def | ||||
ault"/>. When the route is originated, the | ||||
AC-DF bit in the DF Election EC <bcp14>SHOULD NOT</bcp14> be set. This bit | ||||
is not used when selecting an IPMG-DF, i.e., it <bcp14>MUST</bcp14> be ign | ||||
ored | ||||
by the receiver of an SBD-IMET route. | ||||
</t> | </t> | |||
<t> | <t> | |||
Select a DF Election algorithm as specified in <xref | In the context of a given Tenant Domain, to select the IPMG-DF | |||
target="RFC8584"/>. Some of the possible algorithms | for a particular BD, say BD1, the IPMGs of the Tenant Domain perform | |||
can be found, e.g., in <xref target="RFC8584"/>, | the following procedures: | |||
<xref target="RFC7432"/>, and <xref target="I-D.ietf-bess-evpn-pref-df | ||||
"/>. | ||||
</t> | </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | ||||
From the set of received SBD-IMET routes for the given Tenant | ||||
Domain, determine the candidate set of PEs that support IPMG | ||||
functionality for that domain. | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
From that candidate set, eliminate any PEs from which an IMET route | ||||
for BD1 has not been received. | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
Select a DF election algorithm as specified in <xref target="RFC8584" | ||||
format="default"/>. Some of the possible algorithms | ||||
can be found, e.g., in <xref target="RFC8584" format="default"/>, | ||||
<xref target="RFC7432" format="default"/>, and <xref target="I-D.ietf- | ||||
bess-evpn-pref-df" format="default"/>. | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
Apply the DF election algorithm (see <xref target="RFC8584" format="de | ||||
fault"/>) to the candidate set of PEs. | ||||
The winner becomes the IPMG-DF for BD1. | ||||
</t> | ||||
</li> | ||||
</ul> | ||||
<t> | <t> | |||
Apply the DF Election Algorithm (see <xref | Note that even if a given PE supports MEG (<xref target="mvpn" format="def | |||
target="RFC8584"/>) to the candidate set of PEs. | ault"/>) | |||
The "winner' becomes the IPMG-DF for BD1. | and/or PEG (<xref target="pim_iwork" format="default"/>) functionality, as | |||
well as IPMG | ||||
functionality, its SBD-IMET routes carry only one DF Election EC. | ||||
</t> | </t> | |||
</list> | </section> | |||
</t> | <section anchor="non-OISM-IR" numbered="true" toc="default"> | |||
<t> | <name>Ingress Replication</name> | |||
Note that even if a given PE supports MEG <xref target="mvpn"/>) | <t> | |||
and/or PEG (<xref target="pim_iwork"/>) functionality, as well as IPMG | The procedures of this section are used when IR is | |||
functionality, its SBD&nbhy;IMET routes carry only one DF Election EC. | ||||
</t> | ||||
</section> <!-- ipmg_df --> | ||||
<section title="Ingress Replication" anchor="non-OISM-IR"> | ||||
<t> | ||||
The procedures of this section are used when Ingress Replication is | ||||
used to transmit packets from one PE to another. | used to transmit packets from one PE to another. | |||
</t> | </t> | |||
<t> | <t> | |||
When a non&nbhy;OISM PE&nbhy;S transmits a multicast frame from | When a non-OISM PE-S transmits a multicast frame from | |||
BD&nbhy;S to another PE, PE&nbhy;R, PE&nbhy;S will use the | BD-S to another PE, say PE-R, PE-S will use the | |||
encapsulation specified in the BD&nbhy;S IMET route that was | encapsulation specified in the BD-S IMET route that was | |||
originated by PE&nbhy;R. This encapsulation will include the label | originated by PE-R. This encapsulation will include the label | |||
that appears in the "MPLS label" field of the PMSI Tunnel attribute | that appears in the MPLS Label field of the | |||
(PTA) of the IMET route. If the tunnel type is VXLAN, the "label" is | PTA of the IMET route. If the tunnel type is VXLAN, the label is | |||
actually a Virtual Network Identifier (VNI); for other tunnel types, | actually a Virtual Network Identifier (VNI); for other tunnel types, | |||
the label is an MPLS label. In either case, we will speak of the | the label is an MPLS label. In either case, | |||
transmitted frames as carrying a label that was assigned to a | the frames are transmitted with a label that was assigned to a | |||
particular BD by the PE&nbhy;R to which the frame is being | particular BD by the PE-R to which the frame is being | |||
transmitted. | transmitted. | |||
</t> | </t> | |||
<t> | <t> | |||
To support OISM/non&nbhy;OISM interworking, an OISM PE&nbhy;R MUST | To support OISM/non-OISM interworking, an OISM PE-R <bcp14>MUST</bcp14> | |||
originate, for each of its BDs, both an IMET route and an S&nbhy;PMSI | originate, for each of its BDs, both an IMET route and an (C-*,C-*) | |||
(C&nbhy;*,C&nbhy;*) A&nbhy;D route. Note that even when IR is being | S-PMSI A-D route. Note that even when IR is being | |||
used, interworking between OISM and non&nbhy;OISM PEs requires the | used, interworking between OISM and non-OISM PEs requires the | |||
OISM PEs to follow the rules of <xref target="wc_spmsi"/>, as modified | OISM PEs to follow the rules of <xref target="wc_spmsi" format="default"/> | |||
, as modified | ||||
below. | below. | |||
</t> | </t> | |||
<t> | <t> | |||
Non&nbhy;OISM PEs will not understand S&nbhy;PMSI A&nbhy;D routes. So | Non-OISM PEs will not understand S-PMSI A-D routes. So | |||
when a non&nbhy;OISM PE&nbhy;S transmits an IP multicast frame with a | when a non-OISM PE-S transmits an IP multicast frame with a | |||
particular source BD to an IPMG, it encapsulates the frame using the | particular source BD to an IPMG, it encapsulates the frame using the | |||
label specified in that IPMG's BD&nbhy;S IMET route. (This is just | label specified in that IPMG's BD-S IMET route. (This is just | |||
the procedure of <xref target="RFC7432"/>.) | the procedure of <xref target="RFC7432" format="default"/>.) | |||
</t> | </t> | |||
<t> | ||||
The (C&nbhy;*,C&nbhy;*) S&nbhy;PMSI A&nbhy;D route originated by a | ||||
given OISM PE will have a PTA that specifies IR. | ||||
<list style="symbols"> | ||||
<t> | <t> | |||
If MPLS tunneling is being used, the MPLS label field SHOULD | The (C-*,C-*) S-PMSI A-D route originated by a | |||
contain a non&nbhy;zero value, and the LIR flag SHOULD be zero. | given OISM PE will have a PTA that specifies IR. | |||
(The case where the MPLS label field is zero or the LIR flag is | ||||
set is outside the scope of this document.) | ||||
</t> | </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | ||||
If MPLS tunneling is being used, the MPLS Label field <bcp14>SHOULD</b | ||||
cp14> | ||||
contain a non-zero value, and the LIR flag <bcp14>SHOULD</bcp14> be ze | ||||
ro. | ||||
(The case where the MPLS Label field is zero or the LIR flag is | ||||
set is outside the scope of this document.) | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
If the tunnel encapsulation is VXLAN, the MPLS Label field <bcp14>MUST | ||||
</bcp14> | ||||
contain a non-zero value, and the LIR flag <bcp14>MUST</bcp14> be zero | ||||
. | ||||
</t> | ||||
</li> | ||||
</ul> | ||||
<t> | <t> | |||
If the tunnel encapsulation is VXLAN, the MPLS label field MUST | When an OISM PE-S transmits an IP multicast frame to an IPMG, it | |||
contain a non&nbhy;zero value, and the LIR flag MUST be zero. | will use the label specified in that IPMG's (C-*,C-*) | |||
S-PMSI A-D route. | ||||
</t> | </t> | |||
</list> | <t> | |||
</t> | When a PE originates both an IMET route and a (C-*,C-*) | |||
<t> | S-PMSI A-D route, the values of the MPLS Label field in the | |||
When an OISM PE&nbhy;S transmits an IP multicast frame to an IPMG, it | respective PTAs must be distinct. Further, each <bcp14>MUST</bcp14> map u | |||
will use the label specified in that IPMG's (C&nbhy;*,C&nbhy;*) | niquely (in | |||
S&nbhy;PMSI A&nbhy;D route. | ||||
</t> | ||||
<t> | ||||
When a PE originates both an IMET route and a (C&nbhy;*,C&nbhy;*) | ||||
S&nbhy;PMSI A&nbhy;D route, the values of the MPLS label field in the | ||||
respective PTAs must be distinct. Further, each MUST map uniquely (in | ||||
the context of the originating PE) to the route's BD. | the context of the originating PE) to the route's BD. | |||
</t> | </t> | |||
<!-- <t> --> | ||||
<!-- In MPLS networks, it is also possible to originate an S&nbhy;PMSI A-D r | ||||
oute --> | ||||
<!-- whose PTA specifies a zero in the MPLS label field, and whose "PTA -- | ||||
> | ||||
<!-- flags" field has the "Leaf Information Required" bit set. This will | ||||
--> | ||||
<!-- cause each OISM PE to send a Leaf A-D route to each other OISM PE, -- | ||||
> | ||||
<!-- specifying the label to use when transmitting to it a frame of the -- | ||||
> | ||||
<!-- corresponding source BD. --> | ||||
<!-- </t> --> | ||||
<t> | <t> | |||
As a result, an IPMG receiving an MPLS-encapsulated IP multicast frame | As a result, an IPMG receiving an MPLS-encapsulated IP multicast frame | |||
can always tell by the label whether the frame's ingress PE is an OISM | can always tell by the label whether the frame's ingress PE is an OISM | |||
PE or a non&nbhy;OISM PE. When an IPMG receives a VXLAN-encapsulated | PE or a non-OISM PE. When an IPMG receives a VXLAN-encapsulated | |||
IP multicast frame it may need to determine the identity of the | IP multicast frame, it may need to determine the identity of the | |||
ingress PE from the outer IP encapsulation; it can then determine | ingress PE from the outer IP encapsulation; it can then determine | |||
whether the ingress PE is an OISM PE or a non&nbhy;OISM PE by looking | whether the ingress PE is an OISM PE or a non-OISM PE by looking at | |||
the IMET route from that PE. | the IMET route from that PE. | |||
</t> | </t> | |||
<t> | <t> | |||
Suppose an IPMG receives an IP multicast frame from another | Suppose an IPMG receives an IP multicast frame from another | |||
EVPN&nbhy;PE in the Tenant Domain, and the IPMG is not the | EVPN PE in the Tenant Domain and the IPMG is not the | |||
IPMG&nbhy;DF for the frame's source BD. Then the IPMG performs only | IPMG-DF for the frame's source BD. Then, the IPMG performs only | |||
the ordinary OISM functions; it does not perform the IPMG-specific | the ordinary OISM functions; it does not perform the IPMG-specific | |||
functions for that frame. In the remainder of this section, when we | functions for that frame. In the remainder of this section, when we | |||
discuss the procedures applied by an IPMG when it receives an IP | discuss the procedures applied by an IPMG when it receives an IP | |||
multicast frame, we are presuming that the source BD of the frame is a | multicast frame, we are presuming that the source BD of the frame is a | |||
BD for which the IPMG is the IPMG&nbhy;DF. | BD for which the IPMG is the IPMG-DF. | |||
</t> | </t> | |||
<t> | <t> | |||
We have two basic cases to consider: (1) a frame's ingress PE is a | We have two basic cases to consider: (1) a frame's ingress PE is a | |||
non&nbhy;OISM node, and (2) a frame's ingress PE is an OISM node. | non-OISM node and (2) a frame's ingress PE is an OISM node. | |||
</t> | </t> | |||
<section title="Ingress PE is non&nbhy;OISM" anchor="pe-s-non-oism"> | <section anchor="pe-s-non-oism" numbered="true" toc="default"> | |||
<t> | <name>Ingress PE is Non-OISM</name> | |||
In this case, a non&nbhy;OISM PE, PE&nbhy;S, has received an (S,G) | <t> | |||
In this case, a non-OISM PE, say PE-S, has received an (S,G) | ||||
multicast frame over an AC that is attached to a particular BD, | multicast frame over an AC that is attached to a particular BD, | |||
BD&nbhy;S. By virtue of normal EVPN procedures, PE&nbhy;S has sent | say BD-S. By virtue of normal EVPN procedures, PE-S has sent | |||
a copy of the frame to every PE&nbhy;R (both OISM and non&nbhy;OISM) | a copy of the frame to every PE-R (both OISM and non-OISM) | |||
in the Tenant Domain that is attached to BD&nbhy;S. If the | in the Tenant Domain that is attached to BD-S. If the | |||
non&nbhy;OISM node supports <xref target="RFC9251"/>, only PEs | non-OISM node supports <xref target="RFC9251" format="default"/>, only P | |||
Es | ||||
that have expressed interest in (S,G) receive the frame. The IPMG | that have expressed interest in (S,G) receive the frame. The IPMG | |||
will have expressed interest via a (C&nbhy;*,C&nbhy;*) SMET route | will have expressed interest via a (C-*,C-*) SMET route | |||
and thus receives the frame. | and thus receives the frame. | |||
</t> | </t> | |||
<t> | <t> | |||
Any OISM PE (including an IPMG) receiving the frame will apply | Any OISM PE (including an IPMG) receiving the frame will apply | |||
normal OISM procedures. As a result it will deliver the frame to | normal OISM procedures. As a result, it will deliver the frame to | |||
any of its local ACs (in BD&nbhy;S or in any other BD) that have | any of its local ACs (in BD-S or in any other BD) that have | |||
interest in (S,G). | interest in (S,G). | |||
</t> | </t> | |||
<t> | <t> | |||
An OISM PE that is also the IPMG&nbhy;DF for a particular BD, say | An OISM PE that is also the IPMG-DF for a particular BD, say | |||
BD&nbhy;S, has additional procedures that it applies to frames | BD-S, has additional procedures that it applies to frames | |||
received on BD&nbhy;S from non&nbhy;OISM PEs: | received on BD-S from non-OISM PEs: | |||
<list style="format %d. "> | </t> | |||
<t anchor="non-oism-to-oism"> | <ol spacing="normal" type="1"><li anchor="non-oism-to-oism"> | |||
When the IPMG&nbhy;DF for BD&nbhy;S receives an (S,G) frame from | <t> | |||
a non&nbhy;OISM node, it MUST forward a copy of the frame to | When the IPMG-DF for BD-S receives an (S,G) frame from | |||
every OISM PE that is NOT attached to BD&nbhy;S but has interest | a non-OISM node, it <bcp14>MUST</bcp14> forward a copy of the frame | |||
in (S,G). The copy sent to a given OISM PE&nbhy;R must carry | to | |||
the label that PE&nbhy;R has assigned to the SBD in an | every OISM PE that is NOT attached to BD-S but has interest | |||
S&nbhy;PMSI A&nbhy;D route. The IPMG MUST NOT do any IP | in (S,G). The copy sent to a given OISM PE-R must carry | |||
the label that PE-R has assigned to the SBD in an | ||||
S-PMSI A-D route. The IPMG <bcp14>MUST NOT</bcp14> do any IP | ||||
processing of the frame's IP payload. TTL decrement and other | processing of the frame's IP payload. TTL decrement and other | |||
IP processing will be done by PE&nbhy;R, per the normal OISM | IP processing will be done by PE-R, per the normal OISM | |||
procedures. There is no need for the IPMG to include an ESI | procedures. There is no need for the IPMG to include an ESI | |||
label in the frame's tunnel encapsulation, because it is already | label in the frame's tunnel encapsulation, because it is already | |||
known that the frame's source BD has no presence on | known that the frame's source BD has no presence on | |||
PE&nbhy;R. There is also no need for the IPMG to modify the | PE-R. There is also no need for the IPMG to modify the | |||
frame's MAC SA. | frame's MAC SA. | |||
</t> | </t> | |||
<t anchor="non-oism-to-non-oism"> | </li> | |||
In addition, when the IPMG&nbhy;DF for BD&nbhy;S receives an | <li anchor="non-oism-to-non-oism"> | |||
(S,G) frame from a non&nbhy;OISM node, it may need to forward | <t> | |||
copies of the frame to other non&nbhy;OISM nodes. Before it | In addition, when the IPMG-DF for BD-S receives an | |||
does so, it MUST decapsulate the (S,G) packet, and do the IP | (S,G) frame from a non-OISM node, it may need to forward | |||
processing (e.g., TTL decrement). Suppose PE&nbhy;R is a | copies of the frame to other non-OISM nodes. Before it | |||
non&nbhy;OISM node that has an AC to BD&nbhy;R, where BD&nbhy;R | does so, it <bcp14>MUST</bcp14> decapsulate the (S,G) packet and do | |||
is not the same as BD&nbhy;S, and that AC has interest in (S,G). | the IP | |||
processing (e.g., TTL decrement). Suppose PE-R is a | ||||
non-OISM node that has an AC to BD-R, where BD-R | ||||
is not the same as BD-S, and that AC has interest in (S,G). | ||||
The IPMG must then encapsulate the (S,G) packet (after the IP | The IPMG must then encapsulate the (S,G) packet (after the IP | |||
processing has been done) in an Ethernet header. The MAC SA | processing has been done) in an Ethernet header. The MAC SA | |||
field will have the MAC address of the IPMG's IRB interface for | field will have the MAC address of the IPMG's IRB interface for | |||
BD&nbhy;R. The IPMG then sends the frame to PE&nbhy;R. The | BD-R. The IPMG then sends the frame to PE-R. The | |||
tunnel encapsulation will carry the label that PE&nbhy;R | tunnel encapsulation will carry the label that PE-R | |||
advertised in its IMET route for BD&nbhy;R. There is no need to | advertised in its IMET route for BD-R. There is no need to | |||
include an ESI label, as the source and destination BDs are | include an ESI label, as the source and destination BDs are | |||
known to be different. | known to be different. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
Note that if a non&nbhy;OISM PE&nbhy;R has several BDs (other | Note that if a non-OISM PE-R has several BDs (other | |||
than BD&nbhy;S) with local ACs that have interest in (S,G), the | than BD-S) with local ACs that have interest in (S,G), the | |||
IPMG will send it one copy for each such BD. This is necessary | IPMG will send it one copy for each such BD. This is necessary | |||
because the non&nbhy;OISM PE cannot move packets from one BD to | because the non-OISM PE cannot move packets from one BD to | |||
another. | another. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ol> | |||
<t> | <t> | |||
There may be deployment scenarios in which every OISM PE is | There may be deployment scenarios in which every OISM PE is | |||
configured with every BD that is present on any non&nbhy;OISM PE. | configured with every BD that is present on any non-OISM PE. | |||
In such scenarios, the procedures of item <xref | In such scenarios, the procedures of item <xref target="non-oism-to-oism | |||
target="non-oism-to-oism" format="counter"/> above will not actually | " format="counter"/> above will not actually | |||
result in the transmission of any packets. Hence if it is known a | result in the transmission of any packets. Hence, if it is known a | |||
priori that this deployment scenario exists for a given tenant | priori that this deployment scenario exists for a given Tenant | |||
domain, the procedures of item <xref target="non-oism-to-oism" | Domain, the procedures of item <xref target="non-oism-to-oism" format="c | |||
format="counter"/> above can be disabled. | ounter"/> above can be disabled. | |||
</t> | </t> | |||
</section> <!-- PE&nbhy;S-non&nbhy;OISM --> | </section> | |||
<section title="Ingress PE is OISM" anchor="pe-s-oism"> | <section anchor="pe-s-oism" numbered="true" toc="default"> | |||
<t> | <name>Ingress PE is OISM</name> | |||
In this case, an OISM PE, PE&nbhy;S, has received an (S,G) multicast | ||||
frame over an AC that attaches to a particular BD, BD&nbhy;S. | ||||
</t> | ||||
<t> | ||||
By virtue of receiving all the IMET routes for BD&nbhy;S, | ||||
PE&nbhy;S will know all the PEs attached to BD&nbhy;S. By virtue of | ||||
normal OISM procedures: | ||||
<list style="symbols"> | ||||
<t> | <t> | |||
PE&nbhy;S will send a copy of the frame to every OISM PE&nbhy;R | In this case, an OISM PE, say PE-S, has received an (S,G) multicast | |||
(including the IPMG) in the Tenant Domain that is attached to | frame over an AC that attaches to a particular BD, say BD-S. | |||
BD&nbhy;S and has interest in (S,G). The copy sent to a given | ||||
PE&nbhy;R carries the label that that the PE&nbhy;R has assigned | ||||
to BD&nbhy;S in its (C&nbhy;*,C&nbhy;*) S&nbhy;PMSI A&nbhy;D | ||||
route. | ||||
<!-- or Leaf A-D route. --> | ||||
</t> | </t> | |||
<t> | <t> | |||
PE&nbhy;S will also transmit a copy of the (S,G) frame to every | By virtue of receiving all the IMET routes for BD-S, | |||
OISM PE&nbhy;R that has interest in (S,G) but is not attached to | PE-S will know all the PEs attached to BD-S. By virtue of | |||
BD&nbhy;S. The copy will contain the label that the PE&nbhy;R | normal OISM procedures: | |||
has assigned to the SBD. (As specified in <xref target="pe-s-non-oi | </t> | |||
sm"/>, | <ul spacing="normal"> | |||
<li> | ||||
<t> | ||||
PE-S will send a copy of the frame to every OISM PE-R | ||||
(including the IPMG) in the Tenant Domain that is attached to | ||||
BD-S and has interest in (S,G). The copy sent to a given | ||||
PE-R carries the label that the PE-R has assigned | ||||
to BD-S in its (C-*,C-*) S-PMSI A-D | ||||
route. | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
PE-S will also transmit a copy of the (S,G) frame to every | ||||
OISM PE-R that has interest in (S,G) but is not attached to | ||||
BD-S. The copy will contain the label that the PE-R | ||||
has assigned to the SBD. (As specified in <xref target="pe-s-non-oi | ||||
sm" format="default"/>, | ||||
an IPMG is assumed to have indicated interest in all multicast | an IPMG is assumed to have indicated interest in all multicast | |||
flows.) | flows.) | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | ||||
PE-S will also transmit a copy of the (S,G) frame to every | ||||
non-OISM PE-R that is attached to BD-S. It does | ||||
this using the label advertised by that PE-R in its IMET | ||||
route for BD-S. | ||||
</t> | ||||
</li> | ||||
</ul> | ||||
<t> | <t> | |||
PE&nbhy;S will also transmit a copy of the (S,G) frame to every | The PE-Rs follow their normal procedures. An OISM PE that | |||
non&nbhy;OISM PE&nbhy;R that is attached to BD&nbhy;S. It does | receives the (S,G) frame on BD-S applies the OISM procedures to | |||
this using the label advertised by that PE&nbhy;R in its IMET | deliver the frame to its local ACs as necessary. A non-OISM | |||
route for BD&nbhy;S. | PE that receives the (S,G) frame on BD-S delivers the frame | |||
only to its local BD-S ACs as necessary. | ||||
</t> | </t> | |||
</list> | <t> | |||
</t> | Suppose that a non-OISM PE-R has interest in (S,G) on a | |||
<t> | BD that is different than BD-S, say BD-R. If the | |||
The PE&nbhy;Rs follow their normal procedures. An OISM PE that | non-OISM PE-R is attached to BD-S, the OISM PE-S | |||
receives the (S,G) frame on BD&nbhy;S applies the OISM procedures to | ||||
deliver the frame to its local ACs, as necessary. A non&nbhy;OISM | ||||
PE that receives the (S,G) frame on BD&nbhy;S delivers the frame | ||||
only to its local BD&nbhy;S ACs, as necessary. | ||||
</t> | ||||
<t> | ||||
Suppose that a non&nbhy;OISM PE&nbhy;R has interest in (S,G) on a | ||||
BD, BD&nbhy;R, that is different than BD&nbhy;S. If the | ||||
non&nbhy;OISM PE&nbhy;R is attached to BD&nbhy;S, the OISM PE&nbhy;S | ||||
will send it the original (S,G) multicast frame, but the | will send it the original (S,G) multicast frame, but the | |||
non&nbhy;OISM PE&nbhy;R will not be able to send the frame to ACs | non-OISM PE-R will not be able to send the frame to ACs | |||
that are not in BD&nbhy;S. If PE&nbhy;R is not even attached to | that are not in BD-S. If PE-R is not even attached to | |||
BD&nbhy;S, the OISM PE&nbhy;S will not send it a copy of the frame | BD-S, the OISM PE-S will not send it a copy of the frame | |||
at all, because PE&nbhy;R is not attached to the SBD. In these | at all, because PE-R is not attached to the SBD. In these | |||
cases, the IPMG needs to relay the (S,G) multicast traffic from OISM | cases, the IPMG needs to relay the (S,G) multicast traffic from OISM | |||
PE&nbhy;S to non&nbhy;OISM PE&nbhy;R. | PE-S to non-OISM PE-R. | |||
</t> | </t> | |||
<t> | <t> | |||
When the IPMG&nbhy;DF for BD&nbhy;S receives an (S,G) frame from an | When the IPMG-DF for BD-S receives an (S,G) frame from an | |||
OISM PE&nbhy;S, it has to forward it to every non&nbhy;OISM | OISM PE-S, it has to forward it to every non-OISM | |||
PE&nbhy;R that that has interest in (S,G) on a BD&nbhy;R that is | PE-R that has interest in (S,G) on a BD-R that is | |||
different than BD&nbhy;S. The IPMG MUST decapsulate the IP | different than BD-S. The IPMG <bcp14>MUST</bcp14> decapsulate the IP | |||
multicast packet, do the IP processing, re-encapsulate it for | multicast packet, do the IP processing, re-encapsulate it for | |||
BD&nbhy;R (changing the MAC SA to the IPMG's own MAC address for | BD-R (changing the MAC SA to the IPMG's own MAC address for | |||
BD&nbhy;R), and send a copy of the frame to PE&nbhy;R. Note that a | BD-R), and send a copy of the frame to PE-R. Note that a | |||
given non&nbhy;OISM PE&nbhy;R will receive multiple copies of the | given non-OISM PE-R will receive multiple copies of the | |||
frame, if it has multiple BDs on which there is interest in the | frame if it has multiple BDs on which there is interest in the | |||
frame. | frame. | |||
</t> | </t> | |||
</section> <!-- pe-s-oism --> | </section> | |||
</section> <!-- non&nbhy;OISM-IR --> | </section> | |||
<section anchor="non-oism-p2mp" numbered="true" toc="default"> | ||||
<section title="P2MP Tunnels" anchor="non-oism-p2mp"> | <name>P2MP Tunnels</name> | |||
<t> | <t> | |||
When IR is used to distribute the multicast traffic among the | When IR is used to distribute the multicast traffic among the | |||
EVPN&nbhy;PEs, the procedures of <xref target="non-OISM-IR"/> ensure | EVPN PEs, the procedures described in <xref target="non-OISM-IR" format="d efault"/> ensure | |||
that there will be no duplicate delivery of multicast traffic. That | that there will be no duplicate delivery of multicast traffic. That | |||
is, no egress PE will ever send a frame twice on any given AC. If | is, no egress PE will ever send a frame twice on any given AC. If | |||
P2MP tunnels are being used to distribute the multicast traffic, it is | P2MP tunnels are being used to distribute the multicast traffic, it is | |||
necessary to have additional procedures to prevent duplicate delivery. | necessary to have additional procedures to prevent duplicate delivery. | |||
</t> | </t> | |||
<t> | <t> | |||
At the present time, it is not clear that there will be a use case in | At the present time, it is not clear that there will be a use case in | |||
which OISM nodes need to interwork with non&nbhy;OISM nodes that use | which OISM nodes need to interwork with non-OISM nodes that use | |||
P2MP tunnels. If it is determined that there is such a use case, | P2MP tunnels. If it is determined that there is such a use case, | |||
procedures for P2MP may be specified in a separate document. | procedures for P2MP may be specified in a separate document. | |||
</t> | </t> | |||
</section> | ||||
</section> <!-- non-oism-p2mp --> | </section> | |||
<!-- <section title="P2MP Tunnels" anchor="non-oism-p2mp"> --> | <section anchor="external" numbered="true" toc="default"> | |||
<!-- <t> --> | <name>Traffic to/from Outside the EVPN Tenant Domain</name> | |||
<!-- <cref source=" ECR"> --> | <t> | |||
<!-- This section still preliminary, and may never actually be --> | ||||
<!-- needed. Hence it will probably be omitted from the next rev. | ||||
--> | ||||
<!-- We might want to say something short like "procedures will be | ||||
--> | ||||
<!-- provided if it is determined that this is a valid use case". | ||||
--> | ||||
<!-- </cref> --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- When IR is used to distribute the multicast traffic among the - | ||||
-> | ||||
<!-- EVPN-PEs, the procedures of <xref target="non-OISM-IR"/> ensure | ||||
--> | ||||
<!-- that there will be no duplicate delivery of multicast traffic. | ||||
--> | ||||
<!-- That is, no egress PE will ever send a frame twice on any given | ||||
--> | ||||
<!-- AC. If P2MP tunnels are being used to distribute the multicast | ||||
--> | ||||
<!-- traffic, it is necessary have additional procedures to prevent | ||||
--> | ||||
<!-- duplicate delivery. --> | ||||
<!-- <list style="symbols"> --> | ||||
<!-- <t> --> | ||||
<!-- Every OISM PE (including the IPMGs) MUST follow the --> | ||||
<!-- procedures of <xref target="wc_spmsi"/> to advertise IP --> | ||||
<!-- Multicast Tunnels that are distinct from the BUM tunnels. - | ||||
-> | ||||
<!-- OISM PEs MUST NOT send IP multicast frames on the BUM --> | ||||
<!-- tunnels. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- The IPMG that is the DF for a given BD MUST join all the IP | ||||
--> | ||||
<!-- multicast tunnels for that BD from OISM PEs. Thus the IPMG | ||||
--> | ||||
<!-- for a given source BD, say BD-S, will receive each IP --> | ||||
<!-- multicast frame whose source BD is BD-S and whose ingress P | ||||
E --> | ||||
<!-- is OISM. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Since non-OISM PEs do not join the IP multicast tunnels, IP | ||||
--> | ||||
<!-- multicast traffic from an OISM ingress PE to a set of --> | ||||
<!-- non-OISM egress PEs must be relayed by the IPMG. --> | ||||
<!-- <vspace/> --> | ||||
<!-- <vspace/> --> | ||||
<!-- Note that the IPMG does not relay IP multicast frames from | ||||
--> | ||||
<!-- an ingress OISM PE to any egress OISM PEs. --> | ||||
<!-- <vspace/> --> | ||||
<!-- <vspace/> --> | ||||
<!-- Since non-OISM PEs expect to receive IP multicast frames on | ||||
--> | ||||
<!-- the BUM tunnels, the IPMG must advertise a tunnel for each | ||||
--> | ||||
<!-- BD that looks to non-OISM nodes as if it were an ordinary - | ||||
-> | ||||
<!-- BUM tunnel, but is not joined by the OISM nodes. We will - | ||||
-> | ||||
<!-- refer to these as "non-OISM BUM tunnels". --> | ||||
<!-- </t> --> | ||||
<!-- </list> --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Consider an IP multicast frame whose ingress PE is non-OISM --> | ||||
<!-- and whose source BD is BD-S. --> | ||||
<!-- <list style="symbols"> --> | ||||
<!-- <t> --> | ||||
<!-- The procedures of <xref target="RFC7432"/> will cause the - | ||||
-> | ||||
<!-- frame to be sent to all other PEs (OISM or non-OISM) that - | ||||
-> | ||||
<!-- attach to BD-S. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- If the frame has any non-OISM egress PEs with receivers tha | ||||
t --> | ||||
<!-- are in BD-R, where BD-R is different than BD-S, the IPMG -- | ||||
> | ||||
<!-- must relay the frame to the egress non-OISM PEs. It does - | ||||
-> | ||||
<!-- this by doing the IP processing of the frame's IP multicast | ||||
--> | ||||
<!-- packet, and then re-encapsulating the packet for BD-R. --> | ||||
<!-- After re-encapsulation, the MAC SA field of the Ethernet -- | ||||
> | ||||
<!-- header carries the MAC address used by the IPMG itself in - | ||||
-> | ||||
<!-- BD-R. Then the frame is transmitted on the non-OISM BUM -- | ||||
> | ||||
<!-- tunnel for BD-R. --> | ||||
<!-- <vspace/> --> | ||||
<!-- <vspace/> --> | ||||
<!-- Note that if a non-OISM egress PE has receivers on BD-R1 -- | ||||
> | ||||
<!-- and BD-R2, neither of which is BD-S, the egress PE will --> | ||||
<!-- receive two copies of the frame, one on the non-OISM BUM -- | ||||
> | ||||
<!-- tunnel for BD-R1, and one on the non-OISM BUM tunnel for -- | ||||
> | ||||
<!-- BD-R2. This is necessary because the non-OISM PEs cannot - | ||||
-> | ||||
<!-- route frames from one BD to another. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- OISM PEs MUST join all the IP multicast tunnels --> | ||||
<!-- advertised by other OISM PEs, including those --> | ||||
<!-- advertised by the IPMG. When an OISM PE joins the IP --> | ||||
<!-- multicast tunnel for a given BD: --> | ||||
<!-- <list style="symbols"> --> | ||||
<!-- <t> --> | ||||
<!-- If the PE is attached to that BD, it associates the - | ||||
-> | ||||
<!-- tunnel with that BD. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- If the PE is not attached to that BD, it associates - | ||||
-> | ||||
<!-- the tunnel with the SBD. --> | ||||
<!-- </t> --> | ||||
<!-- </list> --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Recall that when the IPMG (or any other OISM node) uses a | ||||
n --> | ||||
<!-- S-PMSI A-D route to advertise a tunnel in a particular BD | ||||
, the --> | ||||
<!-- route carries an RT and an Ethernet Tag ID that together | ||||
--> | ||||
<!-- identify the BD. An OISM PE uses the RT and Tag ID to --> | ||||
<!-- determine whether the route is for one of the BDs to --> | ||||
<!-- which the PE is attached. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- When the IPMG receives an IP multicast frame on BD-S from | ||||
--> | ||||
<!-- a non-OISM ingress PE, it relays the frame unchanged on - | ||||
-> | ||||
<!-- its IP multicast tunnel for BD-S. This will carry the -- | ||||
> | ||||
<!-- frame to all OISM PEs that have interest in it. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- When an OISM PE receives an IP multicast frame on the --> | ||||
<!-- IP multicast tunnel from an IPMG, and the OISM PE has --> | ||||
<!-- associated that frame with BD-S, it discards the frame. - | ||||
-> | ||||
<!-- Otherwise, it follows the normal OISM procedures for --> | ||||
<!-- frames received on an SBD tunnel. --> | ||||
<!-- <vspace/> --> | ||||
<!-- <vspace/> --> | ||||
<!-- Note that if the BD-S IP multicast tunnel from the IPMG i | ||||
s --> | ||||
<!-- an MPLS P2MP LSP, and if the PTA describing that tunnel - | ||||
-> | ||||
<!-- has a zero in the MPLS Label field, then an OISM PE --> | ||||
<!-- attached to BD-S SHOULD NOT join the tunnel. --> | ||||
<!-- </t> --> | ||||
<!-- </list> --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- In order for these procedures to work, the IPMG may need to --> | ||||
<!-- advertise two BUM tunnels for each BD in the tenant domain: --> | ||||
<!-- <list style="format %d. "> --> | ||||
<!-- <t> --> | ||||
<!-- Its "ordinary" BUM tunnel for the given BD, advertised --> | ||||
<!-- in an IMET route for that BD. This tunnel will be --> | ||||
<!-- joined by all PEs (OISM and non-OISM) attached to the --> | ||||
<!-- given BD. The IPMG will use this tunnel only for --> | ||||
<!-- transmitting BUM traffic that it receives from those of --> | ||||
<!-- its own ACs attaching to the given BD. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- A "non-OISM relay BUM tunnel" for the given BD. This is -- | ||||
> | ||||
<!-- advertised in a second IMET route for that BD. This --> | ||||
<!-- second IMET route MUST have a different RD and MUST have -- | ||||
> | ||||
<!-- a different "originating router's IP address". It MUST --> | ||||
<!-- carry a flag or an extended community [to be determined] -- | ||||
> | ||||
<!-- meaning "non-OISM-only". --> | ||||
<!-- <vspace/> --> | ||||
<!-- <vspace/> --> | ||||
<!-- Non-OISM nodes will join this tunnel, since it looks to the | ||||
m --> | ||||
<!-- like an ordinary BUM tunnel. OISM nodes will not join it, | ||||
--> | ||||
<!-- since it is marked "non-OISM-only". --> | ||||
<!-- <vspace/> --> | ||||
<!-- <vspace/> --> | ||||
<!-- When the IPMG needs to relay IP multicast traffic from an - | ||||
-> | ||||
<!-- ingress PE (other than the IPMG itself) to a set of non-OIS | ||||
M --> | ||||
<!-- egress PEs, it sends the traffic on the non-OISM BUM --> | ||||
<!-- tunnel. Note that there is a different non-OISM BUM tunnel | ||||
--> | ||||
<!-- for each BD. --> | ||||
<!-- </t> --> | ||||
<!-- </list> --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- If the IPMG does not have any ACs, it need not advertise an --> | ||||
<!-- "ordinary BUM tunnel". --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- The IPMG must also advertise an "OISM-only relay tunnel" in an | ||||
--> | ||||
<!-- S-PMSI A-D route. These tunnels can be advertised in (C-*,C-*) | ||||
--> | ||||
<!-- S-PMSI A-D routes or in more specific S-PMSI A-D routes. The - | ||||
-> | ||||
<!-- routes advertising these tunnels must be marked with a flag or | ||||
--> | ||||
<!-- EC that identifies them as being OISM-only relay tunnels from a | ||||
n --> | ||||
<!-- IPMG. Since these tunnels are advertised in S-PMSI A-D routes, | ||||
--> | ||||
<!-- and non-OISM nodes do not understand S-PMSI A-D routes, the --> | ||||
<!-- non-OISM nodes will not join these tunnels. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- The non-OISM nodes will advertise P2MP tunnels in their IMET -- | ||||
> | ||||
<!-- routes. These are their "BUM tunnels". Suppose the IPMG gets | ||||
--> | ||||
<!-- an (S,G) multicast frame from the BD-S BUM tunnel of a non-OISM | ||||
--> | ||||
<!-- PE-S. --> | ||||
<!-- <list style="symbols"> --> | ||||
<!-- <t> --> | ||||
<!-- If there are any non-OISM PEs with interest in (S,G) on a - | ||||
-> | ||||
<!-- given BD, say BD-R, where BD-R is not the same as BD-S, the | ||||
n --> | ||||
<!-- the IPMG does the IP processing of the (S,G) multicast --> | ||||
<!-- packet, changes the MAC SA of the Ethernet encapsulation to | ||||
--> | ||||
<!-- its own MAC address, and sends the frame on the non-OISM -- | ||||
> | ||||
<!-- relay BUM tunnel for BD-R. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- If there are any OISM PEs with interest in (S,G) on a given | ||||
--> | ||||
<!-- BD, say BD-R, where BD-R is not the same as BD-S, then the | ||||
--> | ||||
<!-- IPMG sends the frame on the OISM-only relay tunnel for BD-R | ||||
--> | ||||
<!-- that it uses for sending (S,G) traffic. The IPMG MUST NOT | ||||
--> | ||||
<!-- do the IP processing and MUST NOT modify the MAC SA of the | ||||
--> | ||||
<!-- frame. --> | ||||
<!-- </t> --> | ||||
<!-- </list> --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- If an IPMG has ACs attaching to a particular BD, it MUST NOT -- | ||||
> | ||||
<!-- transmit those frames on an OISM-only relay tunnel. Instead, - | ||||
-> | ||||
<!-- the IPMG will need to originate a different set of routes to -- | ||||
> | ||||
<!-- advertise the tunnels for carrying packets from its ACs. These | ||||
--> | ||||
<!-- routes have a different RD and a different originating router I | ||||
P --> | ||||
<!-- address than the relay tunnels. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- We have assumed above that non-OISM nodes will not recognize -- | ||||
> | ||||
<!-- S-PMSI A-D routes. If we want to accommodate a future where -- | ||||
> | ||||
<!-- non-OISM nodes do support S-PMSI A-D routes, an EC or flag woul | ||||
d --> | ||||
<!-- have to be used to distinguish the OISM-only IP multicast --> | ||||
<!-- tunnels from the ordinary IP multicast tunnels. --> | ||||
<!-- The non-OISM nodes would be upgraded to understand this flag or | ||||
--> | ||||
<!-- EC when they are upgraded to understand S-PMSI A-D routes. | ||||
--> | ||||
<!-- </t> --> | ||||
<!-- </section> --> | ||||
</section> <!-- no-OISM --> | ||||
<section title="Traffic to/from Outside the EVPN Tenant Domain" | ||||
anchor="external"> | ||||
<t> | ||||
In this section, we discuss scenarios where a multicast source outside a | In this section, we discuss scenarios where a multicast source outside a | |||
given EVPN Tenant Domain sends traffic to receivers inside the domain | given EVPN Tenant Domain sends traffic to receivers inside the domain | |||
(as well as, possibly, to receivers outside the domain). This requires | (as well as, possibly, to receivers outside the domain). This requires | |||
the OISM procedures to interwork with various layer 3 multicast routing | the OISM procedures to interwork with various Layer 3 multicast routing | |||
procedures. | procedures. | |||
</t> | </t> | |||
<t> | <t> | |||
We assume in this section that the Tenant Domain is not being used as an | In this section, we assume that the Tenant Domain is not being used as an | |||
intermediate transit network for multicast traffic; that is, we do not | intermediate transit network for multicast traffic; that is, we do not | |||
consider the case where the Tenant Domain contains multicast routers | consider the case where the Tenant Domain contains multicast routers | |||
that will receive traffic from sources outside the domain and forward | that will receive traffic from sources outside the domain and forward | |||
the traffic to receivers outside the domain. The transit scenario is | the traffic to receivers outside the domain. The transit scenario is | |||
considered in <xref target="pim"/>. | considered in <xref target="pim" format="default"/>. | |||
</t> | ||||
<t> | ||||
We can divide the non-transit scenarios into two classes: | ||||
<list style="format %d. "> | ||||
<t> | ||||
One or more of the EVPN PE routers provide the functionality needed | ||||
to interwork with layer 3 multicast routing procedures. | ||||
</t> | </t> | |||
<t> | <t> | |||
We can divide the non-transit scenarios into two classes: | ||||
</t> | ||||
<ol spacing="normal" type="1"><li> | ||||
<t> | ||||
One or more of the EVPN PE routers provide the functionality needed | ||||
to interwork with Layer 3 multicast routing procedures. | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
A single BD in the Tenant Domain contains external multicast routers | A single BD in the Tenant Domain contains external multicast routers | |||
("tenant multicast routers"), and those tenant multicast routers are | (tenant multicast routers), and those tenant multicast routers are | |||
used to interwork, on behalf of the entire Tenant Domain, with layer | used to interwork, on behalf of the entire Tenant Domain, with Layer | |||
3 multicast routing procedures. | 3 multicast routing procedures. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ol> | |||
<section title="Layer 3 Interworking via EVPN OISM PEs" anchor="evpn-pe-l3-iwo | <section anchor="evpn-pe-l3-iwork" numbered="true" toc="default"> | |||
rk"> | <name>Layer 3 Interworking via EVPN OISM PEs</name> | |||
<section title="General Principles" anchor="gen_prin"> | <section anchor="gen_prin" numbered="true" toc="default"> | |||
<t> | <name>General Principles</name> | |||
<t> | ||||
Sometimes it is necessary to interwork an EVPN Tenant Domain with an | Sometimes it is necessary to interwork an EVPN Tenant Domain with an | |||
external layer 3 multicast domain (the "external domain"), e.g., | external Layer 3 multicast domain (the external domain), e.g., | |||
a PIM or MVPN domain. This is | a PIM or MVPN domain. This is | |||
needed to allow EVPN tenant systems to receive multicast traffic | needed to allow EVPN tenant systems to receive multicast traffic | |||
from sources ("external sources") outside the EVPN Tenant Domain. | from sources (external sources) outside the EVPN Tenant Domain. | |||
It is also needed to allow receivers ("external receivers") outside | It is also needed to allow receivers (external receivers) outside | |||
the EVPN Tenant Domain to receive traffic from sources inside the | the EVPN Tenant Domain to receive traffic from sources inside the | |||
Tenant Domain. | Tenant Domain. | |||
</t> | </t> | |||
<t> | <t> | |||
In order to allow interworking between an EVPN Tenant Domain and an | In order to allow interworking between an EVPN Tenant Domain and an | |||
external domain, one or more OISM PEs must be "L3 Gateways". An L3 | external domain, one or more OISM PEs must be L3 Gateways. An L3 | |||
Gateway participates both in the OISM procedures and in the L3 | Gateway participates both in the OISM procedures and in the L3 | |||
multicast routing procedures of the external domain, as shown in | multicast routing procedures of the external domain, as shown in | |||
the following figure. | the following figure. | |||
<figure> | </t> | |||
<artwork> | <figure> | |||
<name>Interworking via OISM PEs</name> | ||||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
src1 rcvr1 | src1 rcvr1 | |||
| | | | | | |||
R1 RP R2 | R1 RP R2 | |||
PIM/MVPN | PIM/MVPN | |||
domain | Domain | |||
+---+ +---+ | +---+ +---+ | |||
-----|GW1|----------------------|GW2|---- | -----|GW1|----------------------|GW2|---- | |||
+---+ +---+ | +---+ +---+ | |||
| \ \ / / | | | \ \ / / | | |||
| \ \ / / | | | \ \ / / | | |||
BD1 BD2 SBD SBD BD2 BD1 | BD1 BD2 SBD SBD BD2 BD1 | |||
EVPN Domain | EVPN Domain | |||
SBD SBD | SBD SBD | |||
/ \ | / \ | |||
/ \ | / \ | |||
+---+ +---+ | +---+ +---+ | |||
|PE1| |PE2| | |PE1| |PE2| | |||
+---+ +---+ | +---+ +---+ | |||
| \ / | | | \ / | | |||
BD1 BD2 BD2 BD1 | BD1 BD2 BD2 BD1 | |||
| | | | | | | | | | |||
src2 rcvr2 src3 rcvr3 | src2 rcvr2 src3 rcvr3 | |||
</artwork> | ]]></artwork></figure> | |||
</figure> | <t> | |||
</t> | ||||
<t> | ||||
An L3 Gateway that has interest in receiving (S,G) traffic must be | An L3 Gateway that has interest in receiving (S,G) traffic must be | |||
able to determine the best route to S. If an L3 Gateway has | able to determine the best route to S. If an L3 Gateway has | |||
interest in (*,G), it must be able to determine the best route to | interest in (*,G), it must be able to determine the best route to | |||
G's RP. In these interworking scenarios, the L3 Gateway must be | G's RP. In these interworking scenarios, the L3 Gateway must be | |||
running a layer 3 unicast routing protocol. Via this protocol, it | running a Layer 3 unicast routing protocol. Via this protocol, it | |||
imports unicast routes (either IP routes or VPN&nbhy;IP routes) from | imports unicast routes (either IP routes or VPN-IP routes) from | |||
routers other than EVPN PEs. And since there may be multicast | routers other than EVPN PEs. And since there may be multicast | |||
sources inside the EVPN Tenant Domain, the EVPN PEs also need to | sources inside the EVPN Tenant Domain, the EVPN PEs also need to | |||
export, either as IP routes or as VPN&nbhy;IP routes (depending upon | export, either as IP routes or as VPN-IP routes (depending upon | |||
the external domain), unicast routes to those sources. | the external domain), unicast routes to those sources. | |||
</t> | </t> | |||
<t> | <t> | |||
When selecting the best route to a multicast source or RP, an L3 | When selecting the best route to a multicast source or RP, an L3 | |||
Gateway might have a choice between an EVPN route and an | Gateway might have a choice between an EVPN route and an | |||
IP/VPN&nbhy;IP route. When such a choice exists, the L3 Gateway | IP/VPN-IP route. When such a choice exists, the L3 Gateway | |||
SHOULD always prefer the EVPN route. This will ensure that when | <bcp14>SHOULD</bcp14> always prefer the EVPN route. This will ensure th | |||
at when | ||||
traffic originates in the Tenant Domain and has a receiver in the | traffic originates in the Tenant Domain and has a receiver in the | |||
Tenant Domain, the path to that receiver will remain within the EVPN | Tenant Domain, the path to that receiver will remain within the EVPN | |||
Tenant Domain, even if the source is also reachable via a routed | Tenant Domain, even if the source is also reachable via a routed | |||
path. This also provides protection against sub&nbhy;optimal | path. This also provides protection against sub-optimal | |||
routing that might occur if two EVPN PEs export IP/VPN&nbhy;IP | routing that might occur if two EVPN PEs export IP/VPN-IP | |||
routes and each imports the other's IP/VPN-IP routes. | routes and each imports the other's IP/VPN-IP routes. | |||
</t> | </t> | |||
<t> | <t> | |||
<xref target="rpf"/> discusses the way layer 3 multicast states are | <xref target="rpf" format="default"/> discusses the way Layer 3 multicas | |||
constructed by OISM PEs. These layer 3 multicast states have IRB | t states are | |||
interfaces as their IIF and OIF list entries, and are the basis for | constructed by OISM PEs. These Layer 3 multicast states have IRB | |||
interworking OISM with other layer 3 multicast procedures such as | interfaces as their IIF and OIF list entries and are the basis for | |||
MVPN or PIM. From the perspective of the layer 3 multicast | interworking OISM with other Layer 3 multicast procedures such as | |||
MVPN or PIM. From the perspective of the Layer 3 multicast | ||||
procedures running in a given L3 Gateway, an EVPN Tenant Domain is a | procedures running in a given L3 Gateway, an EVPN Tenant Domain is a | |||
set of IRB interfaces. | set of IRB interfaces. | |||
</t> | </t> | |||
<t> | <t> | |||
When interworking an EVPN Tenant Domain with an external domain, the | When interworking an EVPN Tenant Domain with an external domain, the | |||
L3 Gateway's layer 3 multicast states will not only have IRB | L3 Gateway's Layer 3 multicast states will not only have IRB | |||
interfaces as IIF and OIF list entries, but also other "interfaces" | interfaces as IIF and OIF list entries but also other interfaces | |||
that lead outside the Tenant Domain. For example, when interworking | that lead outside the Tenant Domain. For example, when interworking | |||
with MVPN, the multicast states may have MVPN tunnels as well as IRB | with MVPN, the multicast states may have MVPN tunnels as well as IRB | |||
interfaces as IIF or OIF list members. When interworking with PIM, | interfaces as IIF or OIF list members. When interworking with PIM, | |||
the multicast states may have PIM-enabled non&nbhy;IRB interfaces as | the multicast states may have PIM-enabled non-IRB interfaces as | |||
IIF or OIF list members. | IIF or OIF list members. | |||
</t> | </t> | |||
<t> | <t> | |||
As long as a Tenant Domain is not being used as an intermediate | As long as a Tenant Domain is not being used as an intermediate | |||
transit network for IP multicast traffic, it is not necessary to | transit network for IP multicast traffic, it is not necessary to | |||
enable PIM on its IRB interfaces. | enable PIM on its IRB interfaces. | |||
</t> | </t> | |||
<t> | ||||
In general, an L3 Gateway has the following responsibilities: | ||||
<list style="symbols"> | ||||
<t> | <t> | |||
In general, an L3 Gateway has the following responsibilities: | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | ||||
It exports, to the external domain, unicast routes to those | It exports, to the external domain, unicast routes to those | |||
multicast sources in the EVPN Tenant Domain that are locally | multicast sources in the EVPN Tenant Domain that are locally | |||
attached to the L3 Gateway. | attached to the L3 Gateway. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
It imports, from the external domain, unicast routes to | It imports, from the external domain, unicast routes to | |||
multicast sources that are in the external domain. | multicast sources that are in the external domain. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
It executes the procedures necessary to draw externally sourced | It executes the procedures necessary to draw externally sourced | |||
multicast traffic that is of interest to locally attached | multicast traffic that is of interest to locally attached | |||
receivers in the EVPN Tenant Domain. When such traffic is | receivers in the EVPN Tenant Domain. When such traffic is | |||
received, the traffic is sent down the IRB interfaces of the BDs | received, the traffic is sent down the IRB interfaces of the BDs | |||
on which the locally attached receivers reside. | on which the locally attached receivers reside. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | ||||
One of the L3 Gateways in a given Tenant Domain becomes the "DR" for | ||||
the SBD. (See <xref target="dr_selection"/>.) This L3 gateway has | ||||
the following additional responsibilities: | ||||
<list style="symbols"> | ||||
<t> | <t> | |||
One of the L3 Gateways in a given Tenant Domain becomes the DR for | ||||
the SBD (see <xref target="dr_selection" format="default"/>). This L3 G | ||||
ateway has | ||||
the following additional responsibilities: | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | ||||
It exports, to the external domain, unicast routes to multicast | It exports, to the external domain, unicast routes to multicast | |||
sources in the EVPN Tenant Domain that are not locally | sources in the EVPN Tenant Domain that are not locally | |||
attached to any L3 gateway. | attached to any L3 Gateway. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
It imports, from the external domain, unicast routes to multicast | It imports, from the external domain, unicast routes to multicast | |||
sources that are in the external domain. | sources that are in the external domain. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
It executes the procedures necessary to draw externally sourced | It executes the procedures necessary to draw externally sourced | |||
multicast traffic that is of interest to receivers in the EVPN | multicast traffic that is of interest to receivers in the EVPN | |||
Tenant Domain that are not locally attached to an L3 gateway. | Tenant Domain that are not locally attached to an L3 Gateway. | |||
When such traffic is received, the traffic is sent down the SBD | When such traffic is received, the traffic is sent down the SBD | |||
IRB interface. OISM procedures already described in this | IRB interface. OISM procedures already described in this | |||
document will then ensure that the IP multicast traffic gets | document will then ensure that the IP multicast traffic gets | |||
distributed throughout the Tenant Domain to any EVPN PEs that | distributed throughout the Tenant Domain to any EVPN PEs that | |||
have interest in it. Thus to an OISM PE that is not an L3 | have interest in it. Thus, to an OISM PE that is not an L3 | |||
gateway the externally sourced traffic will appear to have been | Gateway, the externally sourced traffic will appear to have been | |||
sourced on the SBD. | sourced on the SBD. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
In order for this to work, some special care is needed when an L3 | In order for this to work, some special care is needed when an L3 | |||
gateway creates or modifies a layer 3 (*,G) multicast state. | Gateway creates or modifies a Layer 3 (*,G) multicast state. | |||
Suppose group G has both external sources (sources outside the EVPN | Suppose group G has both external sources (sources outside the EVPN | |||
Tenant Domain) and internal sources (sources inside the EVPN tenant | Tenant Domain) and internal sources (sources inside the EVPN Tenant | |||
domain). <xref target="rpf"/> states that when there are internal | Domain). <xref target="rpf" format="default"/> states that when there ar | |||
e internal | ||||
sources, the SBD IRB interface must not be added to the OIF list of | sources, the SBD IRB interface must not be added to the OIF list of | |||
the (*,G) state. Traffic from internal sources will already have | the (*,G) state. Traffic from internal sources will already have | |||
been delivered to all the EVPN PEs that have interest in it. | been delivered to all the EVPN PEs that have interest in it. | |||
However, if the OIF list of the (*,G) state does not contain its SBD | However, if the OIF list of the (*,G) state does not contain its SBD | |||
IRB interface, then traffic from external sources will not get | IRB interface, then traffic from external sources will not get | |||
delivered to other EVPN PEs. | delivered to other EVPN PEs. | |||
</t> | </t> | |||
<t> | <t> | |||
One way of handling this is the following. When an L3 gateway | One way of handling this is the following. When an L3 Gateway | |||
receives (S,G) traffic from other than an IRB interface, and the | receives (S,G) traffic that is from an interface other than IRB, and the | |||
traffic corresponds to a layer 3 (*,G) state, the L3 gateway can | traffic corresponds to a Layer 3 (*,G) state, the L3 Gateway can | |||
create (S,G) state. The IIF will be set to the external interface | create (S,G) state. The IIF will be set to the external interface | |||
over which the traffic is expected. The OIF list will contain the | over which the traffic is expected. The OIF list will contain the | |||
SBD IRB interface, as well as the IRB interfaces of any other BDs | SBD IRB interface, as well as the IRB interfaces of any other BDs | |||
attached to the PEG DR that have locally attached receivers with | attached to the PEG DR that have locally attached receivers with | |||
interest in the (S,G) traffic. The (S,G) state will ensure that the | interest in the (S,G) traffic. The (S,G) state will ensure that the | |||
external traffic is sent down the SBD IRB interface. The following | external traffic is sent down the SBD IRB interface. The following | |||
text will assume this procedure; however other implementation | text will assume this procedure; however, other implementation | |||
techniques may also be possible. | techniques may also be possible. | |||
</t> | </t> | |||
<t> | <t> | |||
If a particular BD | If a particular BD is attached to several L3 | |||
<!-- (other than the SBD) --> | Gateways, one of the L3 Gateways becomes the DR for that BD (see | |||
is attached to several L3 | <xref target="dr_selection" format="default"/>). If the interworking sc | |||
Gateways, one of the L3 Gateways becomes the DR for that BD. (See | enario | |||
<xref target="dr_selection"/>.) If the interworking scenario | ||||
requires FHR functionality, it is generally the DR for a particular | requires FHR functionality, it is generally the DR for a particular | |||
BD that is responsible for performing that functionality on behalf | BD that is responsible for performing that functionality on behalf | |||
of the source hosts on that BD. (E.g., if the interworking scenario | of the source hosts on that BD (e.g., if the interworking scenario | |||
requires that PIM Register messages be sent by an FHR, the DR for a | requires that PIM Register messages be sent by an FHR, the DR for a | |||
given BD would send the PIM Register messages for sources on that | given BD would send the PIM Register messages for sources on that | |||
BD.) Note though that the DR for the SBD does not perform FHR | BD). Although, note that the DR for the SBD does not perform FHR | |||
functionality on behalf of external sources. | functionality on behalf of external sources. | |||
</t> | </t> | |||
<t> | <t> | |||
An optional alternative is to have each L3 gateway perform FHR | An optional alternative is to have each L3 Gateway perform FHR | |||
functionality for locally attached sources. Then the DR would only | functionality for locally attached sources. Then, the DR would only | |||
have to perform FHR functionality on behalf of sources that are | have to perform FHR functionality on behalf of sources that are | |||
locally attached to itself AND sources that are not attached to any | locally attached to itself AND sources that are not attached to any | |||
L3 gateway. | L3 Gateway. | |||
</t> | </t> | |||
<t> | <t> | |||
N.B.: If it is possible that more than one BD contains a tenant | Note that if it is possible that more than one BD contains a tenant | |||
multicast router, then a PE receiving an SMET route for that BD MUST | multicast router, then a PE receiving a SMET route for that BD <bcp14>MU | |||
NOT reconstruct IGMP/MLD Join Reports from the SMET route, and MUST NOT | ST | |||
NOT</bcp14> reconstruct IGMP/MLD Join Reports from the SMET route and <b | ||||
cp14>MUST NOT</bcp14> | ||||
transmit any such IGMP/MLD Join Reports on its local ACs attaching to | transmit any such IGMP/MLD Join Reports on its local ACs attaching to | |||
that BD. Otherwise, multicast traffic may be duplicated. | that BD. Otherwise, multicast traffic may be duplicated. | |||
</t> | </t> | |||
</section> <!-- gen_prin --> | </section> | |||
<section anchor="mvpn" numbered="true" toc="default"> | ||||
<section title="Interworking with MVPN" anchor="mvpn"> | <name>Interworking with MVPN</name> | |||
<t> | <t> | |||
In this section, we specify the procedures necessary to allow EVPN PEs | In this section, we specify the procedures necessary to allow EVPN PEs | |||
running OISM procedures to interwork with L3VPN PEs that run BGP-based | running OISM procedures to interwork with L3VPN PEs that run BGP-based | |||
MVPN <xref target="RFC6514"/> procedures. More specifically, the | MVPN <xref target="RFC6514" format="default"/> procedures. More specifica lly, the | |||
procedures herein allow a given EVPN Tenant Domain to become part of | procedures herein allow a given EVPN Tenant Domain to become part of | |||
an L3VPN/MVPN, and support multicast flows where either: | an L3VPN/MVPN and support multicast flows where either of the following oc | |||
<list style="symbols"> | curs: | |||
<t> | </t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | ||||
The source of a given multicast flow is attached to an Ethernet | The source of a given multicast flow is attached to an Ethernet | |||
segment whose BD is part of an EVPN Tenant Domain, and one or | segment whose BD is part of an EVPN Tenant Domain, and one or | |||
more receivers of the flow are attached to the network via | more receivers of the flow are attached to the network via | |||
L3VPN/MVPN. (Other receivers may be attached to the network via | L3VPN/MVPN. (Other receivers may be attached to the network via | |||
EVPN.) | EVPN.) | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The source of a given multicast flow is attached to the network | The source of a given multicast flow is attached to the network | |||
via L3VPN/MVPN, and one or more receivers of the flow are attached | via L3VPN/MVPN, and one or more receivers of the flow are attached | |||
to an Ethernet segment that is part of an EVPN tenant | to an Ethernet segment that is part of an EVPN Tenant | |||
domain. (Other receivers may be attached via L3VPN/MVPN.) | Domain. (Other receivers may be attached via L3VPN/MVPN.) | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
In this interworking model, existing L3VPN/MVPN PEs are unaware that | In this interworking model, existing L3VPN/MVPN PEs are unaware that | |||
certain sources or receivers are part of an EVPN Tenant Domain. The | certain sources or receivers are part of an EVPN Tenant Domain. The | |||
existing L3VPN/MVPN nodes run only their standard procedures and are | existing L3VPN/MVPN nodes run only their standard procedures and are | |||
entirely unaware of EVPN. Interworking is achieved by having some or | entirely unaware of EVPN. Interworking is achieved by having some or | |||
all of the EVPN PEs function as L3 Gateways running L3VPN/MVPN | all of the EVPN PEs function as L3 Gateways running L3VPN/MVPN | |||
procedures, as detailed in the following sub-sections. | procedures, as detailed in the following subsections. | |||
</t> | </t> | |||
<t> | <t> | |||
In this section, we assume that there are no tenant multicast routers | In this section, we assume that there are no tenant multicast routers | |||
on any of the EVPN-attached Ethernet segments. (There may of course | on any of the EVPN-attached Ethernet segments. (Of course, there may | |||
be multicast routers in the L3VPN.) Consideration of the case where | be multicast routers in the L3VPN.) Consideration of the case where | |||
there are tenant multicast routers is deferred till <xref | there are tenant multicast routers is addressed in <xref target="pim" form | |||
target="pim"/>.) | at="default"/>. | |||
</t> | </t> | |||
<!-- <section title="Model of Operation" anchor="iwork_model"> --> | ||||
<t> | <t> | |||
To support MVPN/EVPN interworking, we introduce the notion of an | To support MVPN/EVPN interworking, we introduce the notion of an | |||
MVPN/EVPN Gateway, or MEG. | MVPN/EVPN Gateway (MEG). | |||
</t> | </t> | |||
<t> | <t> | |||
A MEG is an L3 Gateway (see <xref target="gen_prin"/>), hence is both | A MEG is an L3 Gateway (see <xref target="gen_prin" format="default"/>); h | |||
ence, it is both | ||||
an OISM PE and an L3VPN/MVPN PE. For a given EVPN Tenant Domain, it | an OISM PE and an L3VPN/MVPN PE. For a given EVPN Tenant Domain, it | |||
will have an IP&nbhy;VRF. If the Tenant Domain is part of an | will have an IP-VRF. If the Tenant Domain is part of an | |||
L3VPN/MVPN, the IP&nbhy;VRF also serves as an L3VPN VRF <xref | L3VPN/MVPN, the IP-VRF also serves as an L3VPN VRF <xref target="RFC4364" | |||
target="RFC4364"/>. The IRB interfaces of the IP&nbhy;VRF are | format="default"/>. The IRB interfaces of the IP-VRF are | |||
considered to be "VRF interfaces" of the L3VPN VRF. The L3VPN VRF may | considered to be VRF interfaces of the L3VPN VRF. The L3VPN VRF may | |||
also have other local VRF interfaces that are not EVPN IRB interfaces. | also have other local VRF interfaces that are not EVPN IRB interfaces. | |||
</t> | </t> | |||
<t> | <t> | |||
The VRF on the MEG will import VPN&nbhy;IP routes <xref | The VRF on the MEG will import VPN-IP routes <xref target="RFC4364" format | |||
target="RFC4364"/> from other L3VPN Provider Edge (PE) routers. It | ="default"/> from other L3VPN PE routers. It | |||
will also export VPN&nbhy;IP routes to other L3VPN PE routers. In | will also export VPN-IP routes to other L3VPN PE routers. In | |||
order to do so, it must be appropriately configured with the Route | order to do so, it must be appropriately configured with the RTs | |||
Targets used in the L3VPN to control the distribution of the | used in the L3VPN to control the distribution of the | |||
VPN&nbhy;IP routes. These Route Targets will in general be different | VPN-IP routes. In general, these RTs will be different | |||
than the Route Targets used for controlling the distribution of EVPN | than the RTs used for controlling the distribution of EVPN | |||
routes, as there is no need to distribute EVPN routes to L3VPN-only | routes, as there is no need to distribute EVPN routes to L3VPN-only | |||
PEs and no reason to distribute L3VPN/MVPN routes to EVPN-only PEs. | PEs and no reason to distribute L3VPN/MVPN routes to EVPN-only PEs. | |||
</t> | </t> | |||
<t> | <t> | |||
Note that the RDs in the imported VPN&nbhy;IP routes will not | Note that the RDs in the imported VPN-IP routes will not | |||
necessarily conform to the EVPN rules (as specified in <xref | necessarily conform to the EVPN rules (as specified in <xref target="RFC74 | |||
target="RFC7432"/>) for creating RDs. Therefore a MEG MUST NOT expect | 32" format="default"/>) for creating RDs. Therefore, a MEG <bcp14>MUST NOT</bcp | |||
the RDs of the VPN&nbhy;IP routes to be of any particular format other | 14> expect | |||
the RDs of the VPN-IP routes to be of any particular format other | ||||
than what is required by the L3VPN/MVPN specifications. | than what is required by the L3VPN/MVPN specifications. | |||
</t> | </t> | |||
<t> | <t> | |||
The VPN&nbhy;IP routes that a MEG exports to L3VPN are subnet routes | The VPN-IP routes that a MEG exports to L3VPN are subnet routes | |||
and/or host routes for the multicast sources that are part of the EVPN | and/or host routes for the multicast sources that are part of the EVPN | |||
tenant domain. The exact set of routes that need to be exported is | Tenant Domain. The exact set of routes that need to be exported is | |||
discussed in <xref target="e2m"/>. | discussed in <xref target="e2m" format="default"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
Each IMET route originated by a MEG SHOULD carry a Multicast Flags | Each IMET route originated by a MEG <bcp14>SHOULD</bcp14> carry a Multicas | |||
Extended Community with the "MEG" flag set, indicating that the | t Flags | |||
Extended Community with the MEG flag set, indicating that the | ||||
originator of the IMET route is a MEG. However, PE1 will consider PE2 | originator of the IMET route is a MEG. However, PE1 will consider PE2 | |||
to be a MEG if PE1 imports at least one IMET route from PE2 that | to be a MEG if PE1 imports at least one IMET route from PE2 that | |||
carries the Multicast Flags EC with the MEG flag set. | carries the Multicast Flags EC with the MEG flag set. | |||
</t> | </t> | |||
<t> | <t> | |||
All the MEGs of a given Tenant Domain attach to the SBD of that | All the MEGs of a given Tenant Domain attach to the SBD of that | |||
domain, and one of them is selected to be the SBD's Designated Router | domain, and one of them is selected to be the SBD's Designated Router | |||
(the "MEG SBD&nbhy;DR") for the domain. The selection procedure is | (the MEG SBD-DR) for the domain. The selection procedure is | |||
discussed in <xref target="dr_selection"/>. | discussed in <xref target="dr_selection" format="default"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
In this model of operation, MVPN procedures and EVPN procedures are | In this model of operation, MVPN procedures and EVPN procedures are | |||
largely independent. In particular, there is no assumption that MVPN | largely independent. In particular, there is no assumption that MVPN | |||
and EVPN use the same kind of tunnels. Thus no special procedures are | and EVPN use the same kind of tunnels. Thus, no special procedures are | |||
needed to handle the common scenarios where, e.g., EVPN uses VXLAN | needed to handle the common scenarios where, e.g., EVPN uses VXLAN | |||
tunnels but MVPN uses MPLS P2MP tunnels, or where EVPN uses Ingress | tunnels but MVPN uses MPLS P2MP tunnels, or where EVPN uses IR | |||
Replication but MVPN uses MPLS P2MP tunnels. | but MVPN uses MPLS P2MP tunnels. | |||
</t> | </t> | |||
<t> | <t> | |||
Similarly, no special procedures are needed to prevent duplicate data | Similarly, no special procedures are needed to prevent duplicate data | |||
delivery on Ethernet segments that are multi&nbhy;homed. | delivery on Ethernet segments that are multihomed. | |||
</t> | </t> | |||
<t> | <t> | |||
The MEG does have some special procedures (described below) for | The MEG does have some special procedures (described below) for | |||
interworking between EVPN and MVPN; these have to do with selection of | interworking between EVPN and MVPN; these have to do with selection of | |||
the Upstream PE for a given multicast source, with the exporting of | the Upstream PE for a given multicast source, with the exporting of | |||
VPN&nbhy;IP routes, and with the generation of MVPN C&nbhy;multicast | VPN-IP routes and with the generation of MVPN C-multicast | |||
routes triggered by the installation of SMET routes. | routes triggered by the installation of SMET routes. | |||
</t> | </t> | |||
<section title="MVPN Sources with EVPN Receivers" anchor="m2e"> | <section anchor="m2e" numbered="true" toc="default"> | |||
<section title="Identifying MVPN Sources" anchor="mvpn_source"> | <name>MVPN Sources with EVPN Receivers</name> | |||
<t> | <section anchor="mvpn_source" numbered="true" toc="default"> | |||
<name>Identifying MVPN Sources</name> | ||||
<t> | ||||
Consider a multicast source S. It is possible that a MEG will | Consider a multicast source S. It is possible that a MEG will | |||
import both an EVPN unicast route to S and a VPN&nbhy;IP route (or | import both an EVPN unicast route to S and a VPN-IP route (or | |||
an ordinary IP route), where the prefix length of each route is | an ordinary IP route), where the prefix length of each route is | |||
the same. In order to draw (S,G) multicast traffic for any group | the same. In order to draw (S,G) multicast traffic for any group | |||
G, the MEG SHOULD use the EVPN route rather than the VPN&nbhy;IP | G, the MEG <bcp14>SHOULD</bcp14> use the EVPN route rather than the VP | |||
or IP route to determine the "Upstream PE" (see section 5 of <xref | N-IP | |||
target="RFC6513"/>). | or IP route to determine the Upstream PE (see <xref target="RFC6513" f | |||
</t> | ormat="default" sectionFormat="of" section="5"/>). | |||
<t> | </t> | |||
<t> | ||||
Doing so ensures that when an EVPN tenant system desires to | Doing so ensures that when an EVPN tenant system desires to | |||
receive a multicast flow from another EVPN tenant system, the | receive a multicast flow from another EVPN tenant system, the | |||
traffic from the source to that receiver stays within the EVPN | traffic from the source to that receiver stays within the EVPN | |||
domain. This prevents problems that might arise if there is a | domain. This prevents problems that might arise if there is a | |||
unicast route via L3VPN to S, but no multicast routers along the | unicast route via L3VPN to S but no multicast routers along the | |||
routed path. This also prevents problem that might arise as a | routed path. This also prevents problem that might arise as a | |||
result of the fact that the MEGs will import each others' | result of the fact that the MEGs will import each others' | |||
VPN&nbhy;IP routes. | VPN-IP routes. | |||
</t> | </t> | |||
<t> | <t> | |||
In the <xref target="mvpn_join"/>, we describe the procedures to | In <xref target="mvpn_join" format="default"/>, we describe the proced | |||
be used when the selected route to S is a VPN&nbhy;IP route. | ures to | |||
</t> | be used when the selected route to S is a VPN-IP route. | |||
</section> <!-- mvpn_source --> | </t> | |||
</section> | ||||
<section title="Joining a Flow from an MVPN Source" anchor="mvpn_join"> | <section anchor="mvpn_join" numbered="true" toc="default"> | |||
<t> | <name>Joining a Flow from an MVPN Source</name> | |||
Consider a tenant system, R, on a particular BD, BD-R. Suppose R | <t> | |||
Consider a tenant system, say R, on a particular BD, say BD-R. Suppos | ||||
e R | ||||
wants to receive (S,G) multicast traffic, where source S is not | wants to receive (S,G) multicast traffic, where source S is not | |||
attached to any PE in the EVPN Tenant Domain, but is attached to | attached to any PE in the EVPN Tenant Domain but is attached to | |||
an MVPN PE. | an MVPN PE. | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
Suppose R is on a singly homed Ethernet segment of BD&nbhy;R, | <li> | |||
<t> | ||||
Suppose R is on a singly homed Ethernet segment of BD-R | ||||
and that segment is attached to PE1, where PE1 is a MEG. PE1 | and that segment is attached to PE1, where PE1 is a MEG. PE1 | |||
learns via IGMP/MLD listening that R is interested in (S,G). | learns via IGMP/MLD listening that R is interested in (S,G). | |||
PE1 determines from its VRF that there is no route to S within | PE1 determines from its VRF that there is no route to S within | |||
the Tenant Domain (i.e., no EVPN RT-2 route matching on S's IP | the Tenant Domain (i.e., no EVPN RT-2 route matching on S's IP | |||
address), but that there is a route to S via L3VPN (i.e., the | address) but that there is a route to S via L3VPN (i.e., the | |||
VRF contains a subnet or host route to S that was received as | VRF contains a subnet or host route to S that was received as | |||
a VPN&nbhy;IP route). PE1 thus originates (if it hasn't | a VPN-IP route). Thus, PE1 originates (if it hasn't | |||
already) an MVPN C&nbhy;multicast Source Tree Join(S,G) route. | already) an MVPN C-multicast Source Tree Join (S,G) route. | |||
The route is constructed according to normal MVPN procedures. | The route is constructed according to normal MVPN procedures. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
The layer 2 multicast state is constructed as specified in | The Layer 2 multicast state is constructed as specified in | |||
<xref target="l2_state"/>. | <xref target="l2_state" format="default"/>. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
In the layer 3 multicast state, the IIF is the appropriate | In the Layer 3 multicast state, the IIF is the appropriate | |||
MVPN tunnel, and the IRB interface to BD&nbhy;R is added to | MVPN tunnel, and the IRB interface to BD-R is added to | |||
the OIF list. | the OIF list. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
When PE1 receives (S,G) traffic from the appropriate MVPN | When PE1 receives (S,G) traffic from the appropriate MVPN | |||
tunnel, it performs IP processing of the traffic, and then | tunnel, it performs IP processing of the traffic and then | |||
sends the traffic down its IRB interface to BD&nbhy;R. | sends the traffic down its IRB interface to BD-R. | |||
Following normal OISM procedures, the (S,G) traffic will be | Following normal OISM procedures, the (S,G) traffic will be | |||
encapsulated for Ethernet and sent on the AC to which R is | encapsulated for Ethernet and sent on the AC to which R is | |||
attached. | attached. | |||
</t> | </t> | |||
<t> | </li> | |||
Suppose R is on a singly homed Ethernet segment of BD&nbhy;R, | <li> | |||
<t> | ||||
Suppose R is on a singly homed Ethernet segment of BD-R | ||||
and that segment is attached to PE1, where PE1 is an OISM PE | and that segment is attached to PE1, where PE1 is an OISM PE | |||
but is NOT a MEG. PE1 learns via IGMP/MLD listening that R is | but is NOT a MEG. PE1 learns via IGMP/MLD listening that R is | |||
interested in (S,G). PE1 follows normal OISM procedures, | interested in (S,G). PE1 follows normal OISM procedures, | |||
originating an SBD-SMET route for (S,G); this route will be | originating an SBD-SMET route for (S,G); this route will be | |||
received by all the MEGs of the Tenant Domain, including the | received by all the MEGs of the Tenant Domain, including the | |||
MEG SBD&nbhy;DR. The MEG SBD&nbhy;DR can determine from PE1's | MEG SBD-DR. From PE1's IMET routes, the MEG SBD-DR can determine | |||
IMET routes whether PE1 is itself a MEG. If PE1 is not a MEG, | whether or not PE1 is itself a MEG. If PE1 is not a MEG, | |||
the MEG SBD&nbhy;DR will originate (if it hasn't already) an | the MEG SBD-DR will originate (if it hasn't already) an | |||
MVPN C&nbhy;multicast Source Tree Join(S,G) route. This will | MVPN C-multicast Source Tree Join (S,G) route. This will | |||
cause the MEG SBD&nbhy;DR to receive (S,G) traffic on an MVPN | cause the MEG SBD-DR to receive (S,G) traffic on an MVPN | |||
tunnel. | tunnel. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
The layer 2 multicast state is constructed as specified in | The Layer 2 multicast state is constructed as specified in | |||
<xref target="l2_state"/>. | <xref target="l2_state" format="default"/>. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
In the layer 3 multicast state, the IIF is the appropriate | In the Layer 3 multicast state, the IIF is the appropriate | |||
MVPN tunnel, and the IRB interface to the SBD is added to the | MVPN tunnel, and the IRB interface to the SBD is added to the | |||
OIF list. | OIF list. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
When the MEG SBD&nbhy;DR receives (S,G) traffic on an MVPN | When the MEG SBD-DR receives (S,G) traffic on an MVPN | |||
tunnel, it performs IP processing of the traffic, and the | tunnel, it performs IP processing of the traffic and then | |||
sends the traffic down its IRB interface to the SBD. | sends the traffic down its IRB interface to the SBD. | |||
Following normal OISM procedures, the traffic will be | Following normal OISM procedures, the traffic will be | |||
encapsulated for Ethernet and delivered to all PEs in the | encapsulated for Ethernet and delivered to all PEs in the | |||
Tenant Domain that have interest in (S,G), including PE1. | Tenant Domain that have interest in (S,G), including PE1. | |||
</t> | </t> | |||
<t> | </li> | |||
If R is on a multi&nbhy;homed Ethernet segment of BD&nbhy;R, | <li> | |||
<t> | ||||
If R is on a multihomed Ethernet segment of BD-R, | ||||
one of the PEs attached to the segment will be its DF | one of the PEs attached to the segment will be its DF | |||
(following normal EVPN procedures), and the DF will know (via | (following normal EVPN procedures), and the DF will know (via | |||
IGMP/MLD listening or the procedures of <xref | IGMP/MLD listening or the procedures of <xref target="RFC9251" for | |||
target="RFC9251"/>) that a tenant system reachable via one | mat="default"/>) that a tenant system reachable via one | |||
of its local ACs to BD&nbhy;R is interested in (S,G) traffic. | of its local ACs to BD-R is interested in (S,G) traffic. | |||
The DF is responsible for originating an SBD-SMET route for | The DF is responsible for originating an SBD-SMET route for | |||
(S,G), following normal OISM procedures. If the DF is a MEG, | (S,G), following normal OISM procedures. If the DF is a MEG, | |||
it MUST originate the corresponding MVPN C&nbhy;multicast | it <bcp14>MUST</bcp14> originate the corresponding MVPN C-multicas | |||
Source Tree Join(S,G) route; if the DF is not a MEG, the MEG | t | |||
SBD&nbhy;DR SBD MUST originate the C&nbhy;multicast route when | Source Tree Join (S,G) route; if the DF is not a MEG, the MEG | |||
SBD-DR SBD <bcp14>MUST</bcp14> originate the C-multicast route whe | ||||
n | ||||
it receives the SMET route. | it receives the SMET route. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
Optionally, if the non-DF is a MEG, it MAY originate the | Optionally, if the non-DF is a MEG, it <bcp14>MAY</bcp14> originat | |||
corresponding MVPN C&nbhy;multicast Source Tree Join(S,G) | e the | |||
corresponding MVPN C-multicast Source Tree Join (S,G) | ||||
route. This will cause the traffic to flow to both the DF and | route. This will cause the traffic to flow to both the DF and | |||
the non-DF, but only the DF will forward the traffic out an | the non-DF, but only the DF will forward the traffic out an | |||
AC. This allows for quicker recovery if the DF's local AC to | AC. This allows for quicker recovery if the DF's local AC to | |||
R fails. | R fails. | |||
</t> | </t> | |||
<t> | </li> | |||
If R is attached to a non&nbhy;OISM PE, it will receive the | <li> | |||
traffic via an IPMG, as specified in <xref target="no-OISM"/>. | <t> | |||
</t> | If R is attached to a non-OISM PE, it will receive the | |||
</list> | traffic via an IPMG, as specified in <xref target="no-OISM" format | |||
</t> | ="default"/>. | |||
<t> | </t> | |||
</li> | ||||
</ul> | ||||
<t> | ||||
If an EVPN-attached receiver is interested in (*,G) traffic, and | If an EVPN-attached receiver is interested in (*,G) traffic, and | |||
if it is possible for there to be sources of (*,G) traffic that | if it is possible for there to be sources of (*,G) traffic that | |||
are attached only to L3VPN nodes, the MEGs will have to know the | are attached only to L3VPN nodes, the MEGs will have to know the | |||
group-to-RP mappings. That will enable them to originate MVPN | group-to-RP mappings. That will enable them to originate MVPN | |||
C&nbhy;multicast Shared Tree Join(*,G) routes and to send them | C-multicast Shared Tree Join (*,G) routes and to send them | |||
towards the RP. (Since we are assuming in this section that there | toward the RP. (Since we are assuming in this section that there | |||
are no tenant multicast routers attached to the EVPN Tenant | are no tenant multicast routers attached to the EVPN Tenant | |||
Domain, the RP must be attached via L3VPN. Alternatively, the MEG | Domain, the RP must be attached via L3VPN. Alternatively, the MEG | |||
itself could be configured to function as an RP for group G.) | itself could be configured to function as an RP for group G.) | |||
</t> | </t> | |||
<t> | <t> | |||
The layer 2 multicast states are constructed as specified in <xref | The Layer 2 multicast states are constructed as specified in <xref tar | |||
target="l2_state"/>. | get="l2_state" format="default"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
In the layer 3 (*,G) multicast state, the IIF is the appropriate | In the Layer 3 (*,G) multicast state, the IIF is the appropriate | |||
MVPN tunnel. A MEG will add to the (*,G) OIF list its IRB | MVPN tunnel. A MEG will add its IRB | |||
interfaces for any BDs containing locally attached receivers. If | interfaces to the (*,G) OIF list for any BDs containing locally attach | |||
ed receivers. If | ||||
there are receivers attached to other EVPN PEs, then whenever | there are receivers attached to other EVPN PEs, then whenever | |||
(S,G) traffic from an external source matches a (*,G) state, the | (S,G) traffic from an external source matches a (*,G) state, the | |||
MEG will create (S,G) state, with the MVPN tunnel as the IIF, the | MEG will create (S,G) state, with the MVPN tunnel as the IIF, the | |||
OIF list copied from the (*,G) state, and the SBD IRB interface | OIF list copied from the (*,G) state, and the SBD IRB interface | |||
added to the OIF list. (Please see the discussion in <xref | added to the OIF list. (Please see the discussion in <xref target="ge | |||
target="gen_prin"/> regarding the inclusion of the SBD IRB | n_prin" format="default"/> regarding the inclusion of the SBD IRB | |||
interface in a (*,G) state; the SBD IRB interface is used in the | interface in a (*,G) state; the SBD IRB interface is only used in the | |||
OIF list only for traffic from external sources.) | OIF list for traffic from external sources.) | |||
</t> | </t> | |||
<!-- <t> --> | ||||
<!-- Some special care is needed in the creation of the layer 3 (*,G) | ||||
--> | ||||
<!-- multicast state. Suppose group G has both external sources --> | ||||
<!-- (sources outside the EVPN Tenant Domain) and internal sources --> | ||||
<!-- (sources inside the EVPN Tenant Domain). <xref target="rpf"/> --> | ||||
<!-- states that when there are internal sources, the SBD IRB interfac | ||||
e --> | ||||
<!-- must not be added to the oiflist of the (*,G) state. Traffic fro | ||||
m --> | ||||
<!-- internal sources will have been sent down the SBD IRB interface o | ||||
f --> | ||||
<!-- its ingress PE, and thus will already have been delivered to all | ||||
--> | ||||
<!-- the EVPN PEs that have interest in it. However, if the oiflist o | ||||
f --> | ||||
<!-- the PEG DR's (*,G) state does not contain its SBD IRB interface, | ||||
--> | ||||
<!-- then traffic from external sources will not get delivered to othe | ||||
r --> | ||||
<!-- EVPN PEs. Therefore, when a MEG receives (S,G) traffic from an - | ||||
-> | ||||
<!-- MVPN tunnel, and the traffic corresponds to a layer 3 (*,G) state | ||||
, --> | ||||
<!-- the MEG MUST create (S,G) state. The iif will be set to the MVPN | ||||
--> | ||||
<!-- tunnel the (S,G) traffic is expected to arrive on, and the oiflis | ||||
t --> | ||||
<!-- will contain the SBD IRB interface, as well as the IRB interfaces | ||||
--> | ||||
<!-- of any other BDs attached to the PEG DR that have locally attache | ||||
d --> | ||||
<!-- receivers with interest in the (S,G) traffic. --> | ||||
<!-- </t> --> | ||||
<t> | <t> | |||
Normal MVPN procedures will then result in the MEG getting the | Normal MVPN procedures will then result in the MEG getting the | |||
(*,G) traffic from all the multicast sources for G that are | (*,G) traffic from all the multicast sources for G that are | |||
attached via L3VPN. This traffic arrives on MVPN tunnels. When | attached via L3VPN. This traffic arrives on MVPN tunnels. When | |||
the MEG removes the traffic from these tunnels, it does the IP | the MEG removes the traffic from these tunnels, it does the IP | |||
processing. If there are any receivers on a given BD, BD&nbhy;R, | processing. If there are any receivers on a given BD, say BD-R, | |||
that are attached via local EVPN ACs, the MEG sends the traffic | that are attached via local EVPN ACs, the MEG sends the traffic | |||
down its BD&nbhy;R IRB interface. If there are any other EVPN PEs | down its BD-R IRB interface. If there are any other EVPN PEs | |||
that are interested in the (*,G) traffic, the MEG sends the | that are interested in the (*,G) traffic, the MEG sends the | |||
traffic down the SBD IRB interface. Normal OISM procedures then | traffic down the SBD IRB interface. Normal OISM procedures then | |||
distribute the traffic as needed to other EVPN&nbhy;PEs. | distribute the traffic as needed to other EVPN PEs. | |||
</t> | </t> | |||
</section> <!-- mvpn_join --> | </section> | |||
</section> <!-- m2e --> | </section> | |||
<section anchor="e2m" numbered="true" toc="default"> | ||||
<section title="EVPN Sources with MVPN Receivers" anchor="e2m"> | <name>EVPN Sources with MVPN Receivers</name> | |||
<section title="General procedures" anchor="e2m_general"> | <section anchor="e2m_general" numbered="true" toc="default"> | |||
<t> | <name>General Procedures</name> | |||
<t> | ||||
Consider the case where an EVPN tenant system S is sending IP | Consider the case where an EVPN tenant system S is sending IP | |||
multicast traffic to group G, and there is a receiver R for the | multicast traffic to group G and there is a receiver R for the | |||
(S,G) traffic that is attached to the L3VPN, but not attached to | (S,G) traffic that is attached to the L3VPN but not attached to | |||
the EVPN Tenant Domain. (We assume in this document that the | the EVPN Tenant Domain. (In this document, we assume that the | |||
L3VPN/MVPN&nbhy;only nodes will not have any special procedures to | L3VPN-/MVPN-only nodes will not have any special procedures to | |||
deal with the case where a source is inside an EVPN domain.) | deal with the case where a source is inside an EVPN domain.) | |||
</t> | </t> | |||
<t> | <t> | |||
In this case, an L3VPN PE through which R can be reached has to | In this case, an L3VPN PE through which R can be reached has to | |||
send an MVPN C&nbhy;multicast Join(S,G) route to one of the MEGs | send an MVPN C-multicast Join (S,G) route to one of the MEGs | |||
that is attached to the EVPN Tenant Domain. For this to happen, | that is attached to the EVPN Tenant Domain. For this to happen, | |||
the L3VPN PE must have imported a VPN-IP route for S (either a | the L3VPN PE must have imported a VPN-IP route for S (either a | |||
host route or a subnet route) from a MEG. | host route or a subnet route) from a MEG. | |||
</t> | </t> | |||
<t> | <t> | |||
If a MEG determines that there is multicast source transmitting on | If a MEG determines that there is multicast source transmitting on | |||
one of its ACs, the MEG SHOULD originate a VPN&nbhy;IP host route | one of its ACs, the MEG <bcp14>SHOULD</bcp14> originate a VPN-IP host | |||
for that source. This determination SHOULD be made by examining | route | |||
the IP multicast traffic that arrives on the ACs. (It MAY be made | for that source. This determination <bcp14>SHOULD</bcp14> be made by | |||
by provisioning.) A MEG SHOULD NOT export a VPN&nbhy;IP host | examining | |||
the IP multicast traffic that arrives on the ACs. (It <bcp14>MAY</bcp1 | ||||
4> be made | ||||
by provisioning.) A MEG <bcp14>SHOULD NOT</bcp14> export a VPN-IP hos | ||||
t | ||||
route for any IP address that is not known to be a multicast | route for any IP address that is not known to be a multicast | |||
source (unless it has some other reason for exporting such a | source (unless it has some other reason for exporting such a | |||
route). The VPN&nbhy;IP host route for a given multicast source | route). The VPN-IP host route for a given multicast source | |||
MUST be withdrawn if the source goes silent for a configurable | <bcp14>MUST</bcp14> be withdrawn if the source goes silent for a confi | |||
period of time, or if it can be determined that the source is no | gurable | |||
period of time or if it can be determined that the source is no | ||||
longer reachable via a local AC. | longer reachable via a local AC. | |||
</t> | </t> | |||
<t> | <t> | |||
A MEG SHOULD also originate a VPN&nbhy;IP subnet route for each of | A MEG <bcp14>SHOULD</bcp14> also originate a VPN-IP subnet route for e | |||
ach of | ||||
the BDs in the Tenant Domain. | the BDs in the Tenant Domain. | |||
</t> | </t> | |||
<t> | <t> | |||
VPN&nbhy;IP routes exported by a MEG must carry any attributes or | VPN-IP routes exported by a MEG must carry any attributes or | |||
extended communities that are required by L3VPN and MVPN. In | Extended Communities that are required by L3VPN and MVPN. In | |||
particular, a VPN&nbhy;IP route exported by a MEG must carry a VRF | particular, a VPN-IP route exported by a MEG must carry a VRF | |||
Route Import Extended Community corresponding to the IP&nbhy;VRF | Route Import Extended Community corresponding to the IP-VRF | |||
from which it is imported, and a Source AS Extended Community. | from which it is imported and a Source AS Extended Community. | |||
</t> | </t> | |||
<t> | <t> | |||
As a result, if S is attached to a MEG, the L3VPN nodes will | As a result, if S is attached to a MEG, the L3VPN nodes will | |||
direct their MVPN C&nbhy;multicast Join routes to that MEG. | direct their MVPN C-multicast Join routes to that MEG. | |||
Normal MVPN procedures will cause the traffic to be delivered to | Normal MVPN procedures will cause the traffic to be delivered to | |||
the L3VPN nodes. The layer 3 multicast state for (S,G) will have | the L3VPN nodes. The Layer 3 multicast state for (S,G) will have | |||
the MVPN tunnel on its OIF list. The IIF will be the IRB | the MVPN tunnel on its OIF list. The IIF will be the IRB | |||
interface leading to the BD containing S. | interface leading to the BD containing S. | |||
</t> | </t> | |||
<t> | <t> | |||
If S is not attached to a MEG, the L3VPN nodes will direct their | If S is not attached to a MEG, the L3VPN nodes will direct their | |||
C&nbhy;multicast Join routes to whichever MEG appears to be on the | C-multicast Join routes to whichever MEG appears to be on the | |||
best route to S's subnet. Upon receiving the C&nbhy;multicast | best route to S's subnet. Upon receiving the C-multicast | |||
Join, that MEG will originate an EVPN SMET route for (S,G). As a | Join, that MEG will originate an EVPN SMET route for (S,G). As a | |||
result, the MEG will receive the (S,G) traffic at layer 2 via the | result, the MEG will receive the (S,G) traffic at Layer 2 via the | |||
OISM procedures. The (S,G) traffic will be sent up the | OISM procedures. The (S,G) traffic will be sent up the | |||
appropriate IRB interface, and the layer 3 MVPN procedures will | appropriate IRB interface, and the Layer 3 MVPN procedures will | |||
ensure that the traffic is delivered to the L3VPN nodes that have | ensure that the traffic is delivered to the L3VPN nodes that have | |||
requested it. The layer 3 multicast state for (S,G) will have the | requested it. The Layer 3 multicast state for (S,G) will have the | |||
MVPN tunnel in the OIF list, and the IIF will be one of the | MVPN tunnel in the OIF list, and the IIF will be one of the | |||
following: | following: | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
<li> | ||||
<t> | ||||
If S belongs to a BD that is attached to the MEG, the IIF will | If S belongs to a BD that is attached to the MEG, the IIF will | |||
be the IRB interface to that BD; | be the IRB interface to that BD. | |||
</t> | </t> | |||
<t> | </li> | |||
Otherwise the IIF will be the SBD IRB interface. | <li> | |||
</t> | <t> | |||
</list> | Otherwise, the IIF will be the SBD IRB interface. | |||
</t> | </t> | |||
<t> | </li> | |||
Note that this works even if S is attached to a non&nbhy;OISM PE, | </ul> | |||
per the procedures of <xref target="no-OISM"/>. | <t> | |||
</t> | Note that this works even if S is attached to a non-OISM PE, | |||
</section> <!-- e2m_general --> | per the procedures of <xref target="no-OISM" format="default"/>. | |||
<section title="Any-Source Multicast (ASM) Groups" anchor="e2m_asm"> | </t> | |||
<t> | </section> | |||
Suppose the MEG SBD&nbhy;DR learns that one of the PEs in its | <section anchor="e2m_asm" numbered="true" toc="default"> | |||
Tenant Domain is interested in (*,G), traffic, where G is an | <name>Any-Source Multicast (ASM) Groups</name> | |||
Any&nbhy;Source Multicast (ASM) group. If there are no tenant | <t> | |||
multicast routers, the MEG SBD&nbhy;DR SHOULD perform the "First | Suppose the MEG SBD-DR learns that one of the PEs in its | |||
Hop Router" (FHR) functionality for group G on behalf of the | Tenant Domain is interested in (*,G) traffic, where G is an | |||
Tenant Domain, as described in <xref target="RFC7761"/>. This | ASM group. If there are no tenant | |||
means that the MEG SBD&nbhy;DR must know the identity of the | multicast routers, the MEG SBD-DR <bcp14>SHOULD</bcp14> perform the Fi | |||
Rendezvous Point (RP) for each group, must send Register messages | rst | |||
to the Rendezvous Point, etc. | Hop Router (FHR) functionality for group G on behalf of the | |||
</t> | Tenant Domain, as described in <xref target="RFC7761" format="default" | |||
<t> | />. This | |||
If the MEG SBD&nbhy;DR is to be the FHR for the Tenant Domain, it | means that the MEG SBD-DR must know the identity of the | |||
RP for each group, must send Register messages | ||||
to the RP, etc. | ||||
</t> | ||||
<t> | ||||
If the MEG SBD-DR is to be the FHR for the Tenant Domain, it | ||||
must see all the multicast traffic that is sourced from within the | must see all the multicast traffic that is sourced from within the | |||
domain and destined to an ASM group address. The MEG can ensure | domain and destined to an ASM group address. The MEG can ensure | |||
this by originating an SBD&nbhy;SMET route for (*,*). | this by originating an SBD-SMET route for (*,*). | |||
</t> | </t> | |||
<t> | <t> | |||
(As a possible optimization, an SBD&nbhy;SMET route for (*, "any | (As a possible optimization, an SBD-SMET route for (*, any | |||
ASM group") may be defined in a separate document.) | ASM group) may be defined in a separate document.) | |||
</t> | </t> | |||
<t> | <t> | |||
In some deployment scenarios, it may be preferred that the MEG | In some deployment scenarios, it may be preferred that the MEG | |||
that receives the (S,G) traffic over an AC be the one providing the | that receives the (S,G) traffic over an AC be the one providing the | |||
FHR functionality. This behavior is OPTIONAL. If this option is | FHR functionality. This behavior is <bcp14>OPTIONAL</bcp14>. If this | |||
used, it MUST be ensured that the MEG DR does not provide | option is | |||
used, it <bcp14>MUST</bcp14> be ensured that the MEG DR does not provi | ||||
de | ||||
the FHR functionality for (S,G) traffic that is attached to | the FHR functionality for (S,G) traffic that is attached to | |||
another MEG; FHR functionality for (S,G) traffic from a particular | another MEG; FHR functionality for (S,G) traffic from a particular | |||
source S MUST be provided by only a single router. | source S <bcp14>MUST</bcp14> be provided by only a single router. | |||
</t> | </t> | |||
<t> | <t> | |||
Other deployment scenarios are also possible. For example, one | Other deployment scenarios are also possible. For example, one | |||
might want to configure the MEGs themselves to be RPs. In this | might want to configure the MEGs themselves to be RPs. In this | |||
case, the RPs would have to exchange with each other information | case, the RPs would have to exchange with each other information | |||
about which sources are active. The method exchanging such | about which sources are active. The method exchanging such | |||
information is outside the scope of this document. | information is outside the scope of this document. | |||
</t> | </t> | |||
</section> <!-- e2m_asm --> | </section> | |||
<section title="Source on Multihomed Segment" anchor="e2m_multi"> | <section anchor="e2m_multi" numbered="true" toc="default"> | |||
<t> | <name>Source on Multihomed Segment</name> | |||
Suppose S is attached to a segment that is all&nbhy;active | <t> | |||
multi&nbhy;homed to PEl and PE2. If S is transmitting to two | Suppose S is attached to a segment that is all-active | |||
multihomed to PE1 and PE2. If S is transmitting to two | ||||
groups, say G1 and G2, it is possible that PE1 will receive the | groups, say G1 and G2, it is possible that PE1 will receive the | |||
(S,G1) traffic from S while PE2 receives the (S,G2) traffic from | (S,G1) traffic from S, whereas PE2 will receive the (S,G2) traffic fro m | |||
S. | S. | |||
</t> | </t> | |||
<t> | <t> | |||
This creates an issue for MVPN/EVPN interworking, because there is | This creates an issue for MVPN/EVPN interworking, because there is | |||
no way to cause L3VPN/MVPN nodes to select PE1 as the ingress PE | no way to cause L3VPN/MVPN nodes to select PE1 as the ingress PE | |||
for (S,G1) traffic while selecting PE2 as the ingress PE for | for (S,G1) traffic while selecting PE2 as the ingress PE for | |||
(S,G2) traffic. | (S,G2) traffic. | |||
</t> | </t> | |||
<t> | <t> | |||
However, the following procedure ensures that the IP multicast | However, the following procedure ensures that the IP multicast | |||
traffic will still flow, even if the L3VPN/MVPN nodes picks the | traffic will still flow, even if the L3VPN/MVPN nodes pick the | |||
"wrong" EVPN&nbhy;PE as the Upstream PE for (say) the (S,G1) | wrong EVPN PE as the Upstream PE for, e.g., the (S,G1) | |||
traffic. | traffic. | |||
</t> | </t> | |||
<t> | <t> | |||
Suppose S is on an Ethernet segment, belonging to BD1, that is | Suppose S is on an Ethernet segment, belonging to BD1, that is | |||
multi&nbhy;homed to both PE1 and PE2, where PE1 is a MEG. And | multihomed to both PE1 and PE2, where PE1 is a MEG. And | |||
suppose that IP multicast traffic from S to G travels over the AC | suppose that IP multicast traffic from S to G travels over the AC | |||
that attaches the segment to PE2. If PE1 receives a | that attaches the segment to PE2. If PE1 receives a | |||
C&nbhy;multicast Source Tree Join (S,G) route, it MUST originate | C-multicast Source Tree Join (S,G) route, it <bcp14>MUST</bcp14> origi | |||
an SMET route for (S,G). Normal OISM procedures will then cause | nate | |||
a SMET route for (S,G). Normal OISM procedures will then cause | ||||
PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast | PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast | |||
tunnel. Normal OISM procedures will also cause PE1 to send the | tunnel. Normal OISM procedures will also cause PE1 to send the | |||
(S,G) traffic up its BD1 IRB interface. Normal MVPN procedures | (S,G) traffic up its BD1 IRB interface. Normal MVPN procedures | |||
will then cause PE1 to forward the traffic on an MVPN tunnel. In | will then cause PE1 to forward the traffic on an MVPN tunnel. In | |||
this case, the routing is not optimal, but the traffic does flow | this case, the routing is not optimal, but the traffic does flow | |||
correctly. | correctly. | |||
</t> | </t> | |||
</section> <!-- e2m_multi --> | </section> | |||
</section> <!-- e2m --> | </section> | |||
<section anchor="optimal" numbered="true" toc="default"> | ||||
<!-- </section> <!-\- iwork_model -\-> --> | <name>Obtaining Optimal Routing of Traffic between MVPN and EVPN</na | |||
me> | ||||
<section title="Obtaining Optimal Routing of Traffic Between MVPN and EVPN" | <t> | |||
anchor="optimal"> | ||||
<t> | ||||
The routing of IP multicast traffic between MVPN nodes and EVPN | The routing of IP multicast traffic between MVPN nodes and EVPN | |||
nodes will be optimal as long as there is a MEG along the optimal | nodes will be optimal as long as there is a MEG along the optimal | |||
route. There are various deployment strategies that can be used to | route. There are various deployment strategies that can be used to | |||
obtain optimal routing between MVPN and EVPN. | obtain optimal routing between MVPN and EVPN. | |||
</t> | </t> | |||
<t> | <t> | |||
In one such scenario, a Tenant Domain will have a small number of | In one such scenario, a Tenant Domain will have a small number of | |||
strategically placed MEGs. For example, a Data Center may have a | strategically placed MEGs. For example, a data center may have a | |||
small number of MEGs that connect it to a wide-area network. Then | small number of MEGs that connect it to a wide-area network. Then, | |||
the optimal route into or out of the Data Center would be through | the optimal route into or out of the data center would be through | |||
the MEGs. | the MEGs. | |||
</t> | </t> | |||
<t> | <t> | |||
In this scenario, the MEGs do not need to originate VPN&nbhy;IP host | In this scenario, the MEGs do not need to originate VPN-IP host | |||
routes for the multicast sources, they only need to originate | routes for the multicast sources; they only need to originate | |||
VPN&nbhy;IP subnet routes. The internal structure of the EVPN is | VPN-IP subnet routes. The internal structure of the EVPN is | |||
completely hidden from the MVPN node. EVPN actions such as MAC | completely hidden from the MVPN node. EVPN actions, such as MAC | |||
Mobility and Mass Withdrawal <xref target="RFC7432"/> have zero | Mobility and Mass Withdrawal <xref target="RFC7432" format="default"/>, | |||
have zero | ||||
impact on the MVPN control plane. | impact on the MVPN control plane. | |||
</t> | </t> | |||
<t> | <t> | |||
While this deployment scenario provides the most optimal routing and | While this deployment scenario provides the most optimal routing and | |||
has the least impact on the installed based of MVPN nodes, it does | has the least impact on the installed based of MVPN nodes, it does | |||
complicate network planning considerations. | complicate network planning considerations. | |||
</t> | </t> | |||
<t> | <t> | |||
Another way of providing routing that is close to optimal is to turn | Another way of providing routing that is close to optimal is to turn | |||
each EVPN PE into a MEG. Then routing of MVPN-to-EVPN traffic is | each EVPN PE into a MEG. Then, routing of MVPN-to-EVPN traffic is | |||
optimal. However, routing of EVPN-to-MVPN traffic is not guaranteed | optimal. However, routing of EVPN-to-MVPN traffic is not guaranteed | |||
to be optimal when a source host is on a multi&nbhy;homed Ethernet | to be optimal when a source host is on a multihomed Ethernet | |||
segment (as discussed in <xref target="e2m"/>.) | segment (as discussed in <xref target="e2m" format="default"/>.) | |||
</t> | </t> | |||
<t> | <t> | |||
The obvious disadvantage of this method is that it requires every | The obvious disadvantage of this method is that it requires every | |||
EVPN PE to be a MEG. | EVPN PE to be a MEG. | |||
</t> | </t> | |||
<t> | <t> | |||
The procedures specified in this document allow an operator to add | The procedures specified in this document allow an operator to add | |||
MEG functionality to any subset of his EVPN OISM PEs. This allows | MEG functionality to any subset of its EVPN OISM PEs. This allows | |||
an operator to make whatever trade-offs deemed appropriate between | an operator to make whatever trade-offs deemed appropriate between | |||
optimal routing and MEG deployment. | optimal routing and MEG deployment. | |||
</t> | </t> | |||
</section> <!-- optimal --> | </section> | |||
<section anchor="dr_selection" numbered="true" toc="default"> | ||||
<section title="Selecting the MEG SBD-DR" anchor="dr_selection"> | <name>Selecting the MEG SBD-DR</name> | |||
<!-- <t> --> | ||||
<!-- Each MEG for a given Tenant Domain MUST be configured with a "MEG - | ||||
-> | ||||
<!-- Ethernet Segment" for that domain. This is an Ethernet Segment tha | ||||
t --> | ||||
<!-- has no ACs. Conceptually, it represents the set of non-MEG PEs --> | ||||
<!-- contained in the Tenant Domain. In the control plane, this Etherne | ||||
t --> | ||||
<!-- Segment is identified by an ESI of Type 0; thus the ESI is an --> | ||||
<!-- arbitrary 9-octet value, managed and configured by the operator. -- | ||||
> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- EVPN supports a number of procedures that can be used to select the | ||||
--> | ||||
<!-- Designated Forwarder (DF) for a particular BD on a particular --> | ||||
<!-- Ethernet segment. Some of the possible procedures can be found, -- | ||||
> | ||||
<!-- e.g., in <xref target="RFC7432"/>, <xref target="EVPN-DF-NEW"/>, an | ||||
d --> | ||||
<!-- <xref target="I-D.ietf-bess-evpn-pref-df"/>. Whatever procedure is | ||||
in use in --> | ||||
<!-- a given deployment can be adapted to select a MEG DR for a given BD | ||||
, --> | ||||
<!-- as follows. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Each MEG will originate an Ethernet Segment route for the MEG --> | ||||
<!-- Ethernet Segment. It MUST carry an ES-Import Route Target whose -- | ||||
> | ||||
<!-- value is set to the high-order 6-octets of the MEG ESI. Thus only | ||||
--> | ||||
<!-- MEGs will import the route. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- Once the set of MEGs is known, it is also possible to determine the | ||||
--> | ||||
<!-- set of BDs supported by each MEG. The DF selection procedure can - | ||||
-> | ||||
<!-- then be used to choose a MEG DR for the SBD. (The conditions under | ||||
--> | ||||
<!-- which the MEG DR changes depends upon the DF selection algorithm -- | ||||
> | ||||
<!-- that is in use.) --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- These procedures can also be used to select a DR for each BD. If - | ||||
-> | ||||
<!-- the interworking scenario requires FHR functionality, it is --> | ||||
<!-- generally the DR for a particular BD that is responsible for --> | ||||
<!-- performing that functionality on behalf of the source hosts on that | ||||
--> | ||||
<!-- BD. --> | ||||
<!-- </t> --> | ||||
<t> | ||||
Every PE that is eligible for selection as the MEG SBD&nbhy;DR | ||||
originates an SBD&nbhy;IMET route. As stated in <xref | ||||
target="no-OISM"/>, these SBD&nbhy;IMET routes carry a Multicast Flags | ||||
EC with the MEG Flag set. | ||||
</t> | ||||
<t> | ||||
These SBD&nbhy;IMET routes SHOULD also carry a DF Election EC. The DF | ||||
Election EC and its use are specified in <xref | ||||
target="RFC8584"/>. When the route is originated, the | ||||
AC&nbhy;DF bit in the DF Election EC SHOULD be set to zero. This bit | ||||
is not used when selecting a MEG SBD&nbhy;DR, i.e., it MUST be ignored | ||||
by the receiver of an SBD&nbhy;IMET route. | ||||
</t> | ||||
<t> | <t> | |||
Every PE that is eligible for selection as the MEG SBD-DR | ||||
originates an SBD-IMET route. As stated in <xref target="no-OISM" format= | ||||
"default"/>, these SBD-IMET routes carry a Multicast Flags | ||||
EC with the MEG flag set. | ||||
</t> | ||||
<t> | ||||
These SBD-IMET routes <bcp14>SHOULD</bcp14> also carry a DF Election EC. | ||||
The DF | ||||
Election EC and its use are specified in <xref target="RFC8584" format="de | ||||
fault"/>. When the route is originated, the | ||||
AC-DF bit in the DF Election EC <bcp14>SHOULD</bcp14> be set to zero. Thi | ||||
s bit | ||||
is not used when selecting a MEG SBD-DR, i.e., it <bcp14>MUST</bcp14> be i | ||||
gnored | ||||
by the receiver of an SBD-IMET route. | ||||
</t> | ||||
<t> | ||||
In the context of a given Tenant Domain, to select the MEG SBD-DR, the | In the context of a given Tenant Domain, to select the MEG SBD-DR, the | |||
MEGs of the Tenant Domain perform the following procedure: | MEGs of the Tenant Domain perform the following procedure: | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
From the set of received SBD&nbhy;IMET routes for the given tenant | <li> | |||
domain, determine the candidate set of PEs that support MEG | <t> | |||
From the set of received SBD-IMET routes for the given Tenant | ||||
Domain, determine the candidate set of PEs that support MEG | ||||
functionality for that domain. | functionality for that domain. | |||
</t> | </t> | |||
<t> | </li> | |||
Select a DF Election algorithm as specified in <xref | <li> | |||
target="RFC8584"/>. Some of the possible algorithms | <t> | |||
can be found, e.g., in <xref target="RFC7432"/>, <xref | Select a DF election algorithm as specified in <xref target="RFC8584" | |||
target="RFC8584"/>, and <xref | format="default"/>. Some of the possible algorithms | |||
target="I-D.ietf-bess-evpn-pref-df"/>. | can be found, e.g., in <xref target="RFC7432" format="default"/>, <xre | |||
</t> | f target="RFC8584" format="default"/>, and <xref target="I-D.ietf-bess-evpn-pref | |||
<t> | -df" format="default"/>. | |||
Apply the DF Election Algorithm (see <xref | </t> | |||
target="RFC8584"/>) to the candidate set of PEs. | </li> | |||
The "winner" becomes the MEG SBD-DR. | <li> | |||
</t> | <t> | |||
</list> | Apply the DF election algorithm (see <xref target="RFC8584" format="de | |||
</t> | fault"/>) to the candidate set of PEs. | |||
<t> | The winner becomes the MEG SBD-DR. | |||
Note that if a given PE supports IPMG (<xref target="mvpn"/>) or PEG | </t> | |||
(<xref target="pim_iwork"/>) functionality as well as MEG | </li> | |||
functionality, its SBD&nbhy;IMET routes carry only one DF Election EC. | </ul> | |||
</t> | <t> | |||
Note that if a given PE supports IPMG (<xref target="mvpn" format="default | ||||
</section> <!-- dr_selection --> | "/>) or PEG | |||
</section> <!-- mvpn --> | (<xref target="pim_iwork" format="default"/>) functionality as well as MEG | |||
functionality, its SBD-IMET routes carry only one DF Election EC. | ||||
<section title="Interworking with 'Global Table Multicast'" | </t> | |||
anchor="gtm"> | </section> | |||
<t> | </section> | |||
<section anchor="gtm" numbered="true" toc="default"> | ||||
<name>Interworking with Global Table Multicast</name> | ||||
<t> | ||||
If multicast service to the outside sources and/or receivers is | If multicast service to the outside sources and/or receivers is | |||
provided via the BGP-based "Global Table Multicast" (GTM) procedures | provided via the BGP-based Global Table Multicast (GTM) procedures | |||
of <xref target="RFC7716"/>, the procedures of <xref target="mvpn"/> | of <xref target="RFC7716" format="default"/>, the procedures of <xref targ | |||
et="mvpn" format="default"/> | ||||
can easily be adapted for EVPN/GTM interworking. The way to adapt the | can easily be adapted for EVPN/GTM interworking. The way to adapt the | |||
MVPN procedures to GTM is explained in <xref target="RFC7716"/>. | MVPN procedures to GTM is explained in <xref target="RFC7716" format="defa | |||
</t> | ult"/>. | |||
</section> <!-- gtm --> | </t> | |||
</section> | ||||
<section title="Interworking with PIM" anchor="pim_iwork"> | <section anchor="pim_iwork" numbered="true" toc="default"> | |||
<t> | <name>Interworking with PIM</name> | |||
As we have been discussing, there may be receivers in an EVPN tenant | <t> | |||
domain that are interested in multicast flows whose sources are | As discussed, there may be receivers in an EVPN Tenant | |||
Domain that are interested in multicast flows whose sources are | ||||
outside the EVPN Tenant Domain. Or there may be receivers outside an | outside the EVPN Tenant Domain. Or there may be receivers outside an | |||
EVPN Tenant Domain that are interested in multicast flows whose | EVPN Tenant Domain that are interested in multicast flows whose | |||
sources are inside the Tenant Domain. | sources are inside the Tenant Domain. | |||
</t> | </t> | |||
<t> | ||||
<t> | ||||
If the outside sources and/or receivers are part of an MVPN, | If the outside sources and/or receivers are part of an MVPN, | |||
interworking procedures are covered in <xref target="mvpn"/>. | see the procedures for interworking that are covered in <xref target="mvpn | |||
</t> | " format="default"/>. | |||
<t> | </t> | |||
<t> | ||||
There are also cases where an external source or receiver are attached | There are also cases where an external source or receiver are attached | |||
via IP, and the layer 3 multicast routing is done via PIM. In this | via IP and the Layer 3 multicast routing is done via PIM. In this | |||
case, the interworking between the "PIM domain" and the EVPN tenant | case, the interworking between the PIM domain and the EVPN Tenant | |||
domain is done at L3 Gateways that perform "PIM/EVPN Gateway" (PEG) | Domain is done at L3 Gateways that perform PIM/EVPN Gateway (PEG) | |||
functionality. A PEG is very similar to a MEG, except that its layer | functionality. A PEG is very similar to a MEG, except that its Layer | |||
3 multicast routing is done via PIM rather than via BGP. | 3 multicast routing is done via PIM rather than via BGP. | |||
</t> | </t> | |||
<t> | <t> | |||
If external sources or receivers for a given group are attached to a | If external sources or receivers for a given group are attached to a | |||
PEG via a layer 3 interface, that interface should be treated as a VRF | PEG via a Layer 3 interface, that interface should be treated as a VRF | |||
interface attached to the Tenant Domain's L3VPN VRF. The layer 3 | interface attached to the Tenant Domain's L3VPN VRF. The Layer 3 | |||
multicast routing instance for that Tenant Domain will either run PIM | multicast routing instance for that Tenant Domain will either run PIM | |||
on the VRF interface or will listen for IGMP/MLD messages on that | on the VRF interface or listen for IGMP/MLD messages on that | |||
interface. If the external receiver is attached elsewhere on an IP | interface. If the external receiver is attached elsewhere on an IP | |||
network, the PE has to enable PIM on its interfaces to the backbone | network, the PE has to enable PIM on its interfaces to the backbone | |||
network. In both cases, the PE needs to perform PEG functionality, | network. In both cases, the PE needs to perform PEG functionality, | |||
and its IMET routes must carry the Multicast Flags EC with the PEG | and its IMET routes must carry the Multicast Flags EC with the PEG | |||
flag set. | flag set. | |||
</t> | </t> | |||
<t> | <t> | |||
For each BD on which there is a multicast source or receiver, one of | For each BD on which there is a multicast source or receiver, one of | |||
the PEGs will becomes the PEG DR. DR selection can be done using the | the PEGs will become the PEG DR. DR selection can be done using the | |||
same procedures specified in <xref target="dr_selection"/>, except | same procedures specified in <xref target="dr_selection" format="default"/ | |||
with "PEG" substituted for "MEG". | >, except | |||
</t> | with PEG substituted for MEG. | |||
<t> | </t> | |||
<t> | ||||
As long as there are no tenant multicast routers within the EVPN | As long as there are no tenant multicast routers within the EVPN | |||
Tenant Domain, the PEGs do not need to run PIM on their IRB | Tenant Domain, the PEGs do not need to run PIM on their IRB | |||
interfaces. | interfaces. | |||
</t> | ||||
<section title="Source Inside EVPN Domain" anchor="evpn_source"> | ||||
<t> | ||||
If a PEG receives a PIM Join(S,G) from outside the EVPN tenant | ||||
domain, it may find it necessary to create (S,G) state. The PE | ||||
needs to determine whether S is within the Tenant Domain. If S is | ||||
not within the EVPN Tenant Domain, the PE carries out normal layer 3 | ||||
multicast routing procedures. If S is within the EVPN tenant | ||||
domain, the IIF of the (S,G) state is set as follows: | ||||
<list style="symbols"> | ||||
<t> | ||||
if S is on a BD that is attached to the PE, the IIF is the | ||||
PE's IRB interface to that BD; | ||||
</t> | </t> | |||
<t> | <section anchor="evpn_source" numbered="true" toc="default"> | |||
if S is not on a BD that is attached to the PE, the IIF is the | <name>Source Inside EVPN Domain</name> | |||
<t> | ||||
If a PEG receives a PIM Join (S,G) from outside the EVPN Tenant | ||||
Domain, it may find it necessary to create (S,G) state. The PE | ||||
needs to determine whether S is within the Tenant Domain. If S is | ||||
not within the EVPN Tenant Domain, the PE carries out normal Layer 3 | ||||
multicast routing procedures. If S is within the EVPN Tenant | ||||
Domain, the IIF of the (S,G) state is set as follows: | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t> | ||||
If S is on a BD that is attached to the PE, the IIF is the | ||||
PE's IRB interface to that BD. | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
If S is not on a BD that is attached to the PE, the IIF is the | ||||
PE's IRB interface to the SBD. | PE's IRB interface to the SBD. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
<t> | <t> | |||
When the PE creates such an (S,G) state, it MUST originate (if it | When the PE creates such an (S,G) state, it <bcp14>MUST</bcp14> originat | |||
hasn't already) an SBD&nbhy;SMET route for (S,G). This will cause | e (if it | |||
it to pull the (S,G) traffic via layer 2. When the traffic arrives | hasn't already) an SBD-SMET route for (S,G). This will cause | |||
it to pull the (S,G) traffic via Layer 2. When the traffic arrives | ||||
over an EVPN tunnel, it gets sent up an IRB interface where the | over an EVPN tunnel, it gets sent up an IRB interface where the | |||
layer 3 multicast routing determines the packet's disposition. The | Layer 3 multicast routing determines the packet's disposition. The | |||
SBD&nbhy;SMET route is withdrawn when the (S,G) state no longer | SBD-SMET route is withdrawn when the (S,G) state no longer | |||
exists (unless there is some other reason for not withdrawing it). | exists (unless there is some other reason for not withdrawing it). | |||
</t> | </t> | |||
<t> | <t> | |||
If there are no tenant multicast routers within the EVPN tenant | If there are no tenant multicast routers within the EVPN Tenant | |||
domain, there cannot be an RP in the Tenant Domain, so a PEG does | Domain, there cannot be an RP in the Tenant Domain, so a PEG does | |||
not have to handle externally arriving PIM Join(*,G) messages. | not have to handle externally arriving PIM Join (*,G) messages. | |||
</t> | </t> | |||
<!-- <t> --> | ||||
<!-- It is possible that the PEG may later receive PIM Prune(S,G,rpt) -- | ||||
> | ||||
<!-- from the external network. At that time, it MAY advertise | ||||
(C&nbhy;S,C&nbhy;G) --> | ||||
<!-- an SMET route with the Exclude Group type bit and IGMPv3 bit in the | ||||
--> | ||||
<!-- Flags field set (see <xref target="RFC9251"/> for details), --> | ||||
<!-- signaling to other EVPN PEs that the particular | ||||
(C&nbhy;S,C&nbhy;G) traffic is --> | ||||
<!-- not needed. --> | ||||
<!-- </t> --> | ||||
<!-- <t> --> | ||||
<!-- <cref source=" ECR"> --> | ||||
<!-- It seems to me that the above paragraph is not needed, because we | ||||
--> | ||||
<!-- are assuming there is no RP in the Tenant Domain. So we can't ge | ||||
t --> | ||||
<!-- Prune(S,G,rpt). Am I wrong about that? --> | ||||
<!-- </cref> --> | ||||
<!-- </t> --> | ||||
<t> | <t> | |||
The PEG DR for a particular BD MUST act as the a First Hop Router | The PEG DR for a particular BD <bcp14>MUST</bcp14> act as the a First Ho p Router | |||
for that BD. It will examine all (S,G) traffic on the BD, and | for that BD. It will examine all (S,G) traffic on the BD, and | |||
whenever G is an ASM group, the PEG DR will send Register messages | whenever G is an ASM group, the PEG DR will send Register messages | |||
to the RP for G. This means that the PEG DR will need to pull all | to the RP for G. This means that the PEG DR will need to pull all | |||
the (S,G) traffic originating on a given BD, by originating an SMET | the (S,G) traffic originating on a given BD by originating a SMET | |||
(*,*) route for that BD. If a PEG DR is the DR for all the BDs, in | (*,*) route for that BD. If a PEG DR is the DR for all the BDs, it | |||
SHOULD originate just an SBD&nbhy;SMET (*,*) route rather than an | <bcp14>SHOULD</bcp14> originate just an SBD-SMET (*,*) route rather than | |||
a | ||||
SMET (*,*) route for each BD. | SMET (*,*) route for each BD. | |||
</t> | </t> | |||
<t> | <t> | |||
The rules for exporting IP routes to multicast sources are the same | The rules for exporting IP routes to multicast sources are the same | |||
as those specified for MEGs in <xref target="e2m"/>, except that the | as those specified for MEGs in <xref target="e2m" format="default"/>, ex | |||
exported routes will be IP routes rather than VPN&nbhy;IP routes, | cept that the | |||
exported routes will be IP routes rather than VPN-IP routes, | ||||
and it is not necessary to attach the VRF Route Import EC or the | and it is not necessary to attach the VRF Route Import EC or the | |||
Source AS EC. | Source AS EC. | |||
</t> | </t> | |||
<t> | <t> | |||
When a source is on a multi&nbhy;homed segment, the same issue | When a source is on a multihomed segment, the same issue | |||
discussed in <xref target="e2m_multi"/> exists. Suppose S is on an | discussed in <xref target="e2m_multi" format="default"/> exists. Suppos | |||
Ethernet segment, belonging to BD1, that is multi&nbhy;homed to both | e S is on an | |||
Ethernet segment, belonging to BD1, that is multihomed to both | ||||
PE1 and PE2, where PE1 is a PEG. And suppose that IP multicast | PE1 and PE2, where PE1 is a PEG. And suppose that IP multicast | |||
traffic from S to G travels over the AC that attaches the segment to | traffic from S to G travels over the AC that attaches the segment to | |||
PE2. If PE1 receives an external PIM Join (S,G) route, it MUST | PE2. If PE1 receives an external PIM Join (S,G) route, it <bcp14>MUST</ | |||
originate an SMET route for (S,G). Normal OISM procedures will | bcp14> | |||
originate a SMET route for (S,G). Normal OISM procedures will | ||||
cause PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast | cause PE2 to send the (S,G) traffic to PE1 on an EVPN IP multicast | |||
tunnel. Normal OISM procedures will also cause PE1 to send the | tunnel. Normal OISM procedures will also cause PE1 to send the | |||
(S,G) traffic up its BD1 IRB interface. Normal PIM procedures will | (S,G) traffic up its BD1 IRB interface. Normal PIM procedures will | |||
then cause PE1 to forward the traffic along a PIM tree. In this | then cause PE1 to forward the traffic along a PIM tree. In this | |||
case, the routing is not optimal, but the traffic does flow | case, the routing is not optimal, but the traffic does flow | |||
correctly. | correctly. | |||
</t> | </t> | |||
</section> | ||||
</section> <!-- evpn_source --> | <section anchor="external_source" numbered="true" toc="default"> | |||
<name>Source Outside EVPN Domain</name> | ||||
<section title="Source Outside EVPN Domain" anchor="external_source"> | <t> | |||
<t> | ||||
By means of normal OISM procedures, a PEG learns whether there are | By means of normal OISM procedures, a PEG learns whether there are | |||
receivers in the Tenant Domain that are interested in receiving | receivers in the Tenant Domain that are interested in receiving | |||
(*,G) or (S,G) traffic. The PEG must determine whether S (or the RP | (*,G) or (S,G) traffic. The PEG must determine whether or not S (or the RP | |||
for G) is outside the EVPN Tenant Domain. If so, and if there is a | for G) is outside the EVPN Tenant Domain. If so, and if there is a | |||
receiver on BD1 interested in receiving such traffic, the PEG DR for | receiver on BD1 interested in receiving such traffic, the PEG DR for | |||
BD1 is responsible for originating a PIM Join(S,G) or Join(*,G) | BD1 is responsible for originating a PIM Join (S,G) or Join (*,G) | |||
control message. | control message. | |||
</t> | </t> | |||
<t> | <t> | |||
An alternative would be to allow any PEG that is directly attached to | An alternative would be to allow any PEG that is directly attached to | |||
a receiver to originate the PIM Joins. Then the PEG DR would only | a receiver to originate the PIM Joins. Then, the PEG DR would only | |||
have to originate PIM Joins on behalf of receivers that are not | have to originate PIM Joins on behalf of receivers that are not | |||
attached to a PEG. However, if this is done, it is necessary for the | attached to a PEG. However, if this is done, it is necessary for the | |||
PEGs to run PIM on all their IRB interfaces, so that the PIM Assert | PEGs to run PIM on all their IRB interfaces so that the PIM Assert | |||
procedures can be used to prevent duplicate delivery to a given BD. | procedures can be used to prevent duplicate delivery to a given BD. | |||
</t> | </t> | |||
<t> | <t> | |||
The IIF for the layer 3 (S,G) or (*,G) state is determined by normal | The IIF for the Layer 3 (S,G) or (*,G) state is determined by normal | |||
PIM procedures. If a receiver is on BD1, and the PEG DR is attached | PIM procedures. If a receiver is on BD1, and the PEG DR is attached | |||
to BD1, its IRB interface to BD1 is added to the OIF list. This | to BD1, its IRB interface to BD1 is added to the OIF list. This | |||
ensures that any receivers locally attached to the PEG DR will | ensures that any receivers locally attached to the PEG DR will | |||
receive the traffic. If there are receivers attached to other EVPN | receive the traffic. If there are receivers attached to other EVPN | |||
PEs, then whenever (S,G) traffic from an external source matches a | PEs, then whenever (S,G) traffic from an external source matches a | |||
(*,G) state, the PEG will create (S,G) state. The IIF will be set | (*,G) state, the PEG will create (S,G) state. The IIF will be set | |||
to whatever external interface the traffic is expected to arrive on | to whatever external interface the traffic is expected to arrive on | |||
(copied from the (*,G) state), the OIF list is copied from the (*,G) | (copied from the (*,G) state), the OIF list is copied from the (*,G) | |||
state, and the SBD IRB interface is added to the OIF list. | state, and the SBD IRB interface is added to the OIF list. | |||
</t> | </t> | |||
<!-- <t> --> | </section> | |||
<!-- However, there is the following problem. Suppose group G has both | </section> | |||
--> | </section> | |||
<!-- external sources (sources outside the EVPN Tenant Domain) and --> | <section anchor="external_pim_router" numbered="true" toc="default"> | |||
<!-- internal sources (sources inside the EVPN Tenant Domain). <xref --> | <name>Interworking with PIM via an External PIM Router</name> | |||
<!-- target="rpf"/> states that when there are internal sources, the SBD | ||||
--> | ||||
<!-- IRB interface must not be added to the oiflist of the (*,G) state. | ||||
--> | ||||
<!-- Traffic from internal sources will have been sent down the SBD IRB | ||||
--> | ||||
<!-- interface of its ingress PE, and thus will already have been --> | ||||
<!-- delivered to all the EVPN PEs that have interest in it. However, i | ||||
f --> | ||||
<!-- the oiflist of the PEG DR's (*,G) state does not contain its SBD IR | ||||
B --> | ||||
<!-- interface, then traffic from external sources will not get delivere | ||||
d --> | ||||
<!-- to other EVPN PEs. Therefore, when the PEG DR receives (S,G) --> | ||||
<!-- traffic corresponding to a layer 3 (*,G) state, the PEG DR MUST --> | ||||
<!-- create (S,G) state. The iif will be set to whatever external --> | ||||
<!-- interface the (S,G) traffic is expected to arrive on, and the --> | ||||
<!-- oiflist will contain the SBD IRB interface, as well as the IRB --> | ||||
<!-- interfaces of any other BDs attached to the PEG DR that have locall | ||||
y --> | ||||
<!-- attached receivers with interest in the (S,G) traffic. --> | ||||
<!-- </t> --> | ||||
</section> <!-- external source --> | ||||
</section> <!-- pim_iwork --> | ||||
</section> <!-- evpn-pe-l3-iwork --> | ||||
<section title="Interworking with PIM via an External PIM Router" | ||||
anchor="external_pim_router"> | ||||
<!--t> | ||||
<cref source=" ECR"> | ||||
I made some changes to this section (formerly titled "A Variation on | ||||
External Connection"), so I might have introduced some errors. I | ||||
removed the requirement for the "gateway BD" to be the SBD, as that | ||||
doesn't seem to be necessary, and I'm not sure we want to say that the | ||||
SBD can have ACs. I removed the mention of Layer 3 multicast states, | ||||
as I think the Layer 3 states are constructed via normal OISM | ||||
procedures. I removed the mention of AE bundles because that is an | ||||
implementation/deployment issue. Please correct anything I screwed up | ||||
here. | ||||
</cref> | ||||
</t--> | ||||
<t> | <t> | |||
<xref target="evpn-pe-l3-iwork"/> describes how to use an OISM PE router | <xref target="evpn-pe-l3-iwork" format="default"/> describes how to use an O | |||
as the gateway to a non&nbhy;EVPN multicast domain, when the EVPN tenant | ISM PE router | |||
domain is not being used as an intermediate transit network for | as the gateway to a non-EVPN multicast domain when the EVPN Tenant | |||
Domain is not being used as an intermediate transit network for | ||||
multicast. An alternative approach is to have one or more external PIM | multicast. An alternative approach is to have one or more external PIM | |||
routers (perhaps operated by a tenant) on one of the BDs of the tenant | routers (perhaps operated by a tenant) on one of the BDs of the Tenant | |||
domain. We will refer to this BD as the "gateway BD". | Domain. We will refer to this BD as the "gateway BD". | |||
</t> | </t> | |||
<t> | <t> | |||
In this model: | In this model: | |||
<list style="symbols"> | </t> | |||
<t> | <ul spacing="normal"> | |||
<li> | ||||
<t> | ||||
The EVPN Tenant Domain is treated as a stub network attached to the | The EVPN Tenant Domain is treated as a stub network attached to the | |||
external PIM routers. | external PIM routers. | |||
</t> | </t> | |||
<t> | </li> | |||
The external PIM routers follow normal PIM procedures, and provide | <li> | |||
<t> | ||||
The external PIM routers follow normal PIM procedures and provide | ||||
the FHR and LHR functionality for the entire Tenant Domain. | the FHR and LHR functionality for the entire Tenant Domain. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
The OISM PEs do not run PIM. | The OISM PEs do not run PIM. | |||
</t> | </t> | |||
<t> | </li> | |||
There MUST NOT be more than one gateway BD. | <li> | |||
</t> | <t> | |||
<t> | There <bcp14>MUST NOT</bcp14> be more than one gateway BD. | |||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
If an OISM PE not attached to the gateway BD has interest in a given | If an OISM PE not attached to the gateway BD has interest in a given | |||
multicast flow, it conveys that interest, following normal OISM | multicast flow, it conveys that interest, following normal OISM | |||
procedures, by originating an SBD-SMET route for that flow. | procedures, by originating an SBD-SMET route for that flow. | |||
</t> | </t> | |||
<t> | </li> | |||
<li> | ||||
<t> | ||||
If a PE attached to the gateway BD receives an SBD-SMET, it may need | If a PE attached to the gateway BD receives an SBD-SMET, it may need | |||
to generate and transmit a corresponding IGMP/MLD Join on one or | to generate and transmit a corresponding IGMP/MLD Join on one or | |||
more of its ACs. (Procedures for generating an IGMP/MLD Join as a | more of its ACs. (Procedures for generating an IGMP/MLD Join as a | |||
result of receiving an SMET route are given in <xref | result of receiving a SMET route are given in <xref target="RFC9251" for | |||
target="RFC9251"/>.) The PE MUST know which BD is the Gateway BD | mat="default"/>.) The PE <bcp14>MUST</bcp14> know which BD is the gateway BD | |||
and MUST NOT transmit an IGMP/MLD Join to any other BDs. | and <bcp14>MUST NOT</bcp14> transmit an IGMP/MLD Join to any other BDs. | |||
Furthermore, even if a particular AC is part of that BD, the PE | Furthermore, even if a particular AC is part of that BD, the PE | |||
SHOULD NOT transmit an IGMP/MLD Join on that AC unless there is an | <bcp14>SHOULD NOT</bcp14> transmit an IGMP/MLD Join on that AC unless th ere is an | |||
external PIM router attached via that AC. | external PIM router attached via that AC. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
As a result, IGMP/MLD messages will be received by the external PIM rout ers | As a result, IGMP/MLD messages will be received by the external PIM rout ers | |||
on the gateway BD, and those external PIM routers will send PIM Join | on the gateway BD, and those external PIM routers will send PIM Join | |||
messages externally as required. Traffic for the given multicast flow | messages externally as required. Traffic for the given multicast flow | |||
will then be received by one of the external PIM routers, and that | will then be received by one of the external PIM routers, and that | |||
traffic will be forwarded by that router to the gateway BD. | traffic will be forwarded by that router to the gateway BD. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
The normal OISM procedures will then cause the given multicast flow | The normal OISM procedures will then cause the given multicast flow | |||
to be tunneled to any PEs of the EVPN Tenant Domain that have | to be tunneled to any PEs of the EVPN Tenant Domain that have | |||
interest in the flow. PEs attached to the gateway BD will see the | interest in the flow. PEs attached to the gateway BD will see the | |||
flow as originating from the gateway BD and other PEs will see the flow | flow as originating from the gateway BD, and other PEs will see the flow | |||
as originating from the SBD. | as originating from the SBD. | |||
</t> | </t> | |||
<t> | </li> | |||
An OISM PE attached to a gateway BD MUST set its layer 2 multicast | <li> | |||
<t> | ||||
An OISM PE attached to a gateway BD <bcp14>MUST</bcp14> set its Layer 2 | ||||
multicast | ||||
state to indicate that each AC to the gateway BD has interest in all | state to indicate that each AC to the gateway BD has interest in all | |||
multicast flows. It MUST also originate an SMET route for (*,*). | multicast flows. It <bcp14>MUST</bcp14> also originate a SMET route for | |||
The procedures for originating SMET routes are discussed in <xref | (*,*). | |||
target="interest"/>. | The procedures for originating SMET routes are discussed in <xref target | |||
<vspace/> | ="interest" format="default"/>. | |||
<vspace/> | </t> | |||
<t> | ||||
This will cause the OISM PEs attached to the gateway BD to receive | This will cause the OISM PEs attached to the gateway BD to receive | |||
all the IP multicast traffic that is sourced within the EVPN tenant | all the IP multicast traffic that is sourced within the EVPN Tenant | |||
domain, and to transmit that traffic to the gateway BD, where the | Domain and to transmit that traffic to the gateway BD, where the | |||
external PIM routers will receive it. This enables the external PIM | external PIM routers will receive it. This enables the external PIM | |||
routers to perform FHR functions on behalf of the entire Tenant | routers to perform FHR functions on behalf of the entire Tenant | |||
Domain. (Of course, if the gateway BD has a multi&nbhy;homed | Domain. (Of course, if the gateway BD has a multihomed | |||
segment, only the PE that is the DF for that segment will transmit | segment, only the PE that is the DF for that segment will transmit | |||
the multicast traffic to the segment.) | the multicast traffic to the segment.) | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ul> | |||
</section> | ||||
</section> <!-- external_pim_router --> | </section> | |||
</section> <!-- external --> | <section anchor="pim" numbered="true" toc="default"> | |||
<name>Using an EVPN Tenant Domain as an Intermediate (Transit) Network for | ||||
<section title="Using an EVPN Tenant Domain as an Intermediate (Transit) Network | Multicast Traffic</name> | |||
for Multicast traffic" | ||||
anchor="pim"> | ||||
<!--t> | ||||
<cref source=" ECR"> | ||||
Basically this section says "Use PIM, send PIM messages transparently, | ||||
and use SMET routes to be sure you pull the right traffic to the right | ||||
place if the traffic is originating from the Tenant Domain, or if the | ||||
traffic is being sent through the Tenant Domain by a tenant router." | ||||
One might expect there to be a "use the SMET routes to recreate the | ||||
PIM messages", but that isn't present in this rev. (There are a few | ||||
comments where we might consider that.) | ||||
</cref> | ||||
</t--> | ||||
<t> | <t> | |||
In this section, we consider the scenario where one or more BDs of an | In this section, we consider the scenario where one or more BDs of an | |||
EVPN Tenant Domain are being used to carry IP multicast traffic for | EVPN Tenant Domain are being used to carry IP multicast traffic for | |||
which the source and at least one receiver are not part the tenant | which the source and at least one receiver are not part the Tenant | |||
domain. That is, one or more BDs of the Tenant Domain are intermediate | Domain. That is, one or more BDs of the Tenant Domain are intermediate | |||
"links" of a larger multicast tree created by PIM. | links of a larger multicast tree created by PIM. | |||
</t> | ||||
<t> | ||||
We define a "tenant multicast router" as a multicast router, running | ||||
PIM, that is: | ||||
<list style="format %d."> | ||||
<t> | ||||
attached to one or more BDs of the Tenant Domain, but | ||||
</t> | </t> | |||
<t> | <t> | |||
is not an EVPN PE router. | We define a "tenant multicast router" as a multicast router, running | |||
PIM, that: | ||||
</t> | </t> | |||
</list> | <ol spacing="normal" type="1"><li> | |||
</t> | <t> | |||
<t> | is attached to one or more BDs of the Tenant Domain but | |||
In order an EVPN Tenant Domain to be used as a transit network for IP | </t> | |||
</li> | ||||
<li> | ||||
<t> | ||||
is not an EVPN PE router. | ||||
</t> | ||||
</li> | ||||
</ol> | ||||
<t> | ||||
In order for an EVPN Tenant Domain to be used as a transit network for IP | ||||
multicast, one or more of its BDs must have tenant multicast routers, | multicast, one or more of its BDs must have tenant multicast routers, | |||
and an OISM PE that attaching to such a BD MUST be provisioned to enable | and an OISM PE attached to such a BD <bcp14>MUST</bcp14> be provisioned to e | |||
PIM on its IRB interface to that BD. (This is true even if none of the | nable | |||
PIM on its IRB interface to that BD. (This is true even if none of the | ||||
tenant routers is on a segment attached to the PE.) Further, all the | tenant routers is on a segment attached to the PE.) Further, all the | |||
OISM PEs (even ones not attached to a BD with tenant multicast routers) | OISM PEs (even ones not attached to a BD with tenant multicast routers) | |||
MUST be provisioned to enable PIM on their SBD IRB interfaces. | <bcp14>MUST</bcp14> be provisioned to enable PIM on their SBD IRB interfaces | |||
</t> | . | |||
<t> | </t> | |||
If PIM is enabled on a particular BD, the DR Selection procedure of | <t> | |||
<xref target="dr_selection"/> MUST be replaced by the normal PIM DR | If PIM is enabled on a particular BD, the DR selection procedure of | |||
Election procedure of <xref target="RFC7761"/>. Note that this may | <xref target="dr_selection" format="default"/> <bcp14>MUST</bcp14> be replac | |||
result in one of the tenant routers being selected as the DR, rather | ed by the normal PIM DR | |||
Election procedure of <xref target="RFC7761" format="default"/>. Note that | ||||
this may | ||||
result in one of the tenant routers being selected as the DR rather | ||||
than one of the OISM PE routers. In this case, First Hop Router and | than one of the OISM PE routers. In this case, First Hop Router and | |||
Last Hop Router functionality will not be performed by any of the EVPN | Last Hop Router functionality will not be performed by any of the EVPN | |||
PEs. | PEs. | |||
</t> | </t> | |||
<t> | <t> | |||
A PIM control message on a particular BD is considered to be a | A PIM control message on a particular BD is considered to be a | |||
link&nbhy;local multicast message, and as such is sent transparently | link-local multicast message and, as such, is sent transparently | |||
from PE to PE via the BUM tunnel for that BD. This is true whether the | from PE to PE via the BUM tunnel for that BD. This is true whether the | |||
control message was received from an AC, or whether it was received from | control message was received from an AC or from | |||
the local layer 3 routing instance via an IRB interface. | the local Layer 3 routing instance via an IRB interface. | |||
</t> | </t> | |||
<!--t> | ||||
<cref source=" ECR"> | ||||
Do we need to consider "PIM Proxy" optimizations here? | ||||
</cref> | ||||
</t--> | ||||
<t> | <t> | |||
A PIM Join/Prune message contains three fields that are relevant to the | A PIM Join/Prune message contains three fields that are relevant to the | |||
present discussion: | present discussion: | |||
<list style="symbols"> | ||||
<t> | ||||
Upstream Neighbor | ||||
</t> | </t> | |||
<t> | <ul spacing="normal"> | |||
<li> | ||||
<t> | ||||
Upstream Neighbor | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t> | ||||
Group Address (G) | Group Address (G) | |||
</t> | </t> | |||
</li> | ||||
<li> | ||||
<t> | ||||
Source Address (S), omitted in the case of (*,G) Join/Prune messages | ||||
</t> | ||||
</li> | ||||
</ul> | ||||
<t> | <t> | |||
Source Address (S), omitted in the case of (*,G) Join/Prune messages. | We will generally speak of a PIM Join as a Join (S,G) or a Join (*,G) | |||
message and will use the term "Join (X,G)" to mean either "Join (S,G)" or | ||||
"Join (*,G)". In the context of a Join (X,G), we will use the term "X" to | ||||
mean "S" in the case of (S,G) or "G's RP" in the case of (*,G). | ||||
</t> | </t> | |||
</list> | <t> | |||
</t> | Suppose BD1 contains two tenant multicast routers, say C1 and C2. Suppose | |||
<t> | C1 is on a segment attached to PE1 and C2 is on a segment attached to | |||
We will generally speak of a PIM Join as a "Join(S,G)" or a "Join(*,G)" | PE2. When C1 sends a PIM Join (X,G) to BD1, the Upstream Neighbor field | |||
message, and will use the term "Join(X,G)" to mean "either Join(S,G) or | might be set to PE1, PE2, or C2. C1 chooses the Upstream | |||
Join(*,G)". In the context of a Join(X,G), we will use the term "X" to | Neighbor based on its unicast routing. Typically, it will choose | |||
mean "S in the case of (S,G), or G's RP in the case of (*,G)". | the PIM router on BD1 that is closest (according to | |||
</t> | the unicast routing) to X as the | |||
<t> | Upstream Neighbor. Note that this will not necessarily be PE1. | |||
Suppose BD1 contains two tenant multicast routers, C1 and C2. Suppose | ||||
C1 is on a segment attached to PE1, and C2 is on a segment attached to | ||||
PE2. When C1 sends a PIM Join(X,G) to BD1, the Upstream Neighbor field | ||||
might be set to either PE1, PE2, or C2. C1 chooses the Upstream | ||||
Neighbor based on its unicast routing. Typically, it will choose as the | ||||
Upstream Neighbor the PIM router on BD1 that is "closest" (according to | ||||
the unicast routing) to X. Note that this will not necessarily be PE1. | ||||
PE1 may not even be visible to the unicast routing algorithm used by the | PE1 may not even be visible to the unicast routing algorithm used by the | |||
tenant routers. Even if it is, it is unlikely to be the PIM router that | tenant routers. Even if it is, it is unlikely to be the PIM router that | |||
is closest to X. So we need to consider the following two cases: | is closest to X. So we need to consider the following two cases: | |||
<list style="format %d. "> | </t> | |||
<t> | <ol spacing="normal" type="1"><li> | |||
C1 sends a PIM Join(X,G) to BD1, with PE1 as the Upstream Neighbor. | <t> | |||
<vspace/> | C1 sends a PIM Join (X,G) to BD1, with PE1 as the Upstream Neighbor. | |||
<vspace/> | </t> | |||
<t> | ||||
PE1's PIM routing instance will receive the Join arrive on the BD1 IRB | PE1's PIM routing instance will receive the Join arrive on the BD1 IRB | |||
interface. If X is not within the Tenant Domain, PE1 handles the | interface. If X is not within the Tenant Domain, PE1 handles the | |||
Join according to normal PIM procedures. This will generally result | Join according to normal PIM procedures. This will generally result | |||
in PE1 selecting an Upstream Neighbor and sending it a Join(X,G). | in PE1 selecting an Upstream Neighbor and sending it a Join (X,G). | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
If X is within the Tenant Domain, but is attached to some other PE, | If X is within the Tenant Domain but is attached to some other PE, | |||
PE1 sends (if it hasn't already) an SBD&nbhy;SMET route for (X,G). | PE1 sends (if it hasn't already) an SBD-SMET route for (X,G). | |||
The IIF of the layer 3 (X,G) state will be the SBD IRB interface, | The IIF of the Layer 3 (X,G) state will be the SBD IRB interface, | |||
and the OIF list will include the IRB interface to BD1. | and the OIF list will include the IRB interface to BD1. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
The SBD&nbhy;SMET route will pull the (X,G) traffic to PE1, and the | The SBD-SMET route will pull the (X,G) traffic to PE1, and the | |||
(X,G) state will result in the (X,G) traffic being forwarded to C1. | (X,G) state will result in the (X,G) traffic being forwarded to C1. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
If X is within the Tenant Domain, but is attached to PE1 itself, no | If X is within the Tenant Domain but is attached to PE1 itself, no | |||
SBD&nbhy;SMET route is sent. The IIF of the layer 3 (X,G) state | SBD-SMET route is sent. The IIF of the Layer 3 (X,G) state | |||
will be the IRB interface to X's BD, and the OIF list will include | will be the IRB interface to X's BD, and the OIF list will include | |||
the IRB interface to BD1. | the IRB interface to BD1. | |||
</t> | </t> | |||
<t> | </li> | |||
C1 sends a PIM Join(X,G) to BD1, with either PE2 or C2 as the | <li> | |||
<t> | ||||
C1 sends a PIM Join (X,G) to BD1, with either PE2 or C2 as the | ||||
Upstream Neighbor. | Upstream Neighbor. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
PE1's PIM routing instance will receive the Join arrive on the BD1 IRB | PE1's PIM routing instance will receive the Join arrive on the BD1 IRB | |||
interface. If neither X nor Upstream Neighbor is within the tenant | interface. If neither X nor Upstream Neighbor is within the Tenant | |||
domain, PE1 handles the Join according to normal PIM procedures. | Domain, PE1 handles the Join according to normal PIM procedures. | |||
This will NOT result in PE1 sending a Join(X,G). | This will NOT result in PE1 sending a Join (X,G). | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
If either X or Upstream Neighbor is within the Tenant Domain, PE1 | If either X or Upstream Neighbor is within the Tenant Domain, PE1 | |||
sends (if it hasn't already) an SBD&nbhy;SMET route for (X,G). The | sends (if it hasn't already) an SBD-SMET route for (X,G). The | |||
IIF of the layer 3 (X,G) state will be the SBD IRB interface, and | IIF of the Layer 3 (X,G) state will be the SBD IRB interface, and | |||
the OIF list will include the IRB interface to BD1. | the OIF list will include the IRB interface to BD1. | |||
<vspace/> | </t> | |||
<vspace/> | <t> | |||
The SBD&nbhy;SMET route will pull the (X,G) traffic to PE1, and the | The SBD-SMET route will pull the (X,G) traffic to PE1, and the | |||
(X,G) state will result in the (X,G) traffic being forwarded to C1. | (X,G) state will result in the (X,G) traffic being forwarded to C1. | |||
</t> | </t> | |||
</list> | </li> | |||
</t> | </ol> | |||
<!--t> | </section> | |||
<cref source=" ECR"> | <section anchor="IANA" numbered="true" toc="default"> | |||
Above (case 1) is where we might consider using the SMET route to as a | <name>IANA Considerations</name> | |||
proxy for a PIM message. | ||||
</cref> | ||||
</t> | ||||
<t> | ||||
<cref source=" ECR"> | ||||
Here (case 2) if we wanted to use the SMET route to proxy for the PIM | ||||
Join we'd have to block PIM J/P messages from being sent transparently | ||||
from site to site. | ||||
</cref> | ||||
</t--> | ||||
<!-- <t>It is possible that an EVPN broadcast domain is providing --> | ||||
<!-- transit service for a tenant's larger network and there are tenant - | ||||
-> | ||||
<!-- routers attached to the subnet, running routing protocols like PIM. | ||||
--> | ||||
<!-- In that case, traffic routed by an upstream NVE to the subnet via IR | ||||
B --> | ||||
<!-- interface may be expected on a downstream tenant router. However, -- | ||||
> | ||||
<!-- since multicast data traffic sent down the IRB interfaces --> | ||||
<!-- is forwarded to local ACs only and not to other EVPN sites according | ||||
--> | ||||
<!-- to rule XXX --> | ||||
<!-- <!-\- <xref target="blockrule" format="counter"/> in <xref target="s | ||||
olution"/>, additional -\-> --> | ||||
<!-- procedures are needed to handle this situation with tenant routers. | ||||
--> | ||||
<!-- In particular, NVEs connecting to tenant routers or traffic sources | ||||
--> | ||||
<!-- need to run PIM on the IRB interface for the transit subnet and --> | ||||
<!-- the SBD. --> | ||||
<!-- </t> --> | ||||
<!-- <t>Consider the following situation: --> | ||||
<!-- <figure> --> | ||||
<!-- <artwork> --> | ||||
<!-- S1 S2 --> | ||||
<!-- \ N1 / N2 --> | ||||
<!-- CE1a CE2b --> | ||||
<!-- \ vlan1 / vlan1 --> | ||||
<!-- NVE1 -\-\-\-\-\-\-\-\-\-\-\- NVE2 -\-\-\- CE2a -\- receiver | ||||
--> | ||||
<!-- / N3 N4 --> | ||||
<!-- S3 --> | ||||
<!-- </artwork> --> | ||||
<!-- </figure> --> | ||||
<!-- </t> --> | ||||
<!-- <t>CE1a, CE2a/b are three CE routers on vlan1 that is implemented by EV | ||||
PN. --> | ||||
<!-- The CEs and NVE1/2 run PIM protocol and are PIM neighbors on vlan1. | ||||
--> | ||||
<!-- CE2a has a receiver on network N4 for multicast traffic from S1/2/3 | ||||
--> | ||||
<!-- on network N1/2/3 respectively. --> | ||||
<!-- </t> --> | ||||
<!-- <t>CE2a sends PIM joins to CE1a/CE2b/NVE1 on vlan1 for the three source | ||||
s --> | ||||
<!-- respectively and they all route traffic accordingly onto vlan1. --> | ||||
<!-- Traffic from S1/2 will reach CE2a because NVE1/2 receive the L2 traf | ||||
fic --> | ||||
<!-- on their ACs and forward across the core following EVPN procedures. | ||||
--> | ||||
<!-- Traffic from S3 is routed into vlan1 by NVE1 via the IRB interface, | ||||
--> | ||||
<!-- and per rule XXX --> | ||||
<!-- <!-\- <xref target="blockrule" format="counter"/> in <xref target="s | ||||
olution"/> the traffic will not be -\-> --> | ||||
<!-- sent across the core. Thus, according to the procedures specified -- | ||||
> | ||||
<!-- so far, the traffic from S3 will never be received by NVE2 or CE2a. | ||||
--> | ||||
<!-- </t> --> | ||||
<!-- <t>To solve this problem, NVE2 needs to know that CE2a sent a PIM join | ||||
--> | ||||
<!-- to another NVE in vlan1 and needs to pull traffic via the SBD, --> | ||||
<!-- where the traffic via IRB is not blocked on the core side. Because P | ||||
IM --> | ||||
<!-- protocol already requires a router to process join/prune messages th | ||||
at --> | ||||
<!-- it receives on an interface even if it is not the intended RPF neigh | ||||
bor --> | ||||
<!-- (for the purpose of join suppression and prune overriding), NVE2 can | ||||
--> | ||||
<!-- realize that the upstream router in the join message is another NVE | ||||
--> | ||||
<!-- vs. a CE router (this only requires the NVEs to keep track if a neig | ||||
hbor --> | ||||
<!-- is an NVE for the subnet). In that case, it treats that join/prune - | ||||
-> | ||||
<!-- as for itself. Correspondingly, its PIM upstream state machine will | ||||
--> | ||||
<!-- choose one of the NVEs as the RPF neighbor. Between this local NVE a | ||||
nd --> | ||||
<!-- the chosen RPF neighbor there could be multiple subnets including th | ||||
e --> | ||||
<!-- SBD but the SBD IRB interface is explicitly chosen as the RPF --> | ||||
<!-- interface. Corresponding join/prune is sent over the SBD IRB --> | ||||
<!-- interface (optionally the the join/prune could be replaced with --> | ||||
<!-- SMET routes) and the upstream NVE will route traffic through the SBD | ||||
. --> | ||||
<!-- This NVE then route traffic further downstream to CE routers. --> | ||||
<!-- </t> --> | ||||
<!-- <t>Similarly, if an NVE needs to send PIM join/prune messages due to it | ||||
s --> | ||||
<!-- local IGMP/MLD state changes, the RPF interface is always explicitly | ||||
--> | ||||
<!-- set to the SBD IRB. --> | ||||
<!-- </t> --> | ||||
<!-- <t>Note that, if CE2a chooses NVE1 or NVE2 instead of CE1a --> | ||||
<!-- as its RPF neighbor for S1, then both CE1a and NVE2 will send --> | ||||
<!-- traffic to vlan1 (NVE1 receives join from NVE2 on the SBD and sends | ||||
--> | ||||
<!-- join to CE1a on vlan1. NVE1 receives traffic from CE1a on vlan1 --> | ||||
<!-- and route to SBD. NVE2 receives traffic on SBD and route to --> | ||||
<!-- local receivers on vlan1). PIM assert procedure kicks in but only -- | ||||
> | ||||
<!-- on NVE2, as CE1a does not receive traffic from NVE2. To address this | ||||
, --> | ||||
<!-- an NVE must track all the RPF neighbors and not add an IRB interface | ||||
--> | ||||
<!-- to the OIF list if it received a corresponding PIM join on the IRB, | ||||
--> | ||||
<!-- in which a tenant router is listed as the upstream neighbor. --> | ||||
<!-- That tenant router will deliver traffic to the subnet, and the traff | ||||
ic --> | ||||
<!-- will be forwarded through the core as it is not routed down the IRB | ||||
--> | ||||
<!-- but received on an AC. --> | ||||
<!-- </t> --> | ||||
<!-- <t>With PIM-ASM, if the DR on a source subnet is a tenant router, --> | ||||
<!-- it will handle the registering procedures for PIM-ASM. As a result, | ||||
--> | ||||
<!-- the NVE at same site as the tenant router/DR MUST not handle registe | ||||
ring --> | ||||
<!-- procedures as described in <xref target="solution"/>. --> | ||||
<!-- </t> --> | ||||
</section> <!-- Tenant Routers --> | ||||
<!-- </section> <!-\- Advanced Topics -\-> --> | ||||
<section anchor="IANA" title="IANA Considerations"> | ||||
<t> | ||||
IANA is requested to assign new flags in the "Multicast Flags Extended | ||||
Community Flags" registry. These flags are: | ||||
<list style="symbols"> | ||||
<t> | ||||
IPMG | ||||
</t> | ||||
<t> | ||||
MEG | ||||
</t> | ||||
<t> | ||||
PEG | ||||
</t> | ||||
<t> | ||||
OISM SBD | ||||
</t> | ||||
<t> | <t> | |||
OISM-supported | IANA has assigned new flags in the "Multicast Flags Extended | |||
Community" registry under the "Border Gateway Protocol (BGP) Extended Commun | ||||
ities" registry as shown below. | ||||
</t> | </t> | |||
</list> | ||||
</t> | ||||
<!-- <t>This document requests the following IANA assignments: --> | ||||
<!-- <list style="symbols"> --> | ||||
<!-- <t>A "Non-OISM" Sub-Type in --> | ||||
<!-- "EVPN Extended Community Sub-Types" registry for the --> | ||||
<!-- EVPN Non-OISM Extended Community. --> | ||||
<!-- </t> --> | ||||
<!-- <t>An "Optimized Inter-subnet Multicast" bit (OISM) in the --> | ||||
<!-- Multicast Flags extended community defined in --> | ||||
<!-- <xref target="RFC9251"/> --> | ||||
<!-- </t> --> | ||||
<!-- </list> --> | ||||
<!-- </t> --> | ||||
</section> <!-- iana --> | ||||
<section anchor="Security" title="Security Considerations"> | <table align="center"> | |||
<t> | <name>Multicast Flags Extended Community Registry</name> | |||
<thead> | ||||
<tr> | ||||
<th align="left" colspan="1" rowspan="1">Bit</th> | ||||
<th align="left" colspan="1" rowspan="1">Name</th> | ||||
<th align="left" colspan="1" rowspan="1">Reference</th> | ||||
<th align="left" colspan="1" rowspan="1">Change Controller</th> | ||||
</tr> | ||||
</thead> | ||||
<tbody> | ||||
<tr> | ||||
<td align="left" colspan="1" rowspan="1">7</td> | ||||
<td align="left" colspan="1" rowspan="1">OISM SBD</td> | ||||
<td align="left" colspan="1" rowspan="1">RFC 9625</td> | ||||
<td align="left" colspan="1" rowspan="1">IETF</td> | ||||
</tr> | ||||
<tr> | ||||
<td align="left" colspan="1" rowspan="1">9</td> | ||||
<td align="left" colspan="1" rowspan="1">IPMG</td> | ||||
<td align="left" colspan="1" rowspan="1">RFC 9625</td> | ||||
<td align="left" colspan="1" rowspan="1">IETF</td> | ||||
</tr> | ||||
<tr> | ||||
<td align="left" colspan="1" rowspan="1">10</td> | ||||
<td align="left" colspan="1" rowspan="1">MEG</td> | ||||
<td align="left" colspan="1" rowspan="1">RFC 9625</td> | ||||
<td align="left" colspan="1" rowspan="1">IETF</td> | ||||
</tr> | ||||
<tr> | ||||
<td align="left" colspan="1" rowspan="1">11</td> | ||||
<td align="left" colspan="1" rowspan="1">PEG</td> | ||||
<td align="left" colspan="1" rowspan="1">RFC 9625</td> | ||||
<td align="left" colspan="1" rowspan="1">IETF</td> | ||||
</tr> | ||||
<tr> | ||||
<td align="left" colspan="1" rowspan="1">12</td> | ||||
<td align="left" colspan="1" rowspan="1">OISM-supported</td> | ||||
<td align="left" colspan="1" rowspan="1">RFC 9625</td> | ||||
<td align="left" colspan="1" rowspan="1">IETF</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
</section> | ||||
<section anchor="Security" numbered="true" toc="default"> | ||||
<name>Security Considerations</name> | ||||
<t> | ||||
This document uses protocols and procedures defined in the normative | This document uses protocols and procedures defined in the normative | |||
references, and inherits the security considerations of those | references and inherits the security considerations of those | |||
references. | references. | |||
</t> | </t> | |||
<t> | <t> | |||
This document adds flags or Extended Communities (ECs) to a number of | This document adds flags or Extended Communities (ECs) to a number of | |||
BGP routes, in order to signal that particular nodes support the OISM, | BGP routes in order to signal that particular nodes support the OISM, | |||
IPMG, MEG, and/or PEG functionalities that are defined in this document. | IPMG, MEG, and/or PEG functionalities that are defined in this document. | |||
Incorrect addition, removal, or modification of those flags and/or ECs | Incorrect addition, removal, or modification of those flags and/or ECs | |||
will cause the procedures defined herein to malfunction, in which case | will cause the procedures defined herein to malfunction, in which case | |||
loss or diversion of data traffic is possible. Implementations should | loss or diversion of data traffic is possible. Implementations should | |||
provide tools to easily debug configuration mistakes that cause the | provide tools to easily debug configuration mistakes that cause the | |||
signaling of incorrect information. | signaling of incorrect information. | |||
</t> | </t> | |||
<t> | <t> | |||
The interworking with non-OISM networks described in sections 5 and 6, | The interworking with non-OISM networks described in Sections <xref target="no-O | |||
require gateway functions in multiple redundant PEs, among which one of | ISM" format="counter"/> and <xref target="external" format="counter"/> | |||
requires gateway functions in multiple redundant PEs, among which one of | ||||
them is elected as Designated Forwarder for a given BD (or SBD). The | them is elected as Designated Forwarder for a given BD (or SBD). The | |||
election of the MEG or PEG Designated Router, as well as the IPMG | election of the MEG or PEG DR, as well as the IPMG | |||
Designated Forwarder makes use of the RFC8584 Designated Forwarder election | Designated Forwarder, makes use of the Designated Forwarder election | |||
procedures. An attacker with access to one of these Gateways may | procedures <xref target="RFC8584"/>. An attacker with access to one of these Gat | |||
eways may | ||||
influence such election and therefore modify the forwarding of multicast traffic | influence such election and therefore modify the forwarding of multicast traffic | |||
between the OISM network and the external domain. The operator | between the OISM network and the external domain. The operator | |||
should be especially careful with the protection of these gateways by making | should be especially careful with the protection of these gateways by making | |||
sure the management interfaces to access the gateways are only allowed to | sure the management interfaces to access the gateways are only allowed to | |||
authorized operators. | authorized operators. | |||
</t> | </t> | |||
<t> | <t> | |||
The document also introduces the concept of per-Tenant-Domain dissemination | The document also introduces the concept of per-Tenant-Domain dissemination | |||
for the SMET routes, as opposed to per-BD distribution in [RFC9251]. That is, | for the SMET routes, as opposed to per-BD distribution in <xref target="RFC9251" | |||
e.g., an SMET route triggered by the reception of an IGMP/MLD join in BD-1 on PE | />. That is, | |||
1, | a SMET route triggered by the reception of an IGMP/MLD Join in BD-1 on PE1 | |||
needs to be distributed and imported by all PEs of the Tenant Domain, even | needs to be distributed and imported by all PEs of the Tenant Domain, even | |||
to those PEs that are not attached to BD-1. This means that an attacker with | to those PEs that are not attached to BD-1. This means that an attacker with | |||
access to only one BD in a PE of the Tenant Domain, might force the advertisemen t of | access to only one BD in a PE of the Tenant Domain might force the advertisement of | |||
SMET routes and impact the resources of all the PEs of the Tenant Domain, as | SMET routes and impact the resources of all the PEs of the Tenant Domain, as | |||
opposed to only the PEs of that particular BD (as in RFC9251). The | opposed to only the PEs of that particular BD (as in <xref target="RFC9251"/>). The | |||
implementation should provide ways to filter/control the client IGMP/MLD | implementation should provide ways to filter/control the client IGMP/MLD | |||
reports that are received by the attached hosts. | reports that are received by the attached hosts. | |||
</t> | </t> | |||
</section> <!-- security --> | </section> | |||
<section anchor="Acknowledgements" title="Acknowledgements"> | ||||
<t> | ||||
The authors thank Vikram Nagarajan and Princy Elizabeth for their work | ||||
on <xref target="external_pim_router"/> and <xref target="SBD-matching"/>. | ||||
The authors also benefited | ||||
tremendously from discussions with Aldrin Isaac on EVPN multicast | ||||
optimizations. | ||||
</t> | ||||
</section> <!-- acks --> | ||||
</middle> | </middle> | |||
<back> | ||||
<displayreference target="I-D.ietf-bier-evpn" to="EVPN-BUM"/> | ||||
<displayreference target="I-D.ietf-bess-evpn-pref-df" to="EVPN-DF"/> | ||||
<references> | ||||
<name>References</name> | ||||
<references> | ||||
<name>Normative References</name> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 | ||||
119.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.33 | ||||
76.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.38 | ||||
10.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.30 | ||||
32.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.43 | ||||
60.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.66 | ||||
25.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.71 | ||||
53.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.74 | ||||
32.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81 | ||||
74.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.85 | ||||
84.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
135.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
136.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
251.xml"/> | ||||
<back> | <!-- [I-D.ietf-bess-evpn-bum-procedure-updates] Published as RFC 9572 on 05/24/2 | |||
<references title="Normative References"> | 4 --> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
572.xml"/> | ||||
&RFC2119; <!-- normative keywords --> | <!-- [I-D.ietf-bess-evpn-optimized-ir] Published as RFC 9574 on 05/24/24 --> | |||
&RFC3376; <!-- IGMP --> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | |||
&RFC3810; <!-- MLDv2 --> | 574.xml"/> | |||
&RFC3032; <!-- MPLS Encaps --> | ||||
&RFC4360; <!-- BGP ECs --> | ||||
&RFC6625; <!-- MVPN Wildcards --> | ||||
&RFC7153; <!-- BGP ECs --> | ||||
&RFC7432; <!-- EVPN --> | ||||
&RFC8174; <!-- normative keywords capitalized --> | ||||
&RFC8584; | ||||
&RFC9135; | ||||
&RFC9136; | ||||
&RFC9251; | ||||
<?rfc include='reference.I-D.ietf-bess-evpn-bum-procedure-updates'?> | ||||
<?rfc include='reference.I-D.ietf-bess-evpn-optimized-ir'?> | ||||
</references> | ||||
<references title="Informative References"> | </references> | |||
<references> | ||||
<name>Informative References</name> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.43 | ||||
64.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.65 | ||||
13.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.65 | ||||
14.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.45 | ||||
41.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.76 | ||||
06.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77 | ||||
16.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77 | ||||
61.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82 | ||||
96.xml"/> | ||||
&RFC4364; <!-- L3VPN --> | <!-- [I-D.ietf-bier-evpn] AUTH48 state as of 08/09/24 (RFC-to-be 9624) | |||
<!-- &RFC5015; --> <!-- BIDIR-PIM --> | Long way used to update title and fix initials --> | |||
&RFC6513; <!-- MVPN --> | <reference anchor="I-D.ietf-bier-evpn" target="https://datatracker.ietf. | |||
&RFC6514; <!-- MVPN --> | org/doc/html/draft-ietf-bier-evpn-14"> | |||
&RFC4541; <!-- snooping --> | <front> | |||
&RFC7606; <!-- BGP Error Handling --> | <title>EVPN Broadcast, Unknown Unicast, and Multicast (BUM) Using Bit | |||
&RFC7716; <!-- GTM --> | Index Explicit Replication (BIER)</title> | |||
&RFC7761; <!-- PIM-SM --> | <author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zha | |||
&RFC8296; <!-- BIER encapsulation --> | ng"> | |||
<organization>Juniper Networks</organization> | ||||
</author> | ||||
<author initials="T." surname="Przygienda" fullname="Tony Przygienda" | ||||
> | ||||
<organization>Juniper Networks</organization> | ||||
</author> | ||||
<author initials="A." surname="Sajassi" fullname="Ali Sajassi"> | ||||
<organization>Cisco Systems</organization> | ||||
</author> | ||||
<author initials="J." surname="Rabadan" fullname="Jorge Rabadan"> | ||||
<organization>Nokia</organization> | ||||
</author> | ||||
<date month="August" year="2024"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-bier-evpn-14"/> | ||||
</reference> | ||||
<?rfc include='reference.I-D.ietf-bier-evpn'?> | <!-- [I-D.ietf-bess-evpn-pref-df] In MISSREF*R as of 08/09/24--> | |||
<?rfc include='reference.I-D.ietf-bess-evpn-pref-df'?> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bes | |||
</references> | s-evpn-pref-df.xml"/> | |||
<section title="Integrated Routing and Bridging" anchor="irb"> | </references> | |||
</references> | ||||
<section anchor="irb" numbered="true" toc="default"> | ||||
<name>Integrated Routing and Bridging</name> | ||||
<t> | <t> | |||
This Appendix provides a short tutorial on the interaction of | This appendix provides a short tutorial on the interaction of | |||
routing and bridging. First it shows the traditional model, where | routing and bridging. First, it shows a model, where | |||
bridging and routing are performed in separate devices. Then it shows | bridging and routing are performed in separate devices. Then, it shows | |||
the model specified in <xref target="RFC9135"/>, where a single device | the model specified in <xref target="RFC9135" format="default"/>, where | |||
a single device | ||||
contains both routing and bridging functions. The latter model is | contains both routing and bridging functions. The latter model is | |||
presupposed in the body of this document. | presupposed in the body of this document. | |||
</t> | </t> | |||
<t> | <t> | |||
<xref target="conventional_router"/> shows a "traditional" router | <xref target="conventional_router" format="default"/> shows the model wh | |||
that only does routing and has no L2 bridging capabilities. There | ere a router | |||
are two LANs, LAN1 and LAN2. LAN1 is realized by switch1, LAN2 by | only does routing and has no L2 bridging capabilities. There | |||
switch2. The router has an interface, "lan1" that attaches to LAN1 | are two LANs: LAN1 and LAN2. LAN1 is realized by switch1, and LAN2 is r | |||
(via switch1) and an interface "lan2" that attachs to LAN2 (via | ealized by | |||
switch2). Each intreface is configured, as an IP interface, with an | switch2. The router has an interface, lan1, that attaches to LAN1 | |||
(via switch1) and an interface, lan2, that attaches to LAN2 (via | ||||
switch2). Each interface is configured, as an IP interface, with an | ||||
IP address and a subnet mask. | IP address and a subnet mask. | |||
<figure align="center" anchor="conventional_router" title="Conventional | </t> | |||
Router with LAN Interfaces"> | <figure anchor="conventional_router"> | |||
<artwork align="center"><![CDATA[ | <name>Conventional Router with LAN Interfaces</name> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
+-------+ +--------+ +-------+ | +-------+ +--------+ +-------+ | |||
| | lan1| |lan2 | | | | | lan1| |lan2 | | | |||
H1 -----+Switch1+--------+ Router1+--------+Switch2+------H3 | H1 -----+Switch1+--------+ Router1+--------+Switch2+------H3 | |||
| | | | | | | | | | | | | | |||
H2 -----| | | | | | | H2 -----| | | | | | | |||
+-------+ +--------+ +-------+ | +-------+ +--------+ +-------+ | |||
|_________________| |__________________| | |_________________| |__________________| | |||
LAN1 LAN2 | LAN1 LAN2 | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</t> | ||||
<t> | <t> | |||
IP traffic (unicast or multicast) that remains within a single | IP traffic (unicast or multicast) that remains within a single | |||
subnet never reaches the router. For instance, if H1 emits an | subnet never reaches the router. For instance, if H1 emits an | |||
Ethernet frame with H2's MAC address in the Ethernet destination | Ethernet frame with H2's MAC address in the Ethernet Destination | |||
address field, the frame will go from H1 to Switch1 to H2, without | Address field, the frame will go from H1 to Switch1 to H2 without | |||
ever reaching the router. Since the frame is never seen by a | ever reaching the router. Since the frame is never seen by a | |||
router, the IP datagram within the frame remains entirely unchanged, | router, the IP datagram within the frame remains entirely unchanged, | |||
e.g., its TTL is not decremented. The Ethernet Source and | e.g., its TTL is not decremented. The Ethernet Source and | |||
Destination MAC addresses are not changed either. | Destination MAC addresses are not changed either. | |||
</t> | </t> | |||
<t> | <t> | |||
If H1 wants to send a unicast IP datagram to H3, which is on a | If H1 wants to send a unicast IP datagram to H3, which is on a | |||
different subnet, H1 has to be configured with the IP address of a | different subnet, H1 has to be configured with the IP address of a | |||
"default router". Let's assume that H1 is configured with an IP | default router. Let's assume that H1 is configured with an IP | |||
address of Router1 as its default router address. H1 compares H3's | address of Router1 as its default router address. H1 compares H3's | |||
IP address with its own IP address and IP subnet mask, and | IP address with its own IP address and IP subnet mask and | |||
determines that H3 is on a different subnet. So the packet has to | determines that H3 is on a different subnet. So the packet has to | |||
be routed. H1 uses ARP to map Router1's IP address to a MAC address | be routed. H1 uses ARP to map Router1's IP address to a MAC address | |||
on LAN1. H1 then encapsulates the datagram in an Ethernet frame, | on LAN1. H1 then encapsulates the datagram in an Ethernet frame, | |||
using router1's MAC address as the destination MAC address, and | using Router1's MAC address as the destination MAC address, and | |||
sends the frame to Router1. | sends the frame to Router1. | |||
</t> | </t> | |||
<t> | <t> | |||
Router1 then receives the frame over its lan1 interface. Router1 | Router1 then receives the frame over its lan1 interface. Router1 | |||
sees that the frame is addressed to it, so it removes the Ethernet | sees that the frame is addressed to it, so it removes the Ethernet | |||
encapsulation and processes the IP datagram. The datagram is not | encapsulation and processes the IP datagram. The datagram is not | |||
addressed to Router1, so it must be forwarded further. Router1 does | addressed to Router1, so it must be forwarded further. Router1 does | |||
a lookup of the datagram's IP destination field, and determines that | a lookup of the datagram's IP Destination Address field and determines t | |||
hat | ||||
the destination (H3) can be reached via Router1's lan2 interface. | the destination (H3) can be reached via Router1's lan2 interface. | |||
Router1 now performs the IP processing of the datagram: it | Router1 now performs the IP processing of the datagram: it | |||
decrements the IP TTL, adjusts the IP header checksum (if present), | decrements the IP TTL, adjusts the IP header checksum (if present), | |||
may fragment the packet is necessary, etc. Then the datagram (or | may fragment the packet as necessary, etc. Then, the datagram (or | |||
its fragments) are encapsulated in an Ethernet header, with | its fragments) is encapsulated in an Ethernet header, with | |||
Router1's MAC address on LAN2 as the MAC Source Address, and H3's | Router1's MAC address on LAN2 as the MAC Source Address and H3's | |||
MAC address on LAN2 (which Router1 determines via ARP) as the MAC | MAC address on LAN2 (which Router1 determines via ARP) as the | |||
Destination Address. Finally the packet is sent on the lan2 | Destination MAC Address. Finally, the packet is sent on the lan2 | |||
interface. | interface. | |||
</t> | </t> | |||
<t> | <t> | |||
If H1 has an IP multicast datagram to send (i.e., an IP datagram | If H1 has an IP multicast datagram to send (i.e., an IP datagram | |||
whose Destination Address field is an IP Multicast Address), it | whose Destination Address field is an IP Multicast Address), it | |||
encapsulates it in an Ethernet frame whose MAC Destination Address | encapsulates it in an Ethernet frame whose Destination MAC Address | |||
is computed from the IP Destination Address. | is computed from the IP Destination Address. | |||
</t> | </t> | |||
<t> | <t> | |||
If H2 is a receiver for that multicast address, H2 will receive a | If H2 is a receiver for that multicast address, H2 will receive a | |||
copy of the frame, unchanged, from H1. The MAC Source Address in | copy of the frame, unchanged, from H1. The MAC Source Address in | |||
the Ethernet encapsulation does not change, the IP TTL field does | the Ethernet encapsulation does not change, the IP TTL field does | |||
not get decremented, etc. | not get decremented, etc. | |||
</t> | </t> | |||
<t> | <t> | |||
If H3 is a receiver for that multicast address, the datagram must be | If H3 is a receiver for that multicast address, the datagram must be | |||
routed to H3. In order for this to happen, Router1 must be | routed to H3. In order for this to happen, Router1 must be | |||
configured as a multicast router, and it must accept traffic sent to | configured as a multicast router, and it must accept traffic sent to | |||
Ethernet multicast addresses. Router1 will receive H1's multicast | Ethernet multicast addresses. Router1 will receive H1's multicast | |||
frame on its lan1 interface, will remove the Ethernet encapsulation, | frame on its lan1 interface, remove the Ethernet encapsulation, | |||
and will determine how to dispatch the IP datagram based on | and determine how to dispatch the IP datagram based on | |||
Router1's multicast forwarding states. If Router1 knows that there | Router1's multicast forwarding states. If Router1 knows that there | |||
is a receiver for the multicast datagram on LAN2, it makes a copy of | is a receiver for the multicast datagram on LAN2, it makes a copy of | |||
the datagram, decrements the TTL (and performs any other necessary | the datagram, decrements the TTL (and performs any other necessary | |||
IP processing), then encapsulates the datagram in Ethernet frame for | IP processing), and then encapsulates the datagram in the Ethernet frame for | |||
LAN2. The MAC Source Address for this frame will be Router1's MAC | LAN2. The MAC Source Address for this frame will be Router1's MAC | |||
Source Address on LAN2. The MAC Destination Address is computed | Source Address on LAN2. The Destination MAC Address is computed | |||
from the IP Destination Address. Finally, the frame is sent on | from the IP Destination Address. Finally, the frame is sent on | |||
Router1's LAN2 interface. | Router1's LAN2 interface. | |||
</t> | </t> | |||
<t> | <t> | |||
<xref target="IRB"/> shows an Integrated Router/Bridge that supports | <xref target="IRB" format="default"/> shows an integrated router/bridge | |||
the routing/bridging integration model of <xref target="RFC9135"/>. | that supports | |||
<figure align="center" anchor="IRB" title="Integrated Router/Bridge"> | the routing/bridging integration model of <xref target="RFC9135" format= | |||
<artwork align="center"><![CDATA[ | "default"/>. | |||
</t> | ||||
<figure anchor="IRB"> | ||||
<name>Integrated Router/Bridge</name> | ||||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
+------------------------------------------+ | +------------------------------------------+ | |||
| Integrated Router/Bridge | | | Integrated Router/Bridge | | |||
+-------+ +--------+ +-------+ | +-------+ +--------+ +-------+ | |||
| | IRB1| L3 |IRB2 | | | | | IRB1| L3 |IRB2 | | | |||
H1 -----+ BD1 +--------+Routing +--------+ BD2 +------H3 | H1 -----+ BD1 +--------+Routing +--------+ BD2 +------H3 | |||
| | |Instance| | | | | | |Instance| | | | |||
H2 -----| | | | | | | H2 -----| | | | | | | |||
+-------+ +--------+ +-------+ | +-------+ +--------+ +-------+ | |||
|___________________| |____________________| | |___________________| |____________________| | |||
LAN1 LAN2 | LAN1 LAN2 | |||
]]> </artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</t> | ||||
<t> | <t> | |||
In <xref target="IRB"/>, a single device consists of one or more "L3 | In <xref target="IRB" format="default"/>, a single device consists of on | |||
Routing Instances". The routing/forwarding tables of a given | e or more L3 | |||
routing instance is known as an IP-VRF <xref target="RFC9135"/>. | Routing Instances. The routing/forwarding tables of a given | |||
routing instance is known as an IP-VRF <xref target="RFC9135" format="de | ||||
fault"/>. | ||||
In the context of EVPN, it is convenient to think of each routing | In the context of EVPN, it is convenient to think of each routing | |||
instance as representing the routing of a particular tenant. Each | instance as representing the routing of a particular tenant. Each | |||
IP-VRF is attached to one or more interfaces. | IP-VRF is attached to one or more interfaces. | |||
</t> | </t> | |||
<t> | <t> | |||
When several EVPN PEs have a routing instance of the same tenant | When several EVPN PEs have a routing instance of the same Tenant | |||
domain, those PEs advertise IP routes to the attached hosts. This | Domain, those PEs advertise IP routes to the attached hosts. This | |||
is done as specified in <xref target="RFC9135"/>. | is done as specified in <xref target="RFC9135" format="default"/>. | |||
</t> | </t> | |||
<t> | <t> | |||
The integrated router/bridge shown in <xref target="IRB"/> also | The integrated router/bridge shown in <xref target="IRB" format="default | |||
attaches to a number of "Broadcast Domains" (BDs). Each BD performs | "/> also | |||
the functions that are performed by the bridges in <xref | attaches to a number of Broadcast Domains (BDs). Each BD performs | |||
target="conventional_router"/>. To the L3 routing instance, each BD | the functions that are performed by the bridges in <xref target="convent | |||
ional_router" format="default"/>. To the L3 routing instance, each BD | ||||
appears to be a LAN. The interface attaching a particular BD to a | appears to be a LAN. The interface attaching a particular BD to a | |||
particular IP-VRF is known as an "IRB Interface". From the | particular IP-VRF is known as an "IRB interface". From the | |||
perspective of L3 routing, each BD is a subnet. Thus each IRB | perspective of L3 routing, each BD is a subnet. Thus, each IRB | |||
interface is configured with a MAC address (which is the router's | interface is configured with a MAC address (which is the router's | |||
MAC address on the corresponding LAN), as well as an IP address and | MAC address on the corresponding LAN), as well as an IP address and | |||
subnet mask. | subnet mask. | |||
</t> | </t> | |||
<t> | <t> | |||
The integrated router/bridge shown in <xref target="IRB"/> may have | The integrated router/bridge shown in <xref target="IRB" format="default "/> may have | |||
multiple ACs to each BD. These ACs are visible only to the bridging | multiple ACs to each BD. These ACs are visible only to the bridging | |||
function, not to the routing instance. To the L3 routing instance, | function, not to the routing instance. To the L3 routing instance, | |||
there is just one "interface" to each BD. | there is just one interface to each BD. | |||
</t> | </t> | |||
<t> | <t> | |||
If the L3 routing instance represents the IP routing of a particular | If the L3 routing instance represents the IP routing of a particular | |||
tenant, the BDs attached to that routing instance are BDs belonging | tenant, the BDs attached to that routing instance are BDs belonging | |||
to that same tenant. | to that same tenant. | |||
</t> | </t> | |||
<t> | <t> | |||
Bridging and routing now proceed exactly as in the case of <xref | Bridging and routing now proceed exactly as in the case of <xref target= | |||
target="conventional_router"/>, except that BD1 replaces Switch1, | "conventional_router" format="default"/>, except that BD1 replaces Switch1, | |||
BD2 replaces Switch2, interface IRB1 replaces interface lan1, and | BD2 replaces Switch2, interface IRB1 replaces interface lan1, and | |||
interface IRB2 replaces interface lan2. | interface IRB2 replaces interface lan2. | |||
</t> | </t> | |||
<t> | <t> | |||
It is important to understand that an IRB interface connects an L3 | It is important to understand that an IRB interface connects an L3 | |||
routing instance to a BD, NOT to a "MAC&nbhy;VRF". (See <xref | routing instance to a BD, NOT to a MAC-VRF (see <xref target="RFC7432" f | |||
target="RFC7432"/> for the definition of "MAC&nbhy;VRF".) A | ormat="default"/> for the definition of MAC-VRF). A | |||
MAC&nbhy;VRF may contain several BDs, as long as no MAC address | MAC-VRF may contain several BDs, as long as no MAC address | |||
appears in more than one BD. From the perspective of the L3 routing | appears in more than one BD. From the perspective of the L3 routing | |||
instance, each individual BD is an individual IP subnet; whether | instance, each individual BD is an individual IP subnet; whether or not | |||
each BD has its own MAC&nbhy;VRF or not is irrelevant to the L3 | each BD has its own MAC-VRF is irrelevant to the L3 | |||
routing instance. | routing instance. | |||
</t> | </t> | |||
<t> | <t> | |||
<xref target="two_router_irb"/> illustrates IRB when a pair of BDs | <xref target="two_router_irb" format="default"/> illustrates IRB when a pair of BDs | |||
(subnets) are attached to two different PE routers. In this | (subnets) are attached to two different PE routers. In this | |||
example, each BD has two segments, and one segment of each BD is | example, each BD has two segments, and one segment of each BD is | |||
attached to one PE router. | attached to one PE router. | |||
<figure align="center" anchor="two_router_irb" | </t> | |||
title="Integrated Router/Bridges with Distributed Subnet"> | <figure anchor="two_router_irb"> | |||
<artwork align="center"><![CDATA[ | <name>Integrated Router/Bridges with Distributed Subnet</name> | |||
<artwork align="center" name="" type="" alt=""><![CDATA[ | ||||
+------------------------------------------+ | +------------------------------------------+ | |||
| Integrated Router/Bridges | | | Integrated Router/Bridges | | |||
+-------+ +--------+ +-------+ | +-------+ +--------+ +-------+ | |||
| | IRB1| |IRB2 | | | | | IRB1| |IRB2 | | | |||
H1 -----+ BD1 +--------+ PE1 +--------+ BD2 +------H3 | H1 -----+ BD1 +--------+ PE1 +--------+ BD2 +------H3 | |||
|(Seg-1)| |(L3 Rtg)| |(Seg-1)| | |(Seg-1)| |(L3 Rtg)| |(Seg-1)| | |||
H2 -----| | | | | | | H2 -----| | | | | | | |||
+-------+ +--------+ +-------+ | +-------+ +--------+ +-------+ | |||
|___________________| | |____________________| | |___________________| | |____________________| | |||
LAN1 | LAN2 | LAN1 | LAN2 | |||
| | | | |||
| | | | |||
+-------+ +--------+ +-------+ | +-------+ +--------+ +-------+ | |||
| | IRB1| |IRB2 | | | | | IRB1| |IRB2 | | | |||
H4 -----+ BD1 +--------+ PE2 +--------+ BD2 +------H5 | H4 -----+ BD1 +--------+ PE2 +--------+ BD2 +------H5 | |||
|(Seg-2)| |(L3 Rtg)| |(Seg-2)| | |(Seg-2)| |(L3 Rtg)| |(Seg-2)| | |||
| | | | | | | | | | | | | | |||
+-------+ +--------+ +-------+ | +-------+ +--------+ +-------+ | |||
]]> </artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</t> | ||||
<t> | <t> | |||
If H1 needs to send an IP packet to H4, it determines from its IP | If H1 needs to send an IP packet to H4, it determines from its IP | |||
address and subnet mask that H4 is on the same subnet as H1. | address and subnet mask that H4 is on the same subnet as H1. | |||
Although H1 and H4 are not attached to the same PE router, EVPN | Although H1 and H4 are not attached to the same PE router, EVPN | |||
provides Ethernet communication among all hosts that are on the same | provides Ethernet communication among all hosts that are on the same | |||
BD. H1 thus uses ARP to find H4's MAC address, and sends an | BD. Thus, H1 uses ARP to find H4's MAC address and sends an | |||
Ethernet frame with H4's MAC address in the Destination MAC address | Ethernet frame with H4's MAC address in the Destination MAC Address | |||
field. The frame is received at PE1, but since the Destination MAC | field. The frame is received at PE1, but since the Destination MAC | |||
address is not PE1's MAC address, PE1 assumes that the frame is to | address is not PE1's MAC address, PE1 assumes that the frame is to | |||
remain on BD1. Therefore the packet inside the frame is NOT | remain on BD1. Therefore, the packet inside the frame is NOT | |||
decapsulated, and is NOT send up the IRB interface to PE1's routing | decapsulated and is NOT sent up the IRB interface to PE1's routing | |||
instance. Rather, standard EVPN intra&nbhy;subnet procedures (as | instance. Rather, standard EVPN intra-subnet procedures (as | |||
detailed in <xref target="RFC7432"/>) are used to deliver the frame | detailed in <xref target="RFC7432" format="default"/>) are used to deliv | |||
er the frame | ||||
to PE2, which then sends it to H4. | to PE2, which then sends it to H4. | |||
</t> | </t> | |||
<t> | <t> | |||
If H1 needs to send an IP packet to H5, it determines from its IP | If H1 needs to send an IP packet to H5, it determines from its IP | |||
address and subnet mask that H5 is NOT on the same subnet as H1. | address and subnet mask that H5 is NOT on the same subnet as H1. | |||
Assuming that H1 has been configured with the IP address of PE1 as | Assuming that H1 has been configured with the IP address of PE1 as | |||
its default router, H1 sends the packet in an Ethernet frame with | its default router, H1 sends the packet in an Ethernet frame with | |||
PE1's MAC address in its Destination MAC Address field. PE1 | PE1's MAC address in its Destination MAC Address field. PE1 | |||
receives the frame, and sees that the frame is addressed to it. PE1 | receives the frame and sees that the frame is addressed to it. Thus, PE1 | |||
thus sends the frame up its IRB1 interface to the L3 routing | sends the frame up its IRB1 interface to the L3 routing | |||
instance. Appropriate IP processing is done, e.g., TTL decrement. | instance. Appropriate IP processing is done, e.g., TTL decrement. | |||
The L3 routing instance determines that the "next hop" for H5 is | The L3 routing instance determines that the next hop for H5 is | |||
PE2, so the packet is encapsulated (e.g., in MPLS) and sent across | PE2, so the packet is encapsulated (e.g., in MPLS) and sent across | |||
the backbone to PE2's routing instance. PE2 will see that the | the backbone to PE2's routing instance. PE2 will see that the | |||
packet's destination, H5, is on BD2 segment-2, and will send the | packet's destination, H5, is on BD2 segment-2 and will send the | |||
packet down its IRB2 interface. This causes the IP packet to be | packet down its IRB2 interface. This causes the IP packet to be | |||
encapsulated in an Ethernet frame with PE2's MAC address (on BD2) in | encapsulated in an Ethernet frame with PE2's MAC address (on BD2) in | |||
the Source Address field and H5's MAC address in the Destination | the Source Address field and H5's MAC address in the Destination | |||
Address field. | Address field. | |||
</t> | </t> | |||
<t> | <t> | |||
Note that if H1 has an IP packet to send to H3, the forwarding of | Note that if H1 has an IP packet to send to H3, the forwarding of | |||
the packet is handled entirely within PE1. PE1's routing instance | the packet is handled entirely within PE1. PE1's routing instance | |||
sees the packet arrive on its IRB1 interface, and then transmits the | sees the packet arrive on its IRB1 interface and then transmits the | |||
packet by sending it down its IRB2 interface. | packet by sending it down its IRB2 interface. | |||
</t> | </t> | |||
<t> | <t> | |||
Often, all the hosts in a particular Tenant Domain will be | Often, all the hosts in a particular Tenant Domain will be | |||
provisioned with the same value of the default router IP address. | provisioned with the same value of the default router IP address. | |||
This IP address can be provisioned as an "anycast address" in all the | This IP address can be provisioned as an anycast address in all the | |||
EVPN PEs attached to that Tenant Domain. Thus although all hosts | EVPN PEs attached to that Tenant Domain. Thus, although all hosts | |||
are provisioned with the same "default router address", the actual | are provisioned with the same default router address, the actual | |||
default router for a given host will be one of the PEs | default router for a given host will be one of the PEs | |||
attached to the same Ethernet segment as the host. This | attached to the same Ethernet segment as the host. This | |||
provisioning method ensures that IP packets from a given host are | provisioning method ensures that IP packets from a given host are | |||
handled by the closest EVPN PE that supports IRB. | handled by the closest EVPN PE that supports IRB. | |||
</t> | </t> | |||
<t> | <t> | |||
In the topology of <xref target="two_router_irb"/>, one could | In the topology of <xref target="two_router_irb" format="default"/>, one could | |||
imagine that H1 is configured with a default router address that | imagine that H1 is configured with a default router address that | |||
belongs to PE2 but not to PE1. Inter-subnet routing would still | belongs to PE2 but not to PE1. Inter-subnet routing would still | |||
work, but IP packets from H1 to H3 would then follow the non-optimal | work, but IP packets from H1 to H3 would then follow the non-optimal | |||
path H1-->PE1-->PE2-->PE1-->H3. Sending traffic on this sort of | path H1-->PE1-->PE2-->PE1-->H3. Sending traffic on this sort of | |||
path, where it leaves a router and then comes back to the same | path, where it leaves a router and then comes back to the same | |||
router, is sometimes known as "hairpinning". Similarly, if PE2 | router, is sometimes known as "hairpinning". Similarly, if PE2 | |||
supports IRB but PE1 dos not, the same non-optimal path from H1 to | supports IRB but PE1 dos not, the same non-optimal path from H1 to | |||
H3 would have to be followed. To avoid hairpinning, each EVPN PE | H3 would have to be followed. To avoid hairpinning, each EVPN PE | |||
needs to support IRB. | needs to support IRB. | |||
</t> | </t> | |||
<t> | <t> | |||
It is worth pointing out the way IRB interfaces interact with | It is worth pointing out the way IRB interfaces interact with | |||
multicast traffic. Referring again to <xref | multicast traffic. Referring again to <xref target="two_router_irb" for | |||
target="two_router_irb"/>, suppose PE1 and PE2 are functioning as IP | mat="default"/>, suppose PE1 and PE2 are functioning as IP | |||
multicast routers. Also Suppose that H3 transmits a multicast packet, | multicast routers. Also, suppose that H3 transmits a multicast packet | |||
and both H1 and H4 are interested in receiving that packet. PE1 | and both H1 and H4 are interested in receiving that packet. PE1 | |||
will receive the packet from H3 via its IRB2 interface. The | will receive the packet from H3 via its IRB2 interface. The | |||
Ethernet encapsulation from BD2 is removed, the IP header processing | Ethernet encapsulation from BD2 is removed, the IP header processing | |||
is done, and the packet is then reencapsulated for BD1, with PE1's | is done, and the packet is then re-encapsulated for BD1, with PE1's | |||
MAC address in the MAC Source Address field. Then the packet is | MAC address in the MAC Source Address field. Then, the packet is | |||
sent down the IRB1 interface. Layer 2 procedures (as defined in | sent down the IRB1 interface. Layer 2 procedures (as defined in | |||
<xref target="RFC7432"/> would then be used to deliver a copy of the | <xref target="RFC7432" format="default"/>) would then be used to deliver | |||
packet locally to H1, and remotely to H4. | a copy of the | |||
packet locally to H1 and remotely to H4. | ||||
</t> | </t> | |||
<t> | <t> | |||
Please be aware that his document modifies the semantics, described | Please be aware that this document modifies the semantics, described | |||
in the previous paragraph, of sending/receiving multicast traffic on | in the previous paragraph, of sending/receiving multicast traffic on | |||
an IRB interface. This is explained in <xref target="cp_overview"/> | an IRB interface. This is explained in <xref target="cp_overview" forma t="default"/> | |||
and subsequent sections. | and subsequent sections. | |||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="Acknowledgements" numbered="false" toc="default"> | ||||
<name>Acknowledgements</name> | ||||
<t> | ||||
The authors thank <contact fullname="Vikram Nagarajan"/> and <contact fullna | ||||
me="Princy Elizabeth"/> for their work | ||||
on Sections <xref target="external_pim_router" format="counter"/> and <xref | ||||
target="SBD-matching" format="counter"/>. | ||||
The authors also benefited | ||||
tremendously from discussions with <contact fullname="Aldrin Isaac"/> on EVP | ||||
N multicast | ||||
optimizations. | ||||
</t> | ||||
</section> | ||||
<!-- [rfced] Please review the "Inclusive Language" portion of the | ||||
online Style Guide | ||||
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language> | ||||
and let us know if any changes are needed. | ||||
For example, please consider whether the following should be updated. | ||||
traditional: | ||||
First it shows the traditional model, where bridging | ||||
and routing are performed in separate devices. | ||||
... | ||||
Figure 1 shows a "traditional" router that only does routing and has | ||||
no L2 bridging capabilities. | ||||
--> | ||||
</back> | </back> | |||
</rfc> | </rfc> | |||
End of changes. 845 change blocks. | ||||
3843 lines changed or deleted | 3260 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |