< draft-ietf-bess-evpn-irb-mcast-07.txt.orig | draft-ietf-bess-evpn-irb-mcast-07.txt > | |||
---|---|---|---|---|
skipping to change at page 1, line 32 ¶ | skipping to change at page 1, line 32 ¶ | |||
site, and the segments are interconnected by an IP or MPLS backbone. | site, and the segments are interconnected by an IP or MPLS backbone. | |||
Intra-subnet traffic (either unicast or multicast) always appears to | Intra-subnet traffic (either unicast or multicast) always appears to | |||
the endusers to be bridged, even when it is actually carried over the | the endusers to be bridged, even when it is actually carried over the | |||
IP or MPLS backbone. When a single "tenant" owns multiple such LANs, | IP or MPLS backbone. When a single "tenant" owns multiple such LANs, | |||
EVPN also allows IP unicast traffic to be routed between those LANs. | EVPN also allows IP unicast traffic to be routed between those LANs. | |||
This document specifies new procedures that allow inter-subnet IP | This document specifies new procedures that allow inter-subnet IP | |||
multicast traffic to be routed among the LANs of a given tenant, | multicast traffic to be routed among the LANs of a given tenant, | |||
while still making intra-subnet IP multicast traffic appear to be | while still making intra-subnet IP multicast traffic appear to be | |||
bridged. These procedures can provide optimal routing of the inter- | bridged. These procedures can provide optimal routing of the inter- | |||
subnet multicast traffic, and do not require any such traffic to | subnet multicast traffic, and do not require any such traffic to | |||
leave a given router and then reenter that same router. These | egress a given router and then ingress that same router. These | |||
procedures also accommodate IP multicast traffic that needs to travel | procedures also accommodate IP multicast traffic that originages | |||
to or from systems that are outside the EVPN domain. | or is destined external to the EVPN domain. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
skipping to change at page 4, line 10 ¶ | skipping to change at page 4, line 10 ¶ | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 67 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 67 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 69 | 11.2. Informative References . . . . . . . . . . . . . . . . . 69 | |||
Appendix A. Integrated Routing and Bridging . . . . . . . . . . 71 | Appendix A. Integrated Routing and Bridging . . . . . . . . . . 71 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 | |||
1. Introduction | 1. Introduction | |||
1.1. Background | 1.1. Background | |||
Ethernet VPN (EVPN) [RFC7432] provides a Layer 2 VPN (L2VPN) | Ethernet VPN (EVPN) [RFC7432] provides a Layer 2 VPN (L2VPN) | |||
solution, which allows IP backbone provider to offer ethernet service | solution, which allows an IP backbone provider to offer ethernet service | |||
to a set of customers, known as "tenants". | to a set of customers, known as "tenants". | |||
In this section (as well as in [RFC9135]), we provide some essential | In this section (as well as in [RFC9135]), we provide some essential | |||
background information on EVPN. | background information on EVPN. | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
skipping to change at page 4, line 32 ¶ | skipping to change at page 4, line 32 ¶ | |||
1.1.1. Segments, Broadcast Domains, and Tenants | 1.1.1. Segments, Broadcast Domains, and Tenants | |||
One of the key concepts of EVPN is the Broadcast Domain (BD). A BD | One of the key concepts of EVPN is the Broadcast Domain (BD). A BD | |||
is essentially an emulated ethernet. Each BD belongs to a single | is essentially an emulated ethernet. Each BD belongs to a single | |||
tenant. A BD typically consists of multiple ethernet "segments", and | tenant. A BD typically consists of multiple ethernet "segments", and | |||
each segment may be attached to a different EVPN Provider Edge | each segment may be attached to a different EVPN Provider Edge | |||
(EVPN-PE) router. EVPN-PE routers are often referred to as "Network | (EVPN-PE) router. EVPN-PE routers are often referred to as "Network | |||
Virtualization Endpoints" or NVEs. However, this document will use | Virtualization Endpoints" or NVEs. However, this document will use | |||
the term "EVPN-PE", or, when the context is clear, just "PE". | the term "EVPN-PE", or, when the context is clear, just "PE". | |||
In this document, we use the term "segment" to mean the same as | In this document, the term "segment" is used interchangable with the | |||
"Ethernet Segment" or "ES" in [RFC7432]. | term "Ethernet Segment" or "ES" in [RFC7432]. | |||
Attached to each segment are "Tenant Systems" (TSes). A TS may be | Attached to each segment are "Tenant Systems" (TSes). A TS may be | |||
any type of system, physical or virtual, host or router, etc., that | any type of system, physical or virtual, host or router, etc., that | |||
can attach to an ethernet. | can attach to an ethernet. | |||
When two TSes are on the same segment, traffic between them does not | When two TSes are on the same segment, traffic between them does not | |||
pass through an EVPN-PE. When two TSes are on different segments of | pass through an EVPN-PE. When two TSes are on different segments of | |||
the same BD, traffic between them does pass through an EVPN-PE. | the same BD, traffic between them does pass through an EVPN-PE. | |||
When two TSes, say TS1 and TS2 are on the same BD, then: | When two TSes, say TS1 and TS2 are on the same BD, then: | |||
o If TS1 knows the MAC address of TS2, TS1 can send unicast ethernet | o If TS1 knows the MAC address of TS2, TS1 can send unicast ethernet | |||
frames to TS2. TS2 will receive the frames unaltered. | frames to TS2. TS2 will receive the frames unaltered. | |||
o If TS1 broadcasts an ethernet frame, TS2 will receive the | o If TS1 broadcasts an ethernet frame, TS2 will receive the | |||
unaltered frame. | unaltered frame. | |||
o If TS1 multicasts an ethernet frame, TS2 will receive the | o If TS1 multicasts an ethernet frame, TS2 will receive the | |||
unaltered frame, as long as TS2 has been provisioned to receive | unaltered frame, as long as TS2 has been provisioned to receive | |||
ethernet multicasts. | the ethernet multicast destination MAC address. | |||
When we say that TS2 receives an unaltered frame from TS1, we mean | When we say that TS2 receives an unaltered frame from TS1, we mean | |||
that the frame still contains TS1's MAC address, and that no | that the frame still contains TS1's MAC address, and that no | |||
alteration of the frame's payload (and consequently, no alteration of | alteration of the frame's payload (and consequently, no alteration of | |||
the payload's IP header) has been made. | the payload's IP header) has been made. | |||
EVPN allows a single segment to be attached to multiple PE routers. | EVPN allows a single segment to be attached to multiple PE routers. | |||
This is known as "EVPN multi-homing". Suppose a given segment is | This is known as "EVPN multi-homing". Suppose a given segment is | |||
attached to both PE1 and PE2, and suppose PE1 receives a frame from | attached to both PE1 and PE2, and suppose PE1 receives a frame from | |||
that segment. It may be necessary for PE1 to send the frame over the | that segment. It may be necessary for PE1 to send the frame over the | |||
skipping to change at page 6, line 48 ¶ | skipping to change at page 6, line 48 ¶ | |||
The purpose of this document is to specify procedures for EVPN that | The purpose of this document is to specify procedures for EVPN that | |||
provide optimized IP multicast functionality within an EVPN tenant | provide optimized IP multicast functionality within an EVPN tenant | |||
domain. This document also specifies procedures that allow IP | domain. This document also specifies procedures that allow IP | |||
multicast packets to be sourced from or destined to systems outside | multicast packets to be sourced from or destined to systems outside | |||
the Tenant Domain. We refer to the entire set of these procedures as | the Tenant Domain. We refer to the entire set of these procedures as | |||
"OISM" (Optimized Inter-Subnet Multicast) procedures. | "OISM" (Optimized Inter-Subnet Multicast) procedures. | |||
In order to support the OISM procedures specified in this document, | In order to support the OISM procedures specified in this document, | |||
an EVPN-PE MUST also support [RFC9135] and [RFC9251]. (However, | an EVPN-PE MUST also support [RFC9135] and [RFC9251]. (However, | |||
certain of the procedures in [RFC9251] are modified when OISM is | certain procedures in [RFC9251] are modified when OISM is | |||
supported.) | supported.) | |||
1.1.4. BDs, MAC-VRFS, and EVPN Service Models | 1.1.4. BDs, MAC-VRFS, and EVPN Service Models | |||
[RFC7432] defines the notion of "MAC-VRF". A MAC-VRF contains one or | [RFC7432] defines the notion of "MAC-VRF". A MAC-VRF contains one or | |||
more "Bridge Tables" (see section 3 of [RFC7432] for a discussion of | more "Bridge Tables" (see section 3 of [RFC7432] for a discussion of | |||
this terminology), each of which represents a single Broadcast | this terminology), each of which represents a single Broadcast | |||
Domain. | Domain. | |||
In the IRB model (outlined in Appendix A) a L3 routing instance has | In the IRB model (outlined in Appendix A), an L3 routing instance has | |||
one IRB interface per BD, NOT one per MAC-VRF. This document does | one IRB interface per BD, NOT one per MAC-VRF. This document does | |||
not distinguish between a "Broadcast Domain" and a "Bridge Table", | not distinguish between a "Broadcast Domain" and a "Bridge Table", | |||
and will use the terms interchangeably (or will use the acronym "BD" | and will use the terms interchangeably (or will use the acronym "BD" | |||
to refer to either). The way the BDs are grouped into MAC-VRFs is | to refer to either). The way the BDs are grouped into MAC-VRFs is | |||
not relevant to the procedures specified in this document. | not relevant to the procedures specified in this document. | |||
Section 6 of [RFC7432] also defines several different EVPN service | Section 6 of [RFC7432] also defines several different EVPN service | |||
models: | models: | |||
o In the "vlan-based service", each MAC-VRF contains one "bridge | o In the "vlan-based service", each MAC-VRF contains one "bridge | |||
skipping to change at page 8, line 34 ¶ | skipping to change at page 8, line 34 ¶ | |||
the Tenant Multicast Router will make two copies of the packet, one | the Tenant Multicast Router will make two copies of the packet, one | |||
for BD2 and one for BD3. PE2 will send both copies back to PE1. Not | for BD2 and one for BD3. PE2 will send both copies back to PE1. Not | |||
only is the routing sub-optimal, but PE2 sends multiple copies of the | only is the routing sub-optimal, but PE2 sends multiple copies of the | |||
same packet to PE1. This is a further sub-optimality. | same packet to PE1. This is a further sub-optimality. | |||
This is only an example; many more examples of sub-optimal multicast | This is only an example; many more examples of sub-optimal multicast | |||
routing can easily be given. To eliminate sub-optimal routing and | routing can easily be given. To eliminate sub-optimal routing and | |||
extra copies, it is necessary to have a multicast solution that is | extra copies, it is necessary to have a multicast solution that is | |||
EVPN-aware, and that can use its knowledge of the internal structure | EVPN-aware, and that can use its knowledge of the internal structure | |||
of a Tenant Domain to ensure that multicast traffic gets routed | of a Tenant Domain to ensure that multicast traffic gets routed | |||
optimally. The procedures of this document allow us to avoid all | optimally. The procedures in this document allow us to avoid all | |||
such sub-optimalities when routing inter-subnet multicasts within a | such sub-optimalities when routing inter-subnet multicast traffic within a | |||
Tenant Domain. | Tenant Domain. | |||
1.3. Additional Requirements That Must be Met by the Solution | 1.3. Additional Requirements That Must be Met by the Solution | |||
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: | |||
o The solution must integrate well with the procedures specified in | o The solution must integrate well with the procedures specified in | |||
[RFC9251]. That is, an integrated set of procedures must handle | [RFC9251]. That is, an integrated set of procedures must handle | |||
skipping to change at page 9, line 19 ¶ | skipping to change at page 9, line 19 ¶ | |||
* 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 not | processing of the ethernet payload is done. The IP TTL is not | |||
decremented, the header checksum is not changed, no | decremented, the header checksum is not changed, no | |||
fragmentation is done, etc. | fragmentation is done, etc. | |||
o On the other hand, if a source and a receiver are on different | o On the other hand, if a source and a receiver are on different | |||
subnets, the frame received by the receiver will not have the MAC | subnets, the frame received by the receiver will not have the MAC | |||
Source address of the source, as the frame will appear to have | Source address of the source, as the frame will appear to have | |||
come from a multicast router. Also, proper processing of the IP | come from a multicast router. Also, proper processing of the IP | |||
header is done, e.g., TTL decrement by 1, header checksum | header is done, e.g., TTL decrement by 1, header checksum | |||
modification, possibly fragmentation, etc. | modification, possible fragmentation, etc. | |||
o If a Tenant Domain contains several BDs, it MUST be possible for a | o If a Tenant Domain contains several BDs, it MUST be possible for a | |||
multicast flow (even when the multicast group address is an "any | multicast flow (even when the multicast group address is an "any | |||
source multicast" (ASM) address), to have sources in one of those | source multicast" (ASM) address), to have sources in one of those | |||
BDs and receivers in one or more of the other BDs, without | BDs and receivers in one or more of the other BDs, without | |||
requiring the presence of any system performing PIM Rendezvous | requiring the presence of any system performing PIM Rendezvous | |||
Point (RP) functions ([RFC7761]). Multicast throughout a Tenant | Point (RP) functions [RFC7761]. Multicast throughout a Tenant | |||
Domain must not require the tenant systems to be aware of any | Domain must not require the tenant systems to be aware of any | |||
underlying multicast infrastructure. | underlying multicast infrastructure. | |||
o Sometimes a MAC address used by one TS on a particular BD is also | o Sometimes a MAC address used by one TS on a particular BD is also | |||
used by another TS on a different BD. Inter-subnet routing of | used by another TS on a different BD. Inter-subnet routing of | |||
multicast traffic MUST NOT make any assumptions about the | multicast traffic MUST NOT make any assumptions about the | |||
uniqueness of a MAC address across several BDs. | uniqueness of a MAC address across several BDs. | |||
o If two EVPN-PEs attached to the same Tenant Domain both support | o If two EVPN-PEs attached to the same Tenant Domain both support | |||
the OISM procedures, each may receive inter-subnet multicasts from | the OISM procedures, each may receive inter-subnet multicasts from | |||
the other, even if the egress PE is not attached to any segment of | the other, even if the egress PE is not attached to any segment of | |||
the BD from which the multicast packets are being sourced. It | the BD from which the multicast packets are being sourced. It | |||
MUST NOT be necessary to provision the egress PE with knowledge of | MUST NOT be necessary to provision the egress PE with knowledge of | |||
the ingress BD. | the ingress BD. | |||
o There must be a procedure that that allows EVPN-PE routers | o There must be a procedure that allows EVPN-PE routers | |||
supporting OISM procedures to send/receive multicast traffic to/ | supporting OISM procedures to send/receive multicast traffic to/ | |||
from EVPN-PE routers that support only [RFC7432], but that do not | from EVPN-PE routers that support only [RFC7432], but that do not | |||
support the OISM procedures or even the procedures of [RFC9135]. | support the OISM procedures or even the procedures of [RFC9135]. | |||
However, when interworking with such routers (which we call | However, when interworking with such routers (which we call | |||
"non-OISM PE routers"), optimal routing may not be achievable. | "non-OISM PE routers"), optimal routing may not be achievable. | |||
o It MUST be possible to support scenarios in which multicast flows | o It MUST be possible to support scenarios in which multicast flows | |||
with sources inside a Tenant Domain have "external" receivers, | with sources inside a Tenant Domain have "external" receivers, | |||
i.e., receivers that are outside the domain. It must also be | i.e., receivers that are outside the domain. It must also be | |||
possible to support scenarios where multicast flows with external | possible to support scenarios where multicast flows with external | |||
sources (sources outside the Tenant Domain) have receivers inside | sources (sources outside the Tenant Domain) have receivers inside | |||
the domain. | the domain. | |||
This presupposes that unicast routes to multicast sources outside | This presupposes that unicast routes to multicast sources outside | |||
the domain can be distributed to EVPN-PEs attached to the domain, | the domain can be distributed to EVPN-PEs attached to the domain, | |||
and that unicast routes to multicast sources within the domain can | and that unicast routes to multicast sources within the domain can | |||
be distributed outside the domain. | be distributed outside the domain. | |||
Of particular importance are the scenario in which the external | Of particular importance is the scenario in which the external | |||
sources and/or receivers are reachable via L3VPN/MVPN, and the | sources and/or receivers are reachable via L3VPN/MVPN, and the | |||
scenario in which external sources and/or receivers are reachable | scenario in which external sources and/or receivers are reachable | |||
via IP/PIM. | via IP/PIM. | |||
The solution for external interworking MUST allow for deployment | The solution for external interworking MUST allow for deployment | |||
scenarios in which EVPN does not need to export a host route for | scenarios in which EVPN does not need to export a host route for | |||
every multicast source. | every multicast source. | |||
o The solution for external interworking must not presuppose that | o The solution for external interworking must not presuppose that | |||
the same tunneling technology is used within both the EVPN domain | the same tunneling technology is used within both the EVPN domain | |||
skipping to change at page 11, line 32 ¶ | skipping to change at page 11, line 32 ¶ | |||
becomes that EVI's DF for that segment. Since a BD may belong to | becomes that EVI's DF for that segment. Since a BD may belong to | |||
only one EVI, we can speak unambiguously of the BD's DF for a | only one EVI, we can speak unambiguously of the BD's DF for a | |||
given segment. | given segment. | |||
When the text makes it clear that we are speaking in the context | 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 | of a given BD, we will frequently use the term "a segment's DF" to | |||
mean the given BD's DF for that segment. | mean the given BD's DF for that segment. | |||
o AC: Attachment Circuit. An AC connects the bridging function of | o AC: Attachment Circuit. An AC connects the bridging function of | |||
an EVPN-PE to an ethernet segment of a particular BD. ACs are not | an EVPN-PE to an ethernet segment of a particular BD. ACs are not | |||
visible at the router (L3) layer. | visible at the router L3 layer. | |||
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 will say that the PE has n ACs to that segment. | |||
o L3 Gateway: An L3 Gateway is a PE that connects an EVPN tenant | o L3 Gateway: An L3 Gateway is a PE that connects an EVPN tenant | |||
domain to an external multicast domain by performing both the OISM | domain to an external multicast domain by performing both the OISM | |||
procedures and the Layer 3 multicast procedures of the external | procedures and the Layer 3 multicast procedures of the external | |||
domain. | domain. | |||
o PEG (PIM/EVPN Gateway): A L3 Gateway that connects an EVPN Tenant | o PEG (PIM/EVPN Gateway): A L3 Gateway that connects an EVPN Tenant | |||
skipping to change at page 12, line 8 ¶ | skipping to change at page 12, line 8 ¶ | |||
o MEG (MVPN/EVPN Gateway): A L3 Gateway that connects an EVPN Tenant | o MEG (MVPN/EVPN Gateway): A L3 Gateway that connects an EVPN Tenant | |||
Domain to an external multicast domain whose Layer 3 multicast | Domain to an external multicast domain whose Layer 3 multicast | |||
procedures are those of MVPN ([RFC6513], [RFC6514]). | procedures are those of MVPN ([RFC6513], [RFC6514]). | |||
o IPMG (IP Multicast Gateway): A PE that is used for interworking | o IPMG (IP Multicast Gateway): A PE that is used for interworking | |||
OISM EVPN-PEs with non-OISM EVPN-PEs. | OISM EVPN-PEs with non-OISM EVPN-PEs. | |||
o DR (Designated Router): A PE that has special responsibilities for | o DR (Designated Router): A PE that has special responsibilities for | |||
handling multicast on a given BD. | handling multicast on a given BD. | |||
o FHR (First Hop Router): The FHR is a PIM router ([RFC7761]) with | o FHR (First Hop Router): The FHR is a PIM router [RFC7761] with | |||
special responsibilities. It is the first multicast router to see | special responsibilities. It is the first multicast router to see | |||
(S,G) packets from source S, and if G is an "Any Source Multicast | (S,G) packets from source S, and if G is an "Any Source Multicast | |||
(ASM)" group, the FHR is responsible for sending PIM Register | (ASM)" group, the FHR is responsible for sending PIM Register | |||
messages to the PIM Rendezvous Point for group G. | messages to the PIM Rendezvous Point for group G. | |||
o LHR (Last Hop Router): The LHR is a PIM router ([RFC7761]) with | o LHR (Last Hop Router): The LHR is a PIM router [RFC7761] with | |||
special responsibilities. Generally it is attached to a LAN, and | special responsibilities. Generally it is attached to a LAN, and | |||
it determines whether there are any hosts on the LAN that need to | it determines whether there are any hosts on the LAN that need to | |||
receive a given multicast flow. If so, it creates and sends the | receive a given multicast flow. If so, it creates and sends the | |||
PIM Join messages that are necessary to draw the flow. | PIM Join messages that are necessary to receive the flow. | |||
o EC (Extended Community). A BGP Extended Communities attribute | o EC (Extended Community). A BGP Extended Communities attribute | |||
([RFC4360], [RFC7153]) is a BGP path attribute that consists of | ([RFC4360], [RFC7153]) is a BGP path attribute that consists of | |||
one or more extended communities. | one or more extended communities. | |||
o RT (Route Target): A Route Target is a particular kind of BGP | o RT (Route Target): A Route Target is a particular kind of 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 type/sub-type | field, a sub-type field, and a value field. Certain type/sub-type | |||
combinations indicate that a particular Extended Community is an | combinations indicate that a particular Extended Community is an | |||
RT. RT1 and RT2 are considered to be the same RT if and only if | RT. RT1 and RT2 are considered to be the same RT if and only if | |||
skipping to change at page 13, line 28 ¶ | skipping to change at page 13, line 28 ¶ | |||
However, each PE attached to a given Tenant Domain must be configured | However, each PE attached to a given Tenant Domain must be configured | |||
with the SBD for that Tenant Domain. | with the SBD for that Tenant Domain. | |||
Suppose a particular segment of a particular BD is attached to PE1. | Suppose a particular segment of a particular BD is attached to PE1. | |||
[RFC7432] specifies that PE1 must originate an Inclusive Multicast | [RFC7432] specifies that PE1 must originate an Inclusive Multicast | |||
Ethernet Tag (IMET) route for that BD, and that the IMET route must | Ethernet Tag (IMET) route for that BD, and that the IMET route must | |||
be propagated to all other PEs attached to the same BD. If the given | be propagated to all other PEs attached to the same BD. If the given | |||
segment contains a host that has interest in receiving a particular | segment contains a host that has interest in receiving a particular | |||
multicast flow, either an (S,G) flow or a (*,G) flow, PE1 will learn | multicast flow, either an (S,G) flow or a (*,G) flow, PE1 will learn | |||
of that interest by participating in the IGMP/MLD procedures, as | of that interest by participating in the IGMP/MLD procedures, as | |||
specified in [RFC9251]. In this case, we will say that: | specified in [RFC9251]. In this case: | |||
o PE1 is interested in receiving the flow; | o PE1 is interested in receiving the flow; | |||
o The AC attaching the interested host to PE1 is also said to be | o The AC attaching the interested host to PE1 is also said to be | |||
interested in the flow; | interested in the flow; | |||
o The BD containing an AC that is interested in a particular flow is | o The BD containing an AC that is interested in a particular flow is | |||
also said to be interested in that flow. | also said to be interested in that flow. | |||
Once PE1 determines that it has an AC that is interested in receiving | Once PE1 determines that it has an AC that is interested in receiving | |||
a particular flow or set of flows, it originates one or more | a particular flow or set of flows, it originates one or more | |||
Selective Multicast Ethernet Tag (SMET) route to advertise that | Selective Multicast Ethernet Tag (SMET) route(s) to advertise that | |||
interest. | interest. | |||
Note that each IMET or SMET route is "for" a particular BD. The | Note that each IMET or SMET route is "for" a particular BD. The | |||
notion of a route being "for" a particular BD is explained in | notion of a route being "for" a particular BD is explained in | |||
Section 2.2. | Section 2.2. | |||
When OISM is being supported, the procedures of [RFC9251], are | When OISM is being supported, the procedures of [RFC9251], are | |||
modified as follows: | modified as follows: | |||
o The IMET route originated by a particular PE for a particular BD | o The IMET route originated by a particular PE for a particular BD | |||
skipping to change at page 14, line 46 ¶ | skipping to change at page 14, line 46 ¶ | |||
and at least one of PE2's IMET routes indicates that PE2 is an OISM | and at least one of PE2's IMET routes indicates that PE2 is an OISM | |||
PE, PE1 MUST assume that PE2 is following OISM procedures. | PE, PE1 MUST assume that PE2 is following OISM procedures. | |||
1.5.2. Data Plane | 1.5.2. Data Plane | |||
Suppose PE1 has an AC to a segment in BD1, and PE1 receives from that | Suppose PE1 has an AC to a segment in BD1, and PE1 receives from that | |||
AC an (S,G) multicast frame (as defined in Section 1.4). | AC an (S,G) multicast frame (as defined in Section 1.4). | |||
There may be other ACs of PE1 on which TSes have indicated an | There may be other ACs of PE1 on which TSes have indicated an | |||
interest (via IGMP/MLD) in receiving (S,G) multicast packets. PE1 is | interest (via IGMP/MLD) in receiving (S,G) multicast packets. PE1 is | |||
responsible for sending the received multicast packet out those ACs. | responsible for sending the received multicast packets on those ACs. | |||
There are two cases to consider: | There are two cases to consider: | |||
o Intra-Subnet Forwarding: In this case, an attachment AC with | o Intra-Subnet Forwarding: In this case, an attachment AC with | |||
interest in (S,G) is connected to a segment that is part of the | interest in (S,G) is connected to a segment that is part of the | |||
source BD, BD1. If the segment is not multi-homed, or if PE1 is | source BD, BD1. If the segment is not multi-homed, or if PE1 is | |||
the Designated Forwarder (DF) (see [RFC7432]) for that segment, | the Designated Forwarder (DF) (see [RFC7432]) for that segment, | |||
PE1 sends the multicast frame on that AC without changing the MAC | PE1 sends the multicast frame on that AC without changing the MAC | |||
SA. The IP header is not modified at all; in particular, the TTL | SA. The IP header is not modified at all; in particular, the TTL | |||
is not decremented. | is not decremented. | |||
skipping to change at page 15, line 36 ¶ | skipping to change at page 15, line 36 ¶ | |||
o If PE2 is attached to BD1, the tunnel encapsulation used to send | o If PE2 is attached to BD1, the tunnel encapsulation used to send | |||
the frame to PE2 will cause PE2 to identify BD1 as the apparent | the frame to PE2 will cause PE2 to identify BD1 as the apparent | |||
source BD. | source BD. | |||
o If PE2 is not attached to BD1, the tunnel encapsulation used to | o 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 the | send the frame to PE2 will cause PE2 to identify the SBD as the | |||
apparent source BD. | apparent source BD. | |||
Note that the tunnel encapsulation used for a particular BD will have | Note that the tunnel encapsulation used for a particular BD will have | |||
been advertised in an IMET route or S-PMSI route | been advertised in an IMET route or S-PMSI route | |||
([I-D.ietf-bess-evpn-bum-procedure-updates]) for that BD. That route | [I-D.ietf-bess-evpn-bum-procedure-updates] for that BD. That route | |||
carries a PMSI Tunnel attribute, which specifies how packets | carries a PMSI Tunnel attribute, which specifies how packets | |||
originating from that BD are encapsulated. This information enables | originating from that BD are encapsulated. This information enables | |||
the PE receiving a tunneled packet to identify the apparent source BD | the PE receiving a tunneled packet to identify the apparent source BD | |||
as stated above. See Section 3.2 for more details. | as stated above. See Section 3.2 for more details. | |||
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). | |||
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 | |||
skipping to change at page 17, line 8 ¶ | skipping to change at page 17, line 8 ¶ | |||
o Suppose some other EVPN-PE, say PE2, has interest in (S,G). PE1 | o Suppose some other EVPN-PE, say PE2, has interest in (S,G). PE1 | |||
encapsulates the packet for ethernet, filling in the MAC SA field | encapsulates the packet for ethernet, filling in the MAC SA field | |||
with PE1's own MAC address on the SBD. PE1 then tunnels the | with PE1's own MAC address on the SBD. PE1 then tunnels the | |||
packet to PE2. The tunnel encapsulation will identify the | packet to PE2. The tunnel encapsulation will identify the | |||
apparent source BD as the SBD. Since the apparent source BD is | apparent source BD as the SBD. Since the apparent source BD is | |||
the SBD, PE2 will know to treat the frame as an inter-subnet | the SBD, PE2 will know to treat the frame as an inter-subnet | |||
multicast. | multicast. | |||
When ingress replication is used to transmit IP multicast frames from | When ingress replication is used to transmit IP multicast frames from | |||
an ingress EVPN-PE to a set of egress PEs, then of course the ingress | an ingress EVPN-PE to a set of egress PEs, then the ingress | |||
PE has to send multiple copies of the frame. Each copy is the | PE has to send multiple copies of the frame. Each copy is the | |||
original ethernet frame; decapsulation and IP processing take place | original ethernet frame; decapsulation and IP processing take place | |||
only at the egress PE. | only at the egress PE. | |||
If a Point-to-Multipoint (P2MP) tree or BIER ([I-D.ietf-bier-evpn]) | If a Point-to-Multipoint (P2MP) tree or BIER [I-D.ietf-bier-evpn] | |||
is used to transmit an IP multicast frame from an ingress PE to a set | is used to transmit an IP multicast frame from an ingress PE to a set | |||
of egress PEs, then the ingress PE only has to send one copy of the | of egress PEs, then the ingress PE only has to send one copy of the | |||
frame to each of its next hops. Again, each egress PE receives the | frame to each of its next hops. Again, each egress PE receives the | |||
original frame and does any necessary IP processing. | original frame and does any necessary IP processing. | |||
2. Detailed Model of Operation | 2. Detailed Model of Operation | |||
The model described in Section 1.5.2 can be expressed more precisely | The model described in Section 1.5.2 can be expressed more precisely | |||
using the notion of "IRB interface" (see Appendix A). For a given | using the notion of "IRB interface" (see Appendix A). For a given | |||
Tenant Domain: | Tenant Domain: | |||
o A given PE has one IRB for each BD to which it is attached. This | o 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 IP multicast | IRB interface connects L3 routing to that BD. When IP multicast | |||
packets are sent or received on the IRB interfaces, the semantics | packets are sent or received on the IRB interfaces, the semantics | |||
of the interface is modified from the semantics described in | of the interface is modified from the semantics described in | |||
Appendix A. See Section 2.3 for the details of the modification. | Appendix A. See Section 2.3 for the details of the modification. | |||
o Each PE also has an IRB interface that connects L3 routing to the | o Each PE also has an IRB interface that connects L3 routing to the | |||
SBD. The semantics of this interface is different than the | SBD. The semantics of this interface is different than the | |||
semantics of the IRB interface to the real BDs. See Section 2.3. | semantics of the IRB interface to the real BDs. See Section 2.3. | |||
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 | |||
skipping to change at page 18, line 7 ¶ | skipping to change at page 18, line 7 ¶ | |||
Suppose a given Tenant Domain contains three BDs (BD1, BD2, BD3) and | Suppose a given Tenant Domain contains three BDs (BD1, BD2, BD3) and | |||
two PEs (PE1, PE2). PE1 attaches to BD1 and BD2, while PE2 attaches | two PEs (PE1, PE2). PE1 attaches to BD1 and BD2, while PE2 attaches | |||
to BD2 and BD3. | to BD2 and BD3. | |||
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 Route Target (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-RT". | "SBD-RT". | |||
A Tenant Domain is also configured with an IP-VRF ([RFC9135]), and | A Tenant Domain is also configured with an IP-VRF [RFC9135], and | |||
the IP-VRF is associated with an RT. This RT MAY be the same as the | the IP-VRF is associated with an RT. This RT MAY be the same as the | |||
SBD-RT. | SBD-RT. | |||
Suppose an (S,G) multicast frame originating on BD1 has a receiver on | 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 | 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, and/ | BD1 to BD3 even though its ingress PE is not configured for BD3, and/ | |||
or its egress PE is not configured for BD1. | or its egress PE is not configured for BD1. | |||
skipping to change at page 19, line 14 ¶ | skipping to change at page 19, line 14 ¶ | |||
In those service models that allow a set of BDs to share a single RT, | In those service models that allow a set of BDs to share a single RT, | |||
each BD is assigned a non-zero Tag ID. The Tag ID appears in the | each BD is assigned a non-zero Tag ID. The Tag ID appears in the | |||
Network Layer Reachability Information (NLRI) of many of the BGP | Network Layer Reachability Information (NLRI) of many of the BGP | |||
routes that are used by the EVPN control plane. | routes that are used by the EVPN control plane. | |||
A given route may be about the SBD, or about an "ordinary BD" (a BD | A given route may be about the SBD, or about an "ordinary BD" (a BD | |||
that is not the SBD). An RT that has been assigned to an ordinary BD | that is not the SBD). An RT that has been assigned to an ordinary BD | |||
will be known as an "ordinary BD-RT". | will be known as an "ordinary BD-RT". | |||
When constructing an IMET, SMET, S-PMSI or Leaf | When constructing an IMET, SMET, S-PMSI, or Leaf | |||
([I-D.ietf-bess-evpn-bum-procedure-updates]) route that is about a | ([I-D.ietf-bess-evpn-bum-procedure-updates]) route that is about a | |||
given BD, the following rules apply: | given BD, the following rules apply: | |||
o If the route is about an ordinary BD, say BD1, then | o If the route is about an ordinary BD, say BD1, then | |||
* the route MUST carry the ordinary BD-RT associated with BD1, | * the route MUST carry the ordinary BD-RT associated with BD1, | |||
and | and | |||
* the route MUST NOT carry any RT that is associated with an | * the route MUST NOT carry any RT that is associated with an | |||
ordinary BD other than BD1. | ordinary BD other than BD1. | |||
o If the route is about the SBD, the route MUST carry the SBD-RT, | o If the route is about the SBD, the route MUST carry the SBD-RT, | |||
and MUST NOT carry any RT that is associated with any other BD. | and MUST NOT carry any RT that is associated with any other BD. | |||
o As detailed in subsequent sections, under certain circumstances a | o As detailed in subsequent sections, under certain circumstances a | |||
route that is about BD1 may carry both the RT of BD1 and also the | route that is about BD1 may carry both the RT of BD1 and also the | |||
SBD-RT. | SBD-RT. | |||
The IMET route for the SBD MUST carry an Multicast Flags Extended | The IMET route for the SBD MUST carry a Multicast Flags Extended | |||
Community, in which an "OISM SBD" flag is set. | Community, in which an "OISM SBD" flag is set. | |||
The IMET route for a BD other than the SBD SHOULD carry an EVI-RT EC | The IMET route for a BD other than the SBD SHOULD carry an EVI-RT EC | |||
as defined in [RFC9251]. The EC is constructed from the SBD-RT, to | as defined in [RFC9251]. The EC is constructed from the SBD-RT, to | |||
indicate the BD's corresponding SBD. This allows all PEs to check | indicate the BD's corresponding SBD. This allows all PEs to check | |||
that they have consistent SBD provisioning and allow an AR-replicator | that they have consistent SBD provisioning and allow an AR-replicator | |||
to automatically determine a BD's corresponding SBD w/o any | to automatically determine a BD's corresponding SBD without any | |||
provisioning, as explained in Section 3.2.3.1. | provisioning, as explained in Section 3.2.3.1. | |||
When receiving an IMET, SMET, S-PMSI or Leaf route, it is necessary | When receiving an IMET, SMET, S-PMSI, or Leaf route, it is necessary | |||
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. | |||
When one of the error cases is detected, the route MUST be regarded | When one of the error cases is detected, the route MUST be regarded | |||
as a malformed route, and the "treat-as-withdraw" procedure of | as a malformed route, and the "treat-as-withdraw" procedure of | |||
[RFC7606] MUST be applied. Note though that these error cases are | [RFC7606] MUST be applied. Note that these error cases are | |||
only detectable by EVPN procedures at the receiving PE; BGP | only detectable by EVPN procedures at the receiving PE; BGP | |||
procedures at intermediate nodes will generally not detect the | 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 SHOULD NOT attempt to | |||
do so. | do so. | |||
Case 1: The receiving PE recognizes more than one of the route's RTs | Case 1: The receiving PE recognizes more than one of the route's RTs | |||
as being an SBD-RT (i.e., the route carries SBD-RTs of more | as being an SBD-RT (i.e., the route carries SBD-RTs of more | |||
than one Tenant Domain). | than one Tenant Domain). | |||
This is an error case; the route has not been properly | This is an error case; the route has not been properly | |||
skipping to change at page 20, line 37 ¶ | skipping to change at page 20, line 37 ¶ | |||
associated with the SBD of a different Tenant Domain. | associated with the SBD of a different Tenant Domain. | |||
This is an error case; the route has not been properly | This is an error case; the route has not been properly | |||
constructed. | constructed. | |||
Case 4: The receiving PE does not recognize any of the route's RTs | Case 4: The receiving PE does not recognize any of the route's RTs | |||
as being associated with an ordinary BD in any of its tenant | as being associated with an ordinary BD in any of its tenant | |||
domains, but does recognize one of the RTs as the SBD-RT of | domains, but does recognize one of the RTs as the SBD-RT of | |||
one of its Tenant Domains. | one of its Tenant Domains. | |||
In this case, receiving PE associates the route with the SBD | In this case, the receiving PE associates the route with the SBD | |||
of that Tenant Domain. This association is made even if the | of 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 | Tag ID field of the route's NLRI is not the Tag ID of the | |||
SBD. | SBD. | |||
This is a normal use case where either (a) the route is for | 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 | a BD to which the receiving PE is not attached, or (b) the | |||
route is for the SBD. In either case, the receiving PE | route is for the SBD. In either case, the receiving PE | |||
associates the route with the SBD. | associates the route with the SBD. | |||
Case 5: The receiving PE recognizes exactly one of the RTs as an | Case 5: The receiving PE recognizes exactly one of the RTs as an | |||
skipping to change at page 22, line 5 ¶ | skipping to change at page 22, line 5 ¶ | |||
P2MP tunnels.) At the egress PE, the apparent source BD of the | P2MP tunnels.) At the egress PE, the apparent source BD of the | |||
frame can be inferred from the tunnel encapsulation. If the | frame can be inferred from the tunnel encapsulation. If the | |||
egress PE is not attached to the actual source BD, it will infer | egress PE is not attached to the actual source BD, it will infer | |||
that the apparent source BD is the SBD. | that the apparent source BD is the SBD. | |||
Note that the the inter-PE transmission of a multicast frame | Note that the the inter-PE transmission of a multicast frame | |||
among EVPN-PEs of the same Tenant Domain does NOT involve the IRB | among EVPN-PEs of the same Tenant Domain does NOT involve the IRB | |||
interfaces, as long as the multicast frame was received over an | interfaces, as long as the multicast frame was received over an | |||
AC attached to one of the Tenant Domain's BDs. | AC attached to one of the Tenant Domain's BDs. | |||
2. The frame is also sent up the IRB interface that attaches BD1 to | 2. The frame is also sent on the IRB interface that attaches BD1 to | |||
the Tenant Domain's L3 routing instance in this PE. That is, the | the Tenant Domain's L3 routing instance in this PE. That is, the | |||
L3 routing instance, behaving as if it were a multicast router, | L3 routing instance, behaving as if it were a multicast router, | |||
receives the IP multicast frames that arrive at the PE from its | receives the IP multicast frames that arrive at the PE from its | |||
local ACs. The L3 routing instance decapsulates the frame's | local ACs. The L3 routing instance decapsulates the frame's | |||
payload to extract the IP multicast packet, decrements the IP | payload to extract the IP multicast packet, decrements the IP | |||
TTL, adjusts the header checksum, and does any other necessary IP | TTL, adjusts the header checksum, and does any other necessary IP | |||
processing (e.g., fragmentation). | processing (e.g., fragmentation). | |||
3. The L3 routing instance keeps track of which BDs have local | 3. 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, | |||
skipping to change at page 25, line 21 ¶ | skipping to change at page 25, line 21 ¶ | |||
these "IP Multicast Tunnels". | these "IP Multicast Tunnels". | |||
When the tunneling is done via Ingress Replication or via BIER, this | When the tunneling is done via Ingress Replication 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. | |||
Other things being equal, it is desirable for an ingress PE to | Other things being equal, 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 join | 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 BD1 an | 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), then PE2 | 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) frame. PE2 | must join the P2MP LSP on which PE1 transmits the (S,G) frame. PE2 | |||
must join this P2MP LSP even if PE2 is not attached to the source BD | must join this P2MP LSP even if PE2 is not attached to the source BD | |||
(BD1). If PE1 were transmitting the multicast frame on its BD1 BUM | (BD1). If PE1 were transmitting the multicast frame on its BD1 BUM | |||
tunnel, then PE2 would have to join the BD1 BUM tunnel, even though | tunnel, then PE2 would have to join the BD1 BUM tunnel, even though | |||
PE2 has no BD1 attachment circuits. This would cause PE2 to pull all | PE2 has no BD1 attachment circuits. This would cause PE2 to receive all | |||
the BUM traffic from BD1, most of which it would just have to | the BUM traffic from BD1, most of which it would just have to | |||
discard. Thus we RECOMMEND that the default IP multicast tunnels be | discard. Thus, it is RECOMMENDED that the default IP multicast tunnels be | |||
distinct from the BUM tunnels. | distinct from the BUM tunnels. | |||
Notwithstanding the above, link local IP multicast traffic MUST | Notwithstanding the above, link local IP multicast traffic MUST | |||
always be carried on the BUM tunnels, and ONLY on the BUM tunnels. | always be carried on the BUM tunnels, and ONLY on the BUM tunnels. | |||
Link local IP multicast traffic consists of IPv4 traffic with a | Link local IP multicast traffic consists of IPv4 traffic with a | |||
destination address prefix of 224/8 and IPv6 traffic with a | destination address prefix of 224/8 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 | "IP multicast packet" and "IP multicast frame" are defined in | |||
Section 1.4 so as to exclude the link-local traffic. | Section 1.4 so as to exclude link-local traffic. | |||
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 Section 3.2). When an (S,G) frame is | particular multicast flows (see Section 3.2). When an (S,G) frame is | |||
transmitted on a selective tunnel, it is not transmitted on the BUM | transmitted on a selective tunnel, it is not transmitted on the BUM | |||
tunnel or on the default IP Multicast tunnel. | tunnel or on the default IP Multicast tunnel. | |||
2.7. Advanced Scenarios | 2.7. Advanced Scenarios | |||
There are some deployment scenarios that require special procedures: | There are some deployment scenarios that require special procedures: | |||
skipping to change at page 26, line 14 ¶ | skipping to change at page 26, line 14 ¶ | |||
have one or more gateway PEs that interface the tunnels discussed | have one or more gateway PEs that interface the tunnels discussed | |||
in this document with the BUM tunnels of the legacy PEs. This is | in this document with the BUM tunnels of the legacy PEs. This is | |||
discussed in Section 5. | discussed in Section 5. | |||
2. Sometimes multicast traffic originates from outside the EVPN | 2. 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 Section 6. An important special case of this, | discussed in Section 6. An important special case of this, | |||
integration with MVPN, is discussed in Section 6.1.2. | integration with MVPN, is discussed in Section 6.1.2. | |||
3. In some scenarios, one or more of the tenant systems is a PIM | 3. In some scenarios, one or more of the tenant systems is a PIM | |||
router, and the Tenant Domain is used for 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 | |||
Section 7. | Section 7. | |||
3. EVPN-aware Multicast Solution Control Plane | 3. EVPN-aware Multicast Solution Control Plane | |||
3.1. Supplementary Broadcast Domain (SBD) and Route Targets | 3.1. Supplementary Broadcast Domain (SBD) and Route Targets | |||
As discussed in Section 2.1, every Tenant Domain is associated with a | As discussed in Section 2.1, every Tenant Domain is associated with a | |||
single Supplementary Broadcast Domain (SBD). Recall that a Tenant | single Supplementary Broadcast Domain (SBD). Recall that a Tenant | |||
Domain is defined to be a set of BDs that can freely send and receive | Domain is defined to be a set of BDs that can freely send and receive | |||
skipping to change at page 26, line 38 ¶ | skipping to change at page 26, line 38 ¶ | |||
provisioned with the SBD of that Tenant Domain. | provisioned with the SBD of that Tenant Domain. | |||
At each EVPN-PE attached to a given Tenant Domain, there is an IRB | At each EVPN-PE attached to a given Tenant Domain, there is an IRB | |||
interface leading from the L3 routing instance of that Tenant Domain | interface leading from the L3 routing instance of that Tenant Domain | |||
to the SBD. However, the SBD has no ACs. | to the SBD. However, the SBD has no ACs. | |||
Each SBD is provisioned with a Route Target (RT). All the EVPN-PEs | Each SBD is provisioned with a Route Target (RT). All the EVPN-PEs | |||
supporting a given SBD are provisioned with that RT as an import RT. | supporting a given SBD are provisioned with that RT as an import RT. | |||
That RT MUST NOT be the same as the RT associated with any other BD. | That RT MUST NOT be the same as the RT associated with any other BD. | |||
We will use the term "SBD-RT" to denote the RT has has been assigned | We will use the term "SBD-RT" to denote that the RT has has been assigned | |||
to the SBD. Routes carrying this RT will be propagated to all | to the SBD. Routes carrying this RT will be propagated to all | |||
EVPN-PEs in the same Tenant Domain as the originator. | EVPN-PEs in the same Tenant Domain as the originator. | |||
Section 2.2 specifies the rules by which an EVPN-PE that receives a | Section 2.2 specifies the rules by which an EVPN-PE that receives a | |||
route determines whether a received route "belongs to" a particular | route determines whether a received route "belongs to" a particular | |||
ordinary BD or SBD. | ordinary BD or SBD. | |||
Section 2.2 also specifies additional rules that must be following | Section 2.2 also specifies additional rules that must be followed | |||
when constructing routes that belong to a particular BD, including | when constructing routes that belong to a particular BD, including | |||
the SBD. | the SBD. | |||
The SBD SHOULD be in an EVPN Instance (EVI) of its own. Even if the | The SBD SHOULD be in an EVPN Instance (EVI) of its own. Even if the | |||
SBD is not in an EVI of its own, the SBD-RT MUST be different than | SBD is not in an EVI of its own, the SBD-RT MUST be different than | |||
the RT associated with any other BD. This restriction is necessary | the RT associated with any other BD. This restriction is necessary | |||
in order for the rules of Sections 2.2 and 3.1 to work correctly. | in order for the rules of Sections 2.2 and 3.1 to work correctly. | |||
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-PE with a MAC-VRF. Per [RFC7432], each MAC-VRF is associated | EVPN-PE with a MAC-VRF. Per [RFC7432], each MAC-VRF is associated | |||
skipping to change at page 27, line 44 ¶ | skipping to change at page 27, line 44 ¶ | |||
If AR is used, the ingress EVPN-PE is also an AR-LEAF and the IMET | If AR is used, the ingress EVPN-PE is also an AR-LEAF and the IMET | |||
route coming from the selected AR-REPLICATOR contains the information | route coming from the selected AR-REPLICATOR contains the information | |||
needed. The AR-REPLICATOR will behave as an ingress EVPN-PE when | needed. The AR-REPLICATOR will behave as an ingress EVPN-PE when | |||
sending a flow to the egress EVPN-PEs. | sending a flow to the egress EVPN-PEs. | |||
If the tunneling technique requires P2MP tunnels to be set up (e.g., | If the tunneling technique requires P2MP tunnels to be set up (e.g., | |||
RSVP-TE P2MP, mLDP, PIM), some of the tunnels may be selective | RSVP-TE P2MP, mLDP, PIM), some of the tunnels may be selective | |||
tunnels and some may be inclusive tunnels. | tunnels and some may be inclusive tunnels. | |||
Selective P2MP tunnels are always advertised by the ingress PE using | Selective P2MP tunnels are always advertised by the ingress PE using | |||
S-PMSI A-D routes ([I-D.ietf-bess-evpn-bum-procedure-updates]). | S-PMSI A-D routes [I-D.ietf-bess-evpn-bum-procedure-updates]. | |||
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" [RFC7432] as the default inclusive tunnel for | ordinary "BUM tunnel" [RFC7432] as the default inclusive tunnel for | |||
carrying IP multicast traffic, or using a separate IP multicast | carrying IP multicast traffic, or using a separate IP multicast | |||
tunnel as the default inclusive tunnel for carrying IP multicast. In | tunnel as the default inclusive tunnel for carrying IP multicast. In | |||
the former case, the inclusive tunnel is advertised in an IMET route. | the former case, the inclusive tunnel is advertised in an IMET route. | |||
In the latter case, the inclusive tunnel is advertised in a (C-*,C-*) | In the latter case, the inclusive tunnel is advertised in a (C-*,C-*) | |||
S-PMSI A-D route ([I-D.ietf-bess-evpn-bum-procedure-updates]). | S-PMSI A-D route [I-D.ietf-bess-evpn-bum-procedure-updates]. | |||
Details may be found in subsequent sections. | Details may be found in subsequent sections. | |||
3.2.1. Constructing Routes for the SBD | 3.2.1. Constructing Routes for the SBD | |||
There are situations in which an EVPN-PE needs to originate IMET, | There are situations in which an EVPN-PE needs to originate IMET, | |||
SMET, and/or SPMSI routes for the SBD. Throughout this document, we | SMET, and/or SPMSI routes for the SBD. Throughout this document, we | |||
will refer to such routes respectively as "SBD-IMET routes", | will refer to such routes respectively as "SBD-IMET routes", | |||
"SBD-SMET routes", and "SBD-SPMSI routes". Subsequent sections | "SBD-SMET routes", and "SBD-SPMSI routes". Subsequent sections | |||
detail the conditions under which these routes need to be originated. | detail the conditions under which these routes need to be originated. | |||
skipping to change at page 30, line 13 ¶ | skipping to change at page 30, line 13 ¶ | |||
either the source BD or the SBD. | either the source BD or the SBD. | |||
If an ingress AR-LEAF for a given BD has not received any IMET route | If an ingress AR-LEAF for a given BD has not received any IMET route | |||
for that BD from an AR-REPLICATOR, the ingress AR-LEAF follows the | for that BD from an AR-REPLICATOR, the ingress AR-LEAF follows the | |||
procedures in Section 3.2.2. | procedures in Section 3.2.2. | |||
3.2.3.1. Automatic SBD Matching | 3.2.3.1. Automatic SBD Matching | |||
Each PE needs to know a BD's corresponding SBD. Configuring that | Each PE needs to know a BD's corresponding SBD. Configuring that | |||
information in each BD is one way but it requires repetitive | information in each BD is one way but it requires repetitive | |||
configuration and consistency check (to make sure that all the BDs of | configuration and consistency checking (to make sure that all the BDs of | |||
the same tenant are configured with the same SBD). A better way is | the same tenant are configured with the same SBD). A better way is | |||
to configure the SBD info in the L3 routing instance so that all | to 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. | |||
An AR-replicator also needs to know same information, though it does | An AR-replicator also needs to know same information, though it does | |||
not necessarily have an L3 routing instance. However from the EVI-RT | not necessarily have an L3 routing instance. However from the EVI-RT | |||
EC in a BD's IMET route, an AR-replicator can derive the | EC in a BD's IMET route, an AR-replicator can derive the | |||
corresponding SBD of that BD w/o any configuration. | corresponding SBD of that BD without any configuration. | |||
3.2.4. BIER | 3.2.4. BIER | |||
When BIER is used to transport multicast packets of a given Tenant | When BIER is used to transport multicast packets of a given Tenant | |||
Domain, and a given EVPN-PE attached to that Tenant Domain is a | Domain, and a given EVPN-PE attached to that Tenant Domain is a | |||
possible ingress EVPN-PE for traffic originating outside that Tenant | possible ingress EVPN-PE for traffic originating outside that Tenant | |||
Domain, the given EVPN-PE MUST originate an SBD-IMET route, (see | Domain, the given EVPN-PE MUST originate an SBD-IMET route, (see | |||
Section 3.2.1). | Section 3.2.1). | |||
In addition, IMET routes that are originated for other BDs in the | In addition, IMET routes that are originated for other BDs in the | |||
skipping to change at page 30, line 44 ¶ | skipping to change at page 30, line 44 ¶ | |||
Each IMET route (including but not limited to the SBD-IMET route) | Each IMET route (including but not limited to the SBD-IMET route) | |||
MUST carry a PMSI Tunnel attribute (PTA). The MPLS label field of | MUST carry a PMSI Tunnel attribute (PTA). The MPLS label field of | |||
the PTA MUST specify an upstream-assigned MPLS label that maps | the PTA MUST specify an upstream-assigned MPLS label that maps | |||
uniquely (in the context of the originating EVPN-PE) to the BD for | uniquely (in the context of the originating EVPN-PE) to the BD for | |||
which the route is originated. | which the route is originated. | |||
Suppose an ingress EVPN-PE, PE1, needs to use BIER to tunnel an IP | Suppose an ingress EVPN-PE, PE1, needs to use BIER to tunnel an IP | |||
multicast frame to a set of egress EVPN-PEs. And suppose the frame's | multicast frame to a set of egress EVPN-PEs. And suppose the frame's | |||
source BD is BD1. The frame is encapsulated as follows: | source BD is BD1. The frame is encapsulated as follows: | |||
o A four-octet MPLS label stack entry ([RFC3032]) is prepended to | o A four-octet MPLS label stack entry [RFC3032] is prepended to | |||
the frame. The Label field is set to the upstream-assigned label | the frame. The Label field is set to the upstream-assigned label | |||
that PE1 has assigned to BD1. | that PE1 has assigned to BD1. | |||
o The resulting MPLS packet is then encapsulated in a BIER | o The resulting MPLS packet is then encapsulated in a BIER | |||
encapsulation ([RFC8296], [I-D.ietf-bier-evpn]). The BIER | encapsulation ([RFC8296], [I-D.ietf-bier-evpn]). The BIER | |||
BitString is set to identify the egress EVPN-PEs. The BIER | BitString is set to identify the egress EVPN-PEs. The BIER | |||
"proto" field is set to the value for "MPLS packet with | "proto" field is set to the value for "MPLS packet with | |||
upstream-assigned label at top of stack". | upstream-assigned label at top of stack". | |||
Note: It is possible that the packet being tunneled from PE1 | Note: It is possible that the packet being tunneled from PE1 | |||
skipping to change at page 34, line 48 ¶ | skipping to change at page 34, line 48 ¶ | |||
3.3. Advertising SMET Routes | 3.3. Advertising SMET Routes | |||
[RFC9251] allows an egress EVPN-PE to express its interest in a | [RFC9251] allows an egress EVPN-PE to express its interest in a | |||
particular multicast flow or set of flows by originating an SMET | particular multicast flow or set of flows by originating an SMET | |||
route. The NLRI of the SMET route identifies the flow or set of | route. The NLRI of the SMET route identifies the flow or set of | |||
flows as (C-*,C-*) or (C-*,C-G) or (C-S,C-G). | flows as (C-*,C-*) or (C-*,C-G) or (C-S,C-G). | |||
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 that that BD. From this <RT, tag> pair, other EVPN-PEs | associated with that BD. From this <RT, tag> pair, other EVPN-PEs | |||
can identify the BD to which a received SMET route belongs. | can identify the BD to which a received SMET route belongs. | |||
(Remember though that the route may be carrying multiple RTs.) | (Remember though that the route may be carrying multiple RTs.) | |||
There are three cases to consider: | There are three cases to consider: | |||
o Case 1: It is known that no BD of a Tenant Domain contains a | o Case 1: It is known that no BD of a Tenant Domain contains a | |||
multicast router. | multicast router. | |||
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 SBD. | set of flows by originating an SMET route that belongs to the SBD. | |||
We refer to this as an SBD-SMET route. The SBD-SMET route carries | We refer to this as an SBD-SMET route. The SBD-SMET route carries | |||
the SBD-RT, and has the Tag ID for the SBD in its NLRI. SMET | the SBD-RT, and has the Tag ID for the SBD in its NLRI. SMET | |||
routes for the individual BDs are not needed, because there is no | routes for the individual BDs are not needed, because there is no | |||
need for a PE that receives an SMET route to send a corresponding | need for a PE that receives an SMET route to send a corresponding | |||
IGMP Join message out any of its ACs. | IGMP Join message on any of its ACs. | |||
o Case 2: It is known that more than one BD of a Tenant Domain may | o Case 2: It is known that more than one BD of a Tenant Domain may | |||
contain a multicast router. | contain a multicast router. | |||
This is very like Case 1. An egress PE advertises its interest in | This is very like Case 1. An egress PE advertises its interest in | |||
a flow or set of flows by originating an SBD-SMET route. The | a flow or set of flows by originating an SBD-SMET route. The | |||
SBD-SMET route carries the SBD-RT, and has the Tag ID for the SBD | SBD-SMET route carries the SBD-RT, and has the Tag ID for the SBD | |||
in its NLRI. | in its NLRI. | |||
In this case, it is important to be sure that SMET routes for the | In this case, it is important to be sure that SMET routes for the | |||
individual BDs are not originated. Suppose, for example, that PE1 | individual BDs are not originated. Suppose, for example, that PE1 | |||
had local receivers for a given flow on both BD1 and BD2, and that | had local receivers for a given flow on both BD1 and BD2, and that | |||
it originated SMET routes for both those BDs. Then PEs receiving | it originated SMET routes for both those BDs. Then PEs receiving | |||
those SMET routes might send IGMP Joins on both those BDs. This | those SMET routes might send IGMP Joins on both those BDs. This | |||
could cause externally sourced multicast traffic to enter the | could cause externally sourced multicast traffic to enter the | |||
Tenant Domain at both BDs, which could result in duplication of | Tenant Domain at both BDs, which could result in duplication of | |||
data. | data. | |||
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 in order to receive multicast data | multicast router, then in order to receive multicast data | |||
originating from outside EVPN, the PEs MUST follow the procedures | originating from outside EVPN, the PEs MUST follow the procedures | |||
of Section 6. | of Section 6. | |||
o Case 3: It is known that only a single BD of a Tenant Domain | o Case 3: It is known that only a single BD of a Tenant Domain | |||
contains a multicast router. | contains a multicast router. | |||
Suppose that an egress PE is attached to a BD on which there might | Suppose that an egress PE is attached to a BD on which there might | |||
be a tenant multicast router. (The tenant router is not | 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 which | suppose that the PE has one or more ACs attached to that BD which | |||
are interested in a given multicast flow. In this case, IN | are interested in a given multicast flow. In this case, in | |||
ADDITION to the SMET route for the SBD, the egress PE MAY | addition to the SMET route for the SBD, the egress PE MAY | |||
originate an SMET route for that BD. This will enable the ingress | originate an SMET route for that BD. This will enable the ingress | |||
PE(s) to send IGMP/MLD messages on ACs for the BD, as specified in | PE(s) to send IGMP/MLD messages on ACs for the BD, as specified in | |||
[RFC9251]. As long as that is the only BD on which there is a | [RFC9251]. As long as that is the only BD on which there is a | |||
tenant multicast router, there is no possibility of duplication of | tenant multicast router, there is no possibility of duplication of | |||
data. | data. | |||
This document does not specify procedures for dynamically determining | This document does not specify procedures for dynamically determining | |||
which of the three cases applies to a given deployment; the PEs of a | which of the three cases applies to a given deployment; the PEs of a | |||
given Tenant Domain MUST be provisioned to know which case applies. | given Tenant Domain MUST be provisioned to know which case applies. | |||
As detailed in [RFC9251], an SMET route carries a Multicast Flags EC | As detailed in [RFC9251], an SMET route carries a Multicast Flags EC | |||
containing flags indicating whether it is to result in the | containing flags indicating whether IGMP v1, v2, or v3 messages on | |||
propagation of IGMP v1, v2, or v3 messages on the ACs of the BD to | the ACs of the BD to which the SMET route belongs are propagated. | |||
which the SMET route belongs. These flags SHOULD be set to zero in | These flags SHOULD be set to zero in an SBD-SMET route. | |||
an SBD-SMET route. | ||||
Note that a PE only needs to originate the set of SBD-SMET routes | Note that a PE only needs to originate the set of SBD-SMET routes | |||
that are needed to pull in all the traffic in which it is interested. | that are needed to receive multicast traffic in which it is interested. | |||
Suppose PE1 has ACs attached to BD1 that are interested in (C-*,C-G) | Suppose PE1 has ACs attached to BD1 that are interested in (C-*,C-G) | |||
traffic, and ACs attached to BD2 that are interested in (C-S,C-G) | traffic, and ACs attached to BD2 that are interested in (C-S,C-G) | |||
traffic. A single SBD-SMET route specifying (C-*,C-G) will pull in | traffic. A single SBD-SMET route specifying (C-*,C-G) will attract | |||
all the necessary flows. | all the necessary flows. | |||
As another example, suppose the ACs attached to BD1 are interested in | As another example, suppose the ACs attached to BD1 are interested in | |||
(C-*,C-G) but not in (C-S,C-G), while the ACs attached to BD2 are | (C-*,C-G) but not in (C-S,C-G), while the ACs attached to BD2 are | |||
interested in (C-S,C-G). A single SBD-SMET route specifying | interested in (C-S,C-G). A single SBD-SMET route specifying | |||
(C-*,C-G) will pull in all the necessary flows. | (C-*,C-G) will attract all the necessary flows. | |||
In other words, to determine the set of SBD-SMET routes that have to | In other words, to determine the set of SBD-SMET routes that have to | |||
be sent for a given C-G, the PE has to merge the IGMP/MLD state for | 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 it is attached. | all the BDs (of the given Tenant Domain) to which it is attached. | |||
Per [RFC9251], importing an SMET route for a particular BD will cause | Per [RFC9251], importing an SMET route for a particular BD will cause | |||
IGMP/MLD state to be instantiated for the IRB interface to that BD. | IGMP/MLD state to be instantiated for the IRB interface to that BD. | |||
This applies as well when the BD is the SBD. | This applies as well when the BD is the SBD. | |||
However, traffic that originates in one of the actual BDs of a | However, traffic that originates in one of the actual BDs of a | |||
skipping to change at page 37, line 10 ¶ | skipping to change at page 37, line 10 ¶ | |||
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) multicast | anycast IP address, say S1, and each may transmit an (S1,G) multicast | |||
flow. In such a scenario, the two (S1,G) flows are typically | flow. In such a scenario, the two (S1,G) flows are typically | |||
identical. Ordinary PIM procedures will cause only one the flows to | identical. Ordinary PIM procedures will cause only one the flows to | |||
be delivered to each receiver that has expressed interest in either | be delivered to each receiver that has expressed interest in either | |||
(*,G) or (S1,G). However, the OISM procedures described in this | (*,G) or (S1,G). However, the OISM procedures described in this | |||
document will result in both of the (S1,G) flows being distributed in | document will result in both of the (S1,G) flows being distributed in | |||
the Tenant Domain, and duplicate delivery will result. Therefore, if | the Tenant Domain, and duplicate delivery will result. Therefore, if | |||
there are receivers for (*,G) in a given Tenant Domain, there MUST | there are receivers for (*,G) in a given Tenant Domain, there MUST | |||
NOT be anycast sources for G within that Tenant Domain. (This | NOT be anycast sources for G within that Tenant Domain. (This | |||
restriction can be lifted by defining additional procedures; however | restriction could be lifted by defining additional procedures; however | |||
that is outside the scope of this document.) | that is outside the scope of this document.) | |||
4. Constructing Multicast Forwarding State | 4. Constructing Multicast Forwarding State | |||
4.1. Layer 2 Multicast State | 4.1. Layer 2 Multicast State | |||
An EVPN-PE maintains "layer 2 multicast state" for each BD to which | An EVPN-PE maintains "layer 2 multicast state" for each BD to which | |||
it is attached. | it is attached. | |||
Let PE1 be an EVPN-PE, and BD1 be a BD to which it is attached. At | Let PE1 be an EVPN-PE, and BD1 be a BD to which it is attached. At | |||
skipping to change at page 37, line 44 ¶ | skipping to change at page 37, line 44 ¶ | |||
o The packet is received from BD1's IRB interface (i.e., has been | o The packet is received from BD1's IRB interface (i.e., has been | |||
transmitted by PE1's L3 routing instance down BD1's IRB | transmitted by PE1's L3 routing instance down BD1's IRB | |||
interface). | interface). | |||
According to the procedures of this document, all transmission of IP | According to the procedures of this document, all transmission of IP | |||
multicast packets from one EVPN-PE to another is done at layer 2. | multicast packets from one EVPN-PE to another is done at layer 2. | |||
That is, the packets are transmitted as ethernet frames, according to | That is, the packets are transmitted as ethernet frames, according to | |||
the layer 2 multicast state. | the layer 2 multicast state. | |||
Each layer 2 multicast state (S,G) or (*,G) contains a set "output | Each layer 2 multicast state (S,G) or (*,G) contains a set of "output | |||
interfaces" (OIF list). The disposition of an (S,G) multicast frame | interfaces" (OIF list). The disposition of an (S,G) multicast frame | |||
received by BD1's layer 2 multicast function is determined as | received by BD1's layer 2 multicast function is determined as | |||
follows: | follows: | |||
o The OIF list is taken from BD1's layer 2 (S,G) state, or if there | o 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. (If neither | is no such (S,G) state, then from BD1's (*,G) state. (If neither | |||
state exists, the OIF list is considered to be null.) | state exists, the OIF list is considered to be null.) | |||
o The rules of Section 4.1.2 are applied to the OIF list. This will | o The rules of Section 4.1.2 are applied to the OIF list. This will | |||
generally result in the frame being transmitted to some, but not | generally result in the frame being transmitted to some, but not | |||
all, elements of the OIF list. | all, elements of the OIF list. | |||
Note that there is no RPF check at layer 2. | Note that there is no RPF check at layer 2. | |||
4.1.1. Constructing the OIF List | 4.1.1. Constructing the OIF List | |||
In this document, we have extended the procedures of [RFC9251] so | In this document, we have extended the procedures of [RFC9251] so | |||
that IMET and SMET routes for a particular BD are distributed not | 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 | just to PEs that attach to that BD, but to PEs that attach to any BD | |||
in the Tenant Domain. In this way, each PE attached to a given | in the Tenant Domain. In this way, each PE attached to a given | |||
Tenant Domain learns, from each other PE attached to the same Tenant | Tenant Domain learns, from other PEs attached to the same Tenant | |||
Domain, the set of flows that are of interest to each of those other | Domain, the set of flows that are of interest to each of those other | |||
PEs. (If some PE attached to the Tenant Domain does not support | PEs. (If some PE attached to the Tenant Domain does not support | |||
[RFC9251], it will be assumed to be interested in all flows. Whether | [RFC9251], it will be assumed to be interested in all flows. Whether | |||
a particular remote PE supports [RFC9251] is determined by the | a particular remote PE supports [RFC9251] is determined by the | |||
presence of an Extended Community in its IMET route; this is | presence of an Extended Community in its IMET route; this is | |||
specified in [RFC9251].) If a set of remote PEs are interested in a | specified in [RFC9251].) If a set of remote PEs are interested in a | |||
particular flow, the tunnels used to reach those PEs are added to the | particular flow, the tunnels used to reach those PEs are added to the | |||
OIF list of the multicast states corresponding to that flow. | OIF list of the multicast states corresponding to that flow. | |||
An EVPN-PE may run IGMP/MLD procedures on each of its ACs, in order | An EVPN-PE may run IGMP/MLD procedures on each of its ACs, in order | |||
skipping to change at page 38, line 46 ¶ | skipping to change at page 38, line 46 ¶ | |||
The OIF list for each multicast state must also contain the IRB | The OIF list for each multicast state must also contain the IRB | |||
interface for the BD to which the state belongs. | interface for the BD to which the state belongs. | |||
Implementors should note that the OIF list of a multicast state will | Implementors should note that the OIF list of a multicast state will | |||
change from time to time as ACs and/or remote PEs either become | change from time to time as ACs and/or remote PEs either become | |||
interested in, or lose interest in, particular multicast flows. | interested in, or lose interest in, particular multicast flows. | |||
4.1.2. Data Plane: Applying the OIF List to an (S,G) Frame | 4.1.2. Data Plane: Applying the OIF List to an (S,G) Frame | |||
When an (S,G) multicast frame is received by the layer 2 multicast | When an (S,G) multicast frame is received by the layer 2 multicast | |||
function of a given EVPN-PE, say PE1, its disposition depends (a) the | function of a given EVPN-PE, say PE1, its disposition depends (a) on the | |||
way it was received, (b) upon the OIF list of the corresponding | way it was received, (b) upon the OIF list of the corresponding | |||
multicast state (see Section 4.1.1), (c) upon the "eligibility" of an | multicast state (see Section 4.1.1), (c) upon the "eligibility" of an | |||
AC to receive a given frame (see Section 4.1.2.1 and (d) upon its | AC to receive a given frame (see Section 4.1.2.1) and (d) upon its | |||
apparent source BD (see Section 3.2 for information about determining | apparent source BD (see Section 3.2 for information about determining | |||
the apparent source BD of a frame received over a tunnel from another | the apparent source BD of a frame received over a tunnel from another | |||
PE). | PE). | |||
4.1.2.1. Eligibility of an AC to Receive a Frame | 4.1.2.1. Eligibility of an AC to Receive a Frame | |||
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: | |||
skipping to change at page 39, line 24 ¶ | skipping to change at page 39, line 24 ¶ | |||
2. The ingress PE for the frame is a remote PE, say PE2, local bias | 2. The ingress PE for the frame is a remote PE, say PE2, local bias | |||
is being used, and PE2 is not connected to the same segment as | is being used, and PE2 is not connected to the same segment as | |||
AC1. | AC1. | |||
4.1.2.2. Applying the OIF List | 4.1.2.2. Applying the OIF List | |||
Assume a given (S,G) multicast frame has been received by a given PE, | 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, finds | say PE1. PE1 determines the apparent source BD of the frame, finds | |||
the layer 2 (S,G) state for that BD (or the (*,G) state if there is | the layer 2 (S,G) state for that BD (or the (*,G) state if there is | |||
no (S,G) state), and takes the OIF list from that state. (Note that | no (S,G) state), and uses the OIF list from that state. (Note that | |||
if PE1 is not attached to the actual source BD, the apparent source | if PE1 is not attached to the actual source BD, the apparent source | |||
BD will be the SBD.) | BD will be the SBD.) | |||
Suppose PE1 has determined the frame's apparent source BD to be BD1 | Suppose PE1 has determined the frame's apparent source BD to be BD1 | |||
(which may or may not be the SBD.) There are the following cases to | (which may or may not be the SBD.) There are the following cases to | |||
consider: | consider: | |||
1. The frame was received by PE1 from a local AC, say AC1, that | 1. The frame was received by PE1 from a local AC, say AC1, that | |||
attaches to BD1. | attaches to BD1. | |||
a. The frame MUST be sent out all local ACs of BD1 that appear | a. The frame MUST be sent on all local ACs of BD1 that appear | |||
in the OIF list, except for AC1 itself. | in the OIF list, except for AC1 itself. | |||
b. The frame MUST also be delivered to any other EVPN-PEs that | b. The frame MUST also be delivered to any other EVPN-PEs that | |||
have interest in it. This is achieved as follows: | have interest in it. This is achieved as follows: | |||
i. If (a) AR is being used, and (b) PE1 is an AR-LEAF, and | i. If (a) AR is being used, and (b) PE1 is an AR-LEAF, and | |||
(c) the OIF list is non-null, PE1 MUST send the frame | (c) the OIF list is non-null, PE1 MUST send the frame | |||
to the AR-REPLICATOR. | to the AR-REPLICATOR. | |||
ii. Otherwise the frame MUST be sent on all tunnels in the | ii. Otherwise the frame MUST be sent on all tunnels in the | |||
skipping to change at page 40, line 11 ¶ | skipping to change at page 40, line 11 ¶ | |||
c. The frame MUST be sent to the local L3 routing instance by | c. The frame MUST be sent to the local L3 routing instance by | |||
being sent up the IRB interface of BD1. It MUST NOT be sent | being sent up the IRB interface of BD1. It MUST NOT be sent | |||
up any other IRB interfaces. | up any other IRB interfaces. | |||
2. The frame was received by PE1 over a tunnel from another PE. | 2. The frame was received by PE1 over a tunnel from another PE. | |||
(See Section 3.2 for the rules to determine the apparent source | (See Section 3.2 for the rules to determine the apparent source | |||
BD of a packet received from another PE. Note that if PE1 is not | BD of a packet received from another PE. Note that if PE1 is not | |||
attached to the source BD, it will regard the SBD as the apparent | attached to the source BD, it will regard the SBD as the apparent | |||
source BD.) | source BD.) | |||
a. The frame MUST be sent out all local ACs in the OIF list that | a. The frame MUST be sent on all local ACs in the OIF list that | |||
connect to BD1 and that are eligible (per Section 4.1.2.1) to | connect to BD1 and that are eligible (per Section 4.1.2.1) to | |||
receive the frame. | receive the frame. | |||
b. The frame MUST be sent up the IRB interface of the apparent | b. The frame MUST be sent up the IRB interface of the apparent | |||
source BD. (Note that this may be the SBD.) The frame MUST | source BD. (Note that this may be the SBD.) The frame MUST | |||
NOT be sent up any other IRB interfaces. | NOT be sent up any other IRB interfaces. | |||
c. If PE1 is not an AR-REPLICATOR, it MUST NOT send the frame to | c. If PE1 is not an AR-REPLICATOR, it MUST NOT send the frame to | |||
any other EVPN-PEs. However, if PE1 is an AR-REPLICATOR, it | any other EVPN-PEs. However, if PE1 is an AR-REPLICATOR, it | |||
MUST send the frame to all tunnels in the OIF list, except | MUST send the frame to all tunnels in the OIF list, except | |||
for the tunnel over which the frame was received. | for the tunnel over which the frame was received. | |||
3. The frame was received by PE1 from the BD1 IRB interface (i.e., | 3. The frame was received by PE1 from the BD1 IRB interface (i.e., | |||
the frame has been transmitted by PE1's L3 routing instance down | the frame has been transmitted by PE1's L3 routing instance down | |||
the BD1 IRB interface), and BD1 is NOT the SBD. | the BD1 IRB interface), and BD1 is NOT the SBD. | |||
a. The frame MUST be sent out all local ACs in the OIF list that | a. The frame MUST be sent on all local ACs in the OIF list that | |||
are eligible (per Section 4.1.2.1 to receive the frame. | are eligible, as per Section 4.1.2.1, to receive the frame. | |||
b. The frame MUST NOT be sent to any other EVPN-PEs. | b. The frame MUST NOT be sent to any other EVPN-PEs. | |||
c. The frame MUST NOT be sent up any IRB interfaces. | c. The frame MUST NOT be sent up any IRB interfaces. | |||
4. The frame was received from the SBD IRB interface (i.e., has been | 4. The frame was received from the SBD IRB interface (i.e., has been | |||
transmitted by PE1's L3 routing instance down the SBD IRB | transmitted by PE1's L3 routing instance down the SBD IRB | |||
interface). | interface). | |||
a. The frame MUST be sent on all tunnels in the OIF list. This | a. The frame MUST be sent on all tunnels in the OIF list. This | |||
skipping to change at page 40, line 51 ¶ | skipping to change at page 40, line 51 ¶ | |||
have interest in it. | have interest in it. | |||
b. The frame MUST NOT be sent on any local ACs. | b. The frame MUST NOT be sent on any local ACs. | |||
c. The frame MUST NOT be sent up any IRB interfaces. | c. The frame MUST NOT be sent up any IRB interfaces. | |||
4.2. Layer 3 Forwarding State | 4.2. Layer 3 Forwarding State | |||
If an EVPN-PE is performing IGMP/MLD procedures on the ACs of a given | 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 layer 2 | BD, it processes those messages at layer 2 to help form the layer 2 | |||
multicast state. If also sends those messages up that BD's IRB | multicast state. It also sends those messages up that BD's IRB | |||
interface to the L3 routing instance of a particular tenant domain. | interface to the L3 routing instance of a particular tenant domain. | |||
This causes layer 2 (C-S,C-G) or (C-*,C-G) L3 state to be created/ | This causes layer 2 (C-S,C-G) or (C-*,C-G) L3 state to be created/ | |||
updated. | updated. | |||
A layer 3 multicast state has both an Input Interface (IIF) and an | A flow's layer 3 multicast state has both an Input Interface (IIF) and an | |||
OIF list. | OIF list. | |||
To set the IIF of an (C-S,C-G) state, the EVPN-PE must determine the | To set the IIF of a (C-S,C-G) state, the EVPN-PE must determine the | |||
source BD of C-S. This is done by looking up S in the local | source BD of C-S. This is done by looking up S in the local | |||
MAC-VRF(s) of the given Tenant Domain. | MAC-VRF(s) of the given Tenant Domain. | |||
If the source BD is present on the PE, the IIF is set to the IRB | If the source BD is present on the PE, 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. | |||
For (C-*,C-G) states, traffic can arrive from any BD, so the IIF | 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 interface". | needs to be set to a wildcard value meaning "any IRB interface". | |||
skipping to change at page 42, line 20 ¶ | skipping to change at page 42, line 20 ¶ | |||
o BD-R: a BD that contains a host interested in the flow. The host | o BD-R: 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. | is attached to PE-R via an AC that belongs to BD-R. | |||
To allow OISM PEs to interwork with non-OISM PEs, a given Tenant | To allow OISM PEs to interwork with non-OISM PEs, a given Tenant | |||
Domain needs to contain one or more "IP Multicast Gateways" (IPMGs). | Domain needs to contain one or more "IP Multicast Gateways" (IPMGs). | |||
An IPMG is an OISM PE with special responsibilities regarding the | An IPMG is an OISM PE with special responsibilities regarding the | |||
interworking between OISM and non-OISM PEs. | interworking between OISM and non-OISM PEs. | |||
If a PE is functioning as an IPMG, it MUST signal this fact by | If a PE is functioning as an IPMG, it MUST signal this fact by | |||
setting the "IPMG" flag in the Multicast Flags EC that it attaches to | setting the "IPMG" flag in the Multicast Flags EC that it attaches to | |||
its IMET routes. An IPMG SHOULD attach this EC with the IPMG flag | its IMET routes. An IPMG SHOULD attach this EC, with the IPMG flag | |||
set to all IMET routes it originates. However, if PE1 imports any | set, to all IMET routes it originates. Furthermore, if PE1 imports any | |||
IMET route from PE2 that has the EC present with the "IPMG" flag set, | IMET route from PE2 that has the EC present with the "IPMG" flag set, | |||
then the PE1 will assume that PE2 is an IPMG. | then the PE1 will assume that PE2 is an IPMG. | |||
An IPMG Designated Forwarder (IPMG-DF) selection procedure is used to | An IPMG Designated Forwarder (IPMG-DF) selection procedure is used to | |||
ensure that, at any given time, there is exactly one active IPMG-DF | ensure that, at any given time, there is exactly one active IPMG-DF | |||
for any given BD. Details of the IPMG-DF selection procedure are in | for any given BD. Details of the IPMG-DF selection procedure are in | |||
Section 5.1. The IPMG-DF for a given BD, say BD-S, has special | Section 5.1. The IPMG-DF for a given BD, say BD-S, has special | |||
functions to perform when it receives (S,G) frames on that BD: | functions to perform when it receives (S,G) frames on that BD: | |||
o If the frames are from a non-OISM PE-S: | o If the frames are from a non-OISM PE-S: | |||
* The IPMG-DF forwards them to OISM PEs that do not attach to | * The IPMG-DF forwards them to OISM PEs that do not attach to | |||
BD-S but have interest in (S,G). | BD-S but have interest in (S,G). | |||
Note that OISM PEs that do attach to BD-S will have received | 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. | the frames on the BUM tunnel from the non-OISM PE-S. | |||
* The IPMG-DF forwards them to non-OISM PEs that have interest in | * The IPMG-DF forwards them to non-OISM PEs that have interest in | |||
(S,G) on ACs that do not belong to BD-S. | (S,G) on ACs that do not belong to BD-S. | |||
Note that if a non-OISM PE has multiple BDs other than BD-S | 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 | with interest in (S,G), it will receive one copy of the frame | |||
for each such BD. This is necessary because the non-OISM PEs | for each such BD. This is necessary because the non-OISM PEs | |||
cannot move IP multicast traffic from one BD to another. | cannot move IP multicast traffic from one BD to another. | |||
o If the frames are from an OISM PE, the IPMG-DF forwards them to | o 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 | non-OISM PEs that have interest in (S,G) on ACs that do not belong | |||
to BD-S. | to BD-S. | |||
If a non-OISM PE has interest in (S,G) on an AC belonging to BD-S, | 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 | it will have received a copy of the (S,G) frame, encapsulated for | |||
BD-S, from the OISM PE-S. (See Section 3.2.2.) If the non-OISM | BD-S, from the OISM PE-S. (See Section 3.2.2.) If the non-OISM | |||
PE has interest in (S,G) on one or more ACs belonging to | 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 | 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 BD-Ri. | IPMG-DF needs to send it a copy of the frame for each BD-Ri. | |||
If an IPMG receives a frame on a BD for which it is not the IPMG-DF, | If an IPMG receives a frame on a BD for which it is not the IPMG-DF, | |||
it just follows normal OISM procedures. | it just follows normal OISM procedures. | |||
This section specifies several sets of procedures: | This section specifies several sets of procedures: | |||
o the procedures that the IPMG-DF for a given BD needs to follow | o 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 | when receiving, on that BD, an IP multicast frame from a non-OISM | |||
PE; | PE; | |||
skipping to change at page 44, line 14 ¶ | skipping to change at page 44, line 14 ¶ | |||
5.1. IPMG Designated Forwarder | 5.1. IPMG Designated Forwarder | |||
Every PE that is eligible for selection as an IPMG-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-IMET route. As stated in Section 5, these SBD-IMET routes carry | SBD-IMET route. As stated in Section 5, these SBD-IMET routes carry | |||
a Multicast Flags EC with the IPMG Flag set. | a Multicast Flags EC with the IPMG Flag set. | |||
These SBD-IMET routes SHOULD also carry a DF Election EC. The DF | These SBD-IMET routes SHOULD also carry a DF Election EC. The DF | |||
Election EC and its use is specified in ([RFC8584]). When the route | Election EC and its use is specified in ([RFC8584]). When the route | |||
is originated, the AC-DF bit in the DF Election EC SHOULD be set to | is originated, the AC-DF bit in the DF Election EC SHOULD be not be | |||
zero. This bit is not used when selecting an IPMSG-DF, i.e., it MUST | set. This bit is not used when selecting an IPMSG-DF, i.e., it MUST | |||
be ignored by the receiver of an SBD-IMET route. | be ignored by the receiver of an SBD-IMET route. | |||
In the context of a given Tenant Domain, to select the IPMG-DF for a | In the context of a given Tenant Domain, to select the IPMG-DF for a | |||
particular BD, say BD1, the IPMGs of the Tenant Domain perform the | particular BD, say BD1, the IPMGs of the Tenant Domain perform the | |||
following procedure: | following procedure: | |||
o From the set of received SBD-IMET routes for the given tenant | o From the set of received SBD-IMET routes for the given tenant | |||
domain, determine the candidate set of PEs that support IPMG | domain, determine the candidate set of PEs that support IPMG | |||
functionality for that domain. | functionality for that domain. | |||
skipping to change at page 47, line 38 ¶ | skipping to change at page 47, line 38 ¶ | |||
o PE-S will send a copy of the frame to every OISM PE-R (including | o 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 | 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 | interest in (S,G). The copy sent to a given PE-R carries the | |||
label that that the PE-R has assigned to BD-S in its (C-*,C-*) | label that that the PE-R has assigned to BD-S in its (C-*,C-*) | |||
S-PMSI A-D route. | S-PMSI A-D route. | |||
o PE-S will also transmit a copy of the (S,G) frame to every OISM | o 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 | 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. | copy will contain the label that the PE-R has assigned to the SBD. | |||
(As in Section 5.2.1, an IPMG is assumed to have indicated | (As specified in Section 5.2.1, an IPMG is assumed to have indicated | |||
interest in all multicast flows.) | interest in all multicast flows.) | |||
o PE-S will also transmit a copy of the (S,G) frame to every | o 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 | 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. | label advertised by that PE-R in its IMET route for BD-S. | |||
The PE-Rs follow their normal procedures. An OISM PE that receives | The PE-Rs follow their normal procedures. An OISM PE that receives | |||
the (S,G) frame on BD-S applies the OISM procedures to deliver the | the (S,G) frame on BD-S applies the OISM procedures to deliver the | |||
frame to its local ACs, as necessary. A non-OISM PE that receives | frame to its local ACs, as necessary. A non-OISM PE that receives | |||
the (S,G) frame on BD-S delivers the frame only to its local BD-S | the (S,G) frame on BD-S delivers the frame only to its local BD-S | |||
ACs, as necessary. | ACs, as necessary. | |||
Suppose that a non-OISM PE-R has interest in (S,G) on a BD, BD-R, | Suppose that a non-OISM PE-R has interest in (S,G) on a BD, BD-R, | |||
that is different than BD-S. If the non-OISM PE-R is attached to | that is different than BD-S. If the non-OISM PE-R is attached to | |||
BD-S, the OISM PE-S will send forward it the original (S,G) multicast | BD-S, the OISM PE-S will send it the original (S,G) multicast | |||
frame, but the non-OISM PE-R will not be able to send the frame to | frame, but the non-OISM PE-R will not be able to send the frame to | |||
ACs that are not in BD-S. If PE-R is not even attached to BD-S, the | ACs that are not in BD-S. If PE-R is not even attached to BD-S, the | |||
OISM PE-S will not send it a copy of the frame at all, because PE-R | OISM PE-S will not send it a copy of the frame at all, because PE-R | |||
is not attached to the SBD. In these cases, the IPMG needs to relay | is not attached to the SBD. In these cases, the IPMG needs to relay | |||
the (S,G) multicast traffic from OISM PE-S to non-OISM PE-R. | the (S,G) multicast traffic from OISM PE-S to non-OISM PE-R. | |||
When the IPMG-DF for BD-S receives an (S,G) frame from an OISM PE-S, | When the IPMG-DF for BD-S receives an (S,G) frame from an OISM PE-S, | |||
it has to forward it to every non-OISM PE-R that that has interest in | it has to forward it to every non-OISM PE-R that that has interest in | |||
(S,G) on a BD-R that is different than BD-S. The IPMG MUST | (S,G) on a BD-R that is different than BD-S. The IPMG MUST | |||
decapsulate the IP multicast packet, do the IP processing, re- | decapsulate the IP multicast packet, do the IP processing, re- | |||
encapsulate it for BD-R (changing the MAC SA to the IPMG's own MAC | encapsulate it for BD-R (changing the MAC SA to the IPMG's own MAC | |||
address on BD-R), and send a copy of the frame to PE-R. Note that a | address for BD-R), and send a copy of the frame to PE-R. Note that a | |||
given non-OISM PE-R will receive multiple copies of the frame, if it | 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. | has multiple BDs on which there is interest in the frame. | |||
5.3. P2MP Tunnels | 5.3. P2MP Tunnels | |||
When IR is used to distribute the multicast traffic among the | When IR is used to distribute the multicast traffic among the | |||
EVPN-PEs, the procedures of Section 5.2 ensure that there will be no | EVPN-PEs, the procedures of Section 5.2 ensure that there will be no | |||
duplicate delivery of multicast traffic. That is, no egress PE will | 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 | ever send a frame twice on any given AC. If P2MP tunnels are being | |||
used to distribute the multicast traffic, it is necessary have | used to distribute the multicast traffic, it is necessary to have | |||
additional procedures to prevent duplicate delivery. | additional procedures to prevent duplicate delivery. | |||
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-OISM nodes that use P2MP | 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, | tunnels. If it is determined that there is such a use case, | |||
procedures for it will be included in a future revision of this | procedures for P2MP will be included in a future revision of this | |||
document. | document. | |||
6. Traffic to/from Outside the EVPN Tenant Domain | 6. Traffic to/from Outside the EVPN Tenant Domain | |||
In this section, we discuss scenarios where a multicast source | In this section, we discuss scenarios where a multicast source | |||
outside a given EVPN Tenant Domain sends traffic to receivers inside | outside a given EVPN Tenant Domain sends traffic to receivers inside | |||
the domain (as well as, possibly, to receivers outside the domain). | the domain (as well as, possibly, to receivers outside the domain). | |||
This requires the OISM procedures to interwork with various layer 3 | This requires the OISM procedures to interwork with various layer 3 | |||
multicast routing procedures. | multicast routing procedures. | |||
skipping to change at page 50, line 14 ¶ | skipping to change at page 50, line 14 ¶ | |||
Section 4.2 discusses the way layer 3 multicast states are | Section 4.2 discusses the way layer 3 multicast states are | |||
constructed by OISM PEs. These layer 3 multicast states have IRB | constructed by OISM PEs. These layer 3 multicast states have IRB | |||
interfaces as their IIF and OIF list entries, and are the basis for | interfaces as their IIF and OIF list entries, and are the basis for | |||
interworking OISM with other layer 3 multicast procedures such as | interworking OISM with other layer 3 multicast procedures such as | |||
MVPN or PIM. From the perspective of the layer 3 multicast | 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. | |||
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 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-IRB interfaces as IIF | the multicast states may have PIM-enabled non-IRB interfaces as IIF | |||
or OIF list members. | or OIF list members. | |||
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. | |||
In general, an L3 Gateway has the following responsibilities: | In general, an L3 Gateway has the following responsibilities: | |||
o It exports, to the external domain, unicast routes to those | o 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. | |||
o It imports, from the external domain, unicast routes to multicast | o It imports, from the external domain, unicast routes to multicast | |||
sources that are in the external domain. | sources that are in the external domain. | |||
o It executes the procedures necessary to draw externally sourced | o It executes the procedures necessary to receive 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. | |||
One of the L3 Gateways in a given Tenant Domain becomes the "DR" for | One of the L3 Gateways in a given Tenant Domain becomes the "DR" for | |||
the SBD. (See Section 6.1.2.4.) This L3 gateway has the following | the SBD.(See Section 6.1.2.4.) This L3 gateway has the following | |||
additional responsibilities: | additional responsibilities: | |||
o It exports, to the external domain, unicast routes to multicast | o It exports, to the external domain, unicast routes to multicast | |||
sources that 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. | |||
o It imports, from the external domain, unicast routes to multicast | o It imports, from the external domain, unicast routes to multicast | |||
sources that are in the external domain. | sources that are in the external domain. | |||
o It executes the procedures necessary to draw externally sourced | o It executes the procedures necessary to receive 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 document | IRB interface. OISM procedures already described in this document | |||
will then ensure that the IP multicast traffic gets distributed | will then ensure that the IP multicast traffic gets distributed | |||
throughout the Tenant Domain to any EVPN PEs that have interest in | throughout the Tenant Domain to any EVPN PEs that have interest in | |||
it. Thus to an OISM PE that is not an L3 gateway the externally | it. Thus to an OISM PE that is not an L3 gateway the externally | |||
sourced traffic will appear to have been sourced on the SBD. | sourced traffic will appear to have been sourced on the SBD. | |||
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. Suppose | gateway creates or modifies a layer 3 (*,G) multicast state. Suppose | |||
group G has both external sources (sources outside the EVPN Tenant | group G has both external sources (sources outside the EVPN Tenant | |||
Domain) and internal sources (sources inside the EVPN tenant domain). | Domain) and internal sources (sources inside the EVPN tenant domain). | |||
Section 4.2 states that when there are internal sources, the SBD IRB | Section 4.2 states that when there are internal sources, the SBD IRB | |||
interface must not be added to the OIF list of the (*,G) state. | interface must not be added to the OIF list of the (*,G) state. | |||
Traffic from internal sources will already have been delivered to all | Traffic from internal sources will already have been delivered to all | |||
the EVPN PEs that have interest in it. However, if the OIF list of | the EVPN PEs that have interest in it. However, if the OIF list of | |||
the (*,G) state does not contain its SBD IRB interface, then traffic | the (*,G) state does not contain its SBD IRB interface, then traffic | |||
from external sources will not get delivered to other EVPN PEs. | from external sources will not get delivered to other EVPN PEs. | |||
One way of handling this is the following. When a 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 from other than an IRB interface, 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. | |||
If a particular BD is attached to several L3 Gateways, one of the L3 | If a particular BD is attached to several L3 Gateways, one of the L3 | |||
Gateways becomes the DR for that BD. (See Section 6.1.2.4.) If the | Gateways becomes the DR for that BD. (See Section 6.1.2.4.) If the | |||
interworking scenario requires FHR functionality, it is generally the | interworking scenario requires FHR functionality, it is generally the | |||
DR for a particular BD that is responsible for performing that | DR for a particular BD that is responsible for performing that | |||
functionality on behalf of the source hosts on that BD. (E.g., if | functionality on behalf of the source hosts on that BD. (E.g., if | |||
the interworking scenario requires that PIM Register messages be sent | the interworking scenario requires that PIM Register messages be sent | |||
by a FHR, the DR for a given BD would send the PIM Register messages | by an FHR, the DR for a given BD would send the PIM Register messages | |||
for sources on that BD.) Note though that the DR for the SBD does | for sources on that BD.) Note though that the DR for the SBD does | |||
not perform FHR functionality on behalf of external sources. | not perform FHR functionality on behalf of external sources. | |||
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. | |||
N.B.: If it is possible that more than one BD contains a tenant | N.B.: If it is possible that more than one BD contains a tenant | |||
skipping to change at page 52, line 45 ¶ | skipping to change at page 52, line 45 ¶ | |||
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. (There may of course | |||
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 Section 7.) | there are tenant multicast routers is deferred till Section 7.) | |||
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, or MEG. | |||
A MEG is an L3 Gateway (see Section 6.1.1), hence is both an OISM PE | A MEG is an L3 Gateway (see Section 6.1.1), hence is both an OISM PE | |||
and an L3VPN/MVPN PE. For a given EVPN Tenant Domain it will have an | and an L3VPN/MVPN PE. For a given EVPN Tenant Domain, it will have an | |||
IP-VRF. If the Tenant Domain is part of an L3VPN/MVPN, the IP-VRF | IP-VRF. If the Tenant Domain is part of an L3VPN/MVPN, the IP-VRF | |||
also serves as an L3VPN VRF ([RFC4364]). The IRB interfaces of the | also serves as an L3VPN VRF ([RFC4364]). The IRB interfaces of the | |||
IP-VRF are considered to be "VRF interfaces" of the L3VPN VRF. The | IP-VRF are considered to be "VRF interfaces" of the L3VPN VRF. The | |||
L3VPN VRF may also have other local VRF interfaces that are not EVPN | L3VPN VRF may also have other local VRF interfaces that are not EVPN | |||
IRB interfaces. | IRB interfaces. | |||
The VRF on the MEG will import VPN-IP routes ([RFC4364]) from other | The VRF on the MEG will import VPN-IP routes ([RFC4364]) from other | |||
L3VPN Provider Edge (PE) routers. It will also export VPN-IP routes | L3VPN Provider Edge (PE) routers. It will also export VPN-IP routes | |||
to other L3VPN PE routers. In order to do so, it must be | to other L3VPN PE routers. In order to do so, it must be | |||
appropriately configured with the Route Targets used in the L3VPN to | appropriately configured with the Route Targets used in the L3VPN to | |||
skipping to change at page 54, line 12 ¶ | skipping to change at page 54, line 12 ¶ | |||
of VPN-IP routes, and with the generation of MVPN C-multicast routes | of VPN-IP routes, and with the generation of MVPN C-multicast routes | |||
triggered by the installation of SMET routes. | triggered by the installation of SMET routes. | |||
6.1.2.1. MVPN Sources with EVPN Receivers | 6.1.2.1. MVPN Sources with EVPN Receivers | |||
6.1.2.1.1. Identifying MVPN Sources | 6.1.2.1.1. Identifying MVPN Sources | |||
Consider a multicast source S. It is possible that a MEG will import | Consider a multicast source S. It is possible that a MEG will import | |||
both an EVPN unicast route to S and a VPN-IP route (or an ordinary IP | 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 the same. In order | route), where the prefix length of each route is the same. In order | |||
to draw (S,G) multicast traffic for any group G, the MEG SHOULD use | to receive (S,G) multicast traffic for any group G, the MEG SHOULD use | |||
the EVPN route rather than the VPN-IP or IP route to determine the | the EVPN route rather than the VPN-IP or IP route to determine the | |||
"Upstream PE" (see section 5 of [RFC6513]). | "Upstream PE" (see section 5 of [RFC6513]). | |||
Doing so ensures that when an EVPN tenant system desires to receive a | Doing so ensures that when an EVPN tenant system desires to receive a | |||
multicast flow from another EVPN tenant system, the traffic from the | multicast flow from another EVPN tenant system, the traffic from the | |||
source to that receiver stays within the EVPN domain. This prevents | source to that receiver stays within the EVPN domain. This prevents | |||
problems that might arise if there is a unicast route via L3VPN to S, | problems that might arise if there is a unicast route via L3VPN to S, | |||
but no multicast routers along the routed path. This also prevents | but no multicast routers along the routed path. This also prevents | |||
problem that might arise as a result of the fact that the MEGs will | problem that might arise as a result of the fact that the MEGs will | |||
import each others' VPN-IP routes. | import each others' VPN-IP routes. | |||
In the Section 6.1.2.1.2, we describe the procedures to be used when | In the Section 6.1.2.1.2, we describe the procedures to be used when | |||
the selected route to S is a VPN-IP route. | the selected route to S is a VPN-IP route. | |||
6.1.2.1.2. Joining a Flow from an MVPN Source | 6.1.2.1.2. Joining a Flow from an MVPN Source | |||
Consider a tenant system, R, on a particular BD, BD-R. Suppose R | Consider a tenant system, R, on a particular BD, BD-R. Suppose 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 an | attached to any PE in the EVPN Tenant Domain, but is attached to an | |||
MVPN PE. | MVPN PE.l | |||
o Suppose R is on a singly homed ethernet segment of BD-R, and that | o 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 learns via | segment is attached to PE1, where PE1 is a MEG. PE1 learns via | |||
IGMP/MLD listening that R is interested in (S,G). PE1 determines | IGMP/MLD listening that R is interested in (S,G). PE1 determines | |||
from its VRF that there is no route to S within the Tenant Domain | from its VRF that there is no route to S within the Tenant Domain | |||
(i.e., no EVPN RT-2 route with S's IP address), but that there is | (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 VRF contains a subnet or host | a route to S via L3VPN (i.e., the VRF contains a subnet or host | |||
route to S that was received as a VPN-IP route). PE1 thus | route to S that was received as a VPN-IP route). PE1 thus | |||
originates (if it hasn't already) an MVPN C-multicast Source Tree | originates (if it hasn't already) an MVPN C-multicast Source Tree | |||
Join(S,G) route. The route is constructed according to normal | Join(S,G) route. The route is constructed according to normal | |||
MVPN procedures. | MVPN procedures. | |||
The layer 2 multicast state is constructed as specified in | The layer 2 multicast state is constructed as specified in | |||
Section 4.1. | Section 4.1. | |||
In the layer 3 multicast state, the IIF is the appropriate MVPN | In the layer 3 multicast state, the IIF is the appropriate MVPN | |||
tunnel, and the IRB interface to BD-R is added to the OIF list. | tunnel, and the IRB interface to BD-R is added to the OIF list. | |||
When PE1 receives (S,G) traffic from the appropriate MVPN tunnel, | When PE1 receives (S,G) traffic from the appropriate MVPN tunnel, | |||
it performs IP processing of the traffic, and then sends the | it performs IP processing of the traffic, and then sends the | |||
traffic down its IRB interface to BD-R. Following normal OISM | traffic down its IRB interface to BD-R. Following normal OISM | |||
procedures, the (S,G) traffic will be encapsulated for ethernet | procedures, the (S,G) traffic will be encapsulated for ethernet | |||
and sent out the AC to which R is attached. | and sent on the AC to which R is attached. | |||
o Suppose R is on a singly homed ethernet segment of BD-R, and that | o 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 but is NOT a | 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 interested in | MEG. PE1 learns via IGMP/MLD listening that R is interested in | |||
(S,G). PE1 follows normal OISM procedures, originating an SBD- | (S,G). PE1 follows normal OISM procedures, originating an SBD- | |||
SMET route for (S,G); this route will be received by all the MEGs | SMET route for (S,G); this route will be received by all the MEGs | |||
of the Tenant Domain, including the MEG SBD-DR. The MEG SBD-DR | of the Tenant Domain, including the MEG SBD-DR. The MEG SBD-DR | |||
can determine from PE1's IMET routes whether PE1 is itself a MEG. | can determine from PE1's IMET routes whether PE1 is itself a MEG. | |||
If PE1 is not a MEG, the MEG SBD-DR will originate (if it hasn't | If PE1 is not a MEG, the MEG SBD-DR will originate (if it hasn't | |||
already) an MVPN C-multicast Source Tree Join(S,G) route. This | already) an MVPN C-multicast Source Tree Join(S,G) route. This | |||
skipping to change at page 55, line 47 ¶ | skipping to change at page 55, line 47 ¶ | |||
its local ACs to BD-R is interested in (S,G) traffic. The DF is | its local ACs to BD-R is interested in (S,G) traffic. The DF is | |||
responsible for originating an SBD-SMET route for (S,G), following | responsible for originating an SBD-SMET route for (S,G), following | |||
normal OISM procedures. If the DF is a MEG, it MUST originate the | normal OISM procedures. If the DF is a MEG, it MUST originate the | |||
corresponding MVPN C-multicast Source Tree Join(S,G) route; if the | corresponding MVPN C-multicast Source Tree Join(S,G) route; if the | |||
DF is not a MEG, the MEG SBD-DR SBD MUST originate the C-multicast | DF is not a MEG, the MEG SBD-DR SBD MUST originate the C-multicast | |||
route when it receives the SMET route. | route when it receives the SMET route. | |||
Optionally, if the non-DF is a MEG, it MAY originate the | Optionally, if the non-DF is a MEG, it MAY originate the | |||
corresponding MVPN C-multicast Source Tree Join(S,G) route. This | corresponding MVPN C-multicast Source Tree Join(S,G) route. This | |||
will cause the traffic to flow to both the DF and the non-DF, but | will cause the traffic to flow to both the DF and the non-DF, but | |||
only the DF will forward the traffic out an AC. This allows for | only the DF will forward the traffic on an AC. This allows for | |||
quicker recovery if the DF's local AC to R fails. | quicker recovery if the DF's local AC to R fails. | |||
o If R is attached to a non-OISM PE, it will receive the traffic via | o If R is attached to a non-OISM PE, it will receive the traffic via | |||
an IPMG, as specified in Section 5. | an IPMG, as specified in Section 5. | |||
If an EVPN-attached receiver is interested in (*,G) traffic, and if | If an EVPN-attached receiver is interested in (*,G) traffic, and if | |||
it is possible for there to be sources of (*,G) traffic that are | 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 group- | attached only to L3VPN nodes, the MEGs will have to know the group- | |||
to-RP mappings. That will enable them to originate MVPN C-multicast | to-RP mappings. That will enable them to originate MVPN C-multicast | |||
Shared Tree Join(*,G) routes and to send them towards the RP. (Since | Shared Tree Join(*,G) routes and to send them towards the RP. (Since | |||
skipping to change at page 58, line 28 ¶ | skipping to change at page 58, line 28 ¶ | |||
If the MEG SBD-DR is to be the FHR for the Tenant Domain, it must see | 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 domain and | all the multicast traffic that is sourced from within the domain and | |||
destined to an ASM group address. The MEG can ensure this by | destined to an ASM group address. The MEG can ensure this by | |||
originating an SBD-SMET route for (*,*). | originating an SBD-SMET route for (*,*). | |||
(As a possible optimization, an SBD-SMET route for (*, "any ASM | (As a possible optimization, an SBD-SMET route for (*, "any ASM | |||
group") may be defined in a future revision of this draft.) | group") may be defined in a future revision of this draft.) | |||
In some deployment scenarios, it may be preferred that the MEG that | In some deployment scenarios, it may be preferred that the MEG that | |||
receives the (S,G) traffic over an AC be the one provides the FHR | receives the (S,G) traffic over an AC be the one providing the FHR | |||
functionality. This behavior is OPTIONAL. If this option is used, | functionality. This behavior is OPTIONAL. If this option is used, | |||
it MUST be ensured that the MEG DR does not provide the FHR | it MUST be ensured that the MEG DR does not provide the FHR | |||
functionality for (S,G) traffic that is attached to another MEG; FHR | functionality for (S,G) traffic that is attached to another MEG; FHR | |||
functionality for (S,G) traffic from a particular source S MUST be | functionality for (S,G) traffic from a particular source S MUST be | |||
provided by only a single router. | provided by only a single router. | |||
Other deployment scenarios are also possible. For example, one might | Other deployment scenarios are also possible. For example, one might | |||
want to configure the MEGs to themselves be RPs. In this case, the | want to configure the MEGs themselves to be RPs. In this case, the | |||
RPs would have to exchange with each other information about which | RPs would have to exchange with each other information about which | |||
sources are active. The method exchanging such information is | sources are active. The method exchanging such information is | |||
outside the scope of this document. | outside the scope of this document. | |||
6.1.2.2.3. Source on Multihomed Segment | 6.1.2.2.3. Source on Multihomed Segment | |||
Suppose S is attached to a segment that is all-active multi-homed to | Suppose S is attached to a segment that is all-active multi-homed to | |||
PEl and PE2. If S is transmitting to two groups, say G1 and G2, it | PEl and PE2. If S is transmitting to two groups, say G1 and G2, it | |||
is possible that PE1 will receive the (S,G1) traffic from S while PE2 | is possible that PE1 will receive the (S,G1) traffic from S while PE2 | |||
receives the (S,G2) traffic from S. | receives the (S,G2) traffic from S. | |||
skipping to change at page 59, line 12 ¶ | skipping to change at page 59, line 12 ¶ | |||
(S,G1) traffic while selecting PE2 as the ingress PE for (S,G2) | (S,G1) traffic while selecting PE2 as the ingress PE for (S,G2) | |||
traffic. | traffic. | |||
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 picks the | |||
"wrong" EVPN-PE as the Upstream PE for (say) the (S,G1) traffic. | "wrong" EVPN-PE as the Upstream PE for (say) the (S,G1) traffic. | |||
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-homed to both PE1 and PE2, where PE1 is a MEG. And suppose | multi-homed to both PE1 and PE2, where PE1 is a MEG. And suppose | |||
that IP multicast traffic from S to G travels over the AC that | that IP multicast traffic from S to G travels over the AC that | |||
attaches the segment to PE2 . If PE1 receives a C-multicast Source | attaches the segment to PE2. If PE1 receives a C-multicast Source | |||
Tree Join (S,G) route, it MUST originate an SMET route for (S,G). | Tree Join (S,G) route, it MUST originate an SMET route for (S,G). | |||
Normal OISM procedures will then cause PE2 to send the (S,G) traffic | Normal OISM procedures will then cause PE2 to send the (S,G) traffic | |||
to PE1 on an EVPN IP multicast tunnel. Normal OISM procedures will | to PE1 on an EVPN IP multicast tunnel. Normal OISM procedures will | |||
also cause PE1 to send the (S,G) traffic up its BD1 IRB interface. | also cause PE1 to send the (S,G) traffic up its BD1 IRB interface. | |||
Normal MVPN procedures will then cause PE1 to forward the traffic on | Normal MVPN procedures will then cause PE1 to forward the traffic on | |||
an MVPN tunnel. In this case, the routing is not optimal, but the | an MVPN tunnel. In this case, the routing is not optimal, but the | |||
traffic does flow correctly. | traffic does flow correctly. | |||
6.1.2.3. Obtaining Optimal Routing of Traffic Between MVPN and EVPN | 6.1.2.3. Obtaining Optimal Routing of Traffic Between MVPN and EVPN | |||
skipping to change at page 60, line 7 ¶ | skipping to change at page 60, line 7 ¶ | |||
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-homed ethernet segment | to be optimal when a source host is on a multi-homed ethernet segment | |||
(as discussed in Section 6.1.2.2.) | (as discussed in Section 6.1.2.2.) | |||
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. | |||
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 an | MEG functionality to any subset of his EVPN OISM PEs. This allows an | |||
operator to make whatever trade-offs he deems appropriate between | operator to make whatever trade-offs deemed appropriate between | |||
optimal routing and MEG deployment. | optimal routing and MEG deployment. | |||
6.1.2.4. Selecting the MEG SBD-DR | 6.1.2.4. Selecting the MEG SBD-DR | |||
Every PE that is eligible for selection as the MEG SBD-DR originates | Every PE that is eligible for selection as the MEG SBD-DR originates | |||
an SBD-IMET route. As stated in Section 5, these SBD-IMET routes | an SBD-IMET route. As stated in Section 5, these SBD-IMET routes | |||
carry a Multicast Flags EC with the MEG Flag set. | carry a Multicast Flags EC with the MEG Flag set. | |||
These SBD-IMET routes SHOULD also carry a DF Election EC. The DF | These SBD-IMET routes SHOULD also carry a DF Election EC. The DF | |||
Election EC and its use is specified in ([RFC8584]). When the route | Election EC and its use are specified in ([RFC8584]). When the route | |||
is originated, the AC-DF bit in the DF Election EC SHOULD be set to | is originated, the AC-DF bit in the DF Election EC SHOULD be set to | |||
zero. This bit is not used when selecting a MEG SBD-DR, i.e., it | zero. This bit is not used when selecting a MEG SBD-DR, i.e., it | |||
MUST be ignored by the receiver of an SBD-IMET route. | MUST be ignored by the receiver of an SBD-IMET route. | |||
In the context of a given Tenant Domain, to select the MEG SBD-DR, | In the context of a given Tenant Domain, to select the MEG SBD-DR, | |||
the MEGs of the Tenant Domain perform the following procedure: | the MEGs of the Tenant Domain perform the following procedure: | |||
o From the set of received SBD-IMET routes for the given tenant | o From the set of received SBD-IMET routes for the given tenant | |||
domain, determine he candidate set of PEs that support MEG | domain, determine the candidate set of PEs that support MEG | |||
functionality for that domain. | functionality for that domain. | |||
o Select a DF Election algorithm as specified in [RFC8584]. Some of | o Select a DF Election algorithm as specified in [RFC8584]. Some of | |||
the possible algorithms can be found, e.g., in [RFC7432], | the possible algorithms can be found, e.g., in [RFC7432], | |||
[RFC8584], and [I-D.ietf-bess-evpn-pref-df]. | [RFC8584], and [I-D.ietf-bess-evpn-pref-df]. | |||
o Apply the DF Election Algorithm (see [RFC8584]) to the candidate | o Apply the DF Election Algorithm (see [RFC8584]) to the candidate | |||
set of PEs. The "winner" becomes the MEG SBD-DR. | set of PEs. The "winner" becomes the MEG SBD-DR. | |||
Note that if a given PE supports IPMG (Section 6.1.2) or PEG | Note that if a given PE supports IPMG (Section 6.1.2) or PEG | |||
skipping to change at page 62, line 7 ¶ | skipping to change at page 62, line 7 ¶ | |||
the IIF of the (S,G) state is set as follows: | the IIF of the (S,G) state is set as follows: | |||
o if S is on a BD that is attached to the PE, the IIF is the PE's | o if S is on a BD that is attached to the PE, the IIF is the PE's | |||
IRB interface to that BD; | IRB interface to that BD; | |||
o if S is not on a BD that is attached to the PE, the IIF is the | o 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. | |||
When the PE creates such an (S,G) state, it MUST originate (if it | When the PE creates such an (S,G) state, it MUST originate (if it | |||
hasn't already) an SBD-SMET route for (S,G). This will cause it to | 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 | receive the (S,G) traffic via layer 2. When the traffic arrives over an | |||
EVPN tunnel, it gets sent up an IRB interface where the layer 3 | EVPN tunnel, it gets sent up an IRB interface where the layer 3 | |||
multicast routing determines the packet's disposition. The SBD-SMET | multicast routing determines the packet's disposition. The SBD-SMET | |||
route is withdrawn when the (S,G) state no longer exists (unless | route is withdrawn when the (S,G) state no longer exists (unless | |||
there is some other reason for not withdrawing it). | there is some other reason for not withdrawing it). | |||
If there are no tenant multicast routers with the EVPN tenant domain, | 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 not have to | there cannot be an RP in the Tenant Domain, so a PEG does not have to | |||
handle externally arriving PIM Join(*,G) messages. | handle externally arriving PIM Join(*,G) messages. | |||
The PEG DR for a particular BD MUST act as the a First Hop Router for | The PEG DR for a particular BD MUST act as the a First Hop Router for | |||
that BD. It will examine all (S,G) traffic on the BD, and whenever G | 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 to the RP for | 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 the (S,G) | G. This means that the PEG DR will need to receive all the (S,G) | |||
traffic originating on a given BD, by originating an SMET (*,*) route | traffic originating on a given BD, by originating an SMET (*,*) route | |||
for that BD. If a PEG DR is the DR for all the BDS, in SHOULD | for that BD. If a PEG DR is the DR for all the SBD, in SHOULD | |||
originate just an SBD-SMET (*,*) route rather than an SMET (*,*) | originate just an SBD-SMET (*,*) route rather than an SMET (*,*) | |||
route for each BD. | route for each BD. | |||
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 Section 6.1.2.2, except that the | as those specified for MEGs in Section 6.1.2.2, except that the | |||
exported routes will be IP routes rather than VPN-IP routes, and it | 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 Source AS | is not necessary to attach the VRF Route Import EC or the Source AS | |||
EC. | EC. | |||
When a source is on a multi-homed segment, the same issue discussed | When a source is on a multi-homed segment, the same issue discussed | |||
skipping to change at page 63, line 23 ¶ | skipping to change at page 63, line 23 ¶ | |||
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 to | (*,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 | 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 added to the OIF list. | state, and the SBD IRB interface is added to the OIF list. | |||
6.2. Interworking with PIM via an External PIM Router | 6.2. Interworking with PIM via an External PIM Router | |||
Section 6.1 describes how to use an OISM PE router as the gateway to | Section 6.1 describes how to use an OISM PE router as the gateway to | |||
a non-EVPN multicast domain, when the EVPN tenant domain is not being | a non-EVPN multicast domain, when the EVPN tenant domain is not being | |||
used as an intermediate transit network for multicast. An | used as an intermediate transit network for multicast. An | |||
alternative approach is to have one or more external PIM routers | alternative approach is to have one or more external PIM routers | |||
(perhaps operated by a tenant) on one of the BDs of the tenant | (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". | |||
skipping to change at page 63, line 51 ¶ | skipping to change at page 63, line 51 ¶ | |||
o The OISM PEs do not run PIM. | o The OISM PEs do not run PIM. | |||
o There MUST NOT be more than one gateway BD. | o There MUST NOT be more than one gateway BD. | |||
o If an OISM PE not attached to the gateway BD has interest in a | o If an OISM PE not attached to the gateway BD has interest in a | |||
given multicast flow, it conveys that interest, following normal | given multicast flow, it conveys that interest, following normal | |||
OISM procedures, by originating an SBD-SMET route for that flow. | OISM procedures, by originating an SBD-SMET route for that flow. | |||
o If a PE attached to the gateway BD receives an SBD-SMET, it may | o If a PE attached to the gateway BD receives an SBD-SMET, it may | |||
need to generate and transmit a corresponding IGMP/MLD Join out | need to generate and transmit a corresponding IGMP/MLD Join on | |||
one or more of its ACs. (Procedures for generating an IGMP/MLD | one or more of its ACs. (Procedures for generating an IGMP/MLD | |||
Join as a result of receiving an SMET route are given in | Join as a result of receiving an SMET route are given in | |||
[RFC9251].) The PE MUST know which BD is the Gateway BD and MUST | [RFC9251].) The PE MUST know which BD is the Gateway BD and MUST | |||
NOT transmit an IGMP/MLD Join to any other BDs. Furthermore, even | NOT transmit an IGMP/MLD Join to any other BDs. Furthermore, even | |||
if a particular AC is part of that BD, the PE SHOULD NOT transmit | if a particular AC is part of that BD, the PE SHOULD NOT transmit | |||
an IGMP/MLD Join on that AC unless that an external PIM route is | an IGMP/MLD Join on that AC unless there is an external PIM route | |||
attached via that AC. | attached via that AC. | |||
As a result, IGMP/MLD messages will seen by the external PIM | As a result, IGMP/MLD messages will be received by the external PIM | |||
routers on the gateway BD, and those external PIM routers will | routers on the gateway BD, and those external PIM routers will | |||
send PIM Join messages externally as required. Traffic of the | send PIM Join messages externally as required. Traffic for the | |||
given multicast flow will then be received by one of the external | given multicast flow will then be received by one of the external | |||
PIM routers, and that traffic will be forwarded by that router to | PIM routers, and that traffic will be forwarded by that router to | |||
the gateway BD. | the gateway BD. | |||
The normal OISM procedures will then cause the given multicast | The normal OISM procedures will then cause the given multicast | |||
flow to be tunneled to any PEs of the EVPN Tenant Domain that have | flow 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, other PEs will see the | flow as originating from the gateway BD and other PEs will see the | |||
flow as originating from the SBD. | flow as originating from the SBD. | |||
o An OISM PE attached to a gateway BD MUST set its layer 2 multicast | o An OISM PE attached to a gateway BD MUST set its layer 2 multicast | |||
state to indicate that each AC to the gateway BD has interest in | state to indicate that each AC to the gateway BD has interest in | |||
all multicast flows. It MUST also originate an SMET route for | all multicast flows. It MUST also originate an SMET route for | |||
(*,*). The procedures for originating SMET routes are discussed | (*,*). The procedures for originating SMET routes are discussed | |||
in Section 2.5. | in Section 2.5. | |||
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 | all the IP multicast traffic that is sourced within the EVPN | |||
tenant domain, and to transmit that traffic to the gateway BD, | tenant domain, and to transmit that traffic to the gateway BD, | |||
where the external PIM routers will see it. This enables the | where the external PIM routers will receive it. This enables the | |||
external PIM routers to perform FHR functions on behalf of the | external PIM routers to perform FHR functions on behalf of the | |||
entire Tenant Domain. (Of course, if the gateway BD has a | entire Tenant Domain. (Of course, if the gateway BD has a | |||
multi-homed segment, only the PE that is the DF for that segment | multi-homed segment, only the PE that is the DF for that segment | |||
will transmit the multicast traffic to the segment.) | will transmit the multicast traffic to the segment.) | |||
7. Using an EVPN Tenant Domain as an Intermediate (Transit) Network for | 7. Using an EVPN Tenant Domain as an Intermediate (Transit) Network for | |||
Multicast traffic | Multicast traffic | |||
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 | |||
skipping to change at page 66, line 13 ¶ | skipping to change at page 66, line 13 ¶ | |||
will choose as the Upstream Neighbor the PIM router on BD1 that is | will choose as the Upstream Neighbor the PIM router on BD1 that is | |||
"closest" (according to the unicast routing) to X. Note that this | "closest" (according to the unicast routing) to X. Note that this | |||
will not necessarily be PE1. PE1 may not even be visible to the | will not necessarily be PE1. PE1 may not even be visible to the | |||
unicast routing algorithm used by the tenant routers. Even if it is, | unicast routing algorithm used by the tenant routers. Even if it is, | |||
it is unlikely to be the PIM router that is closest to X. So we need | it is unlikely to be the PIM router that is closest to X. So we need | |||
to consider the following two cases: | to consider the following two cases: | |||
1. C1 sends a PIM Join(X,G) to BD1, with PE1 as the Upstream | 1. C1 sends a PIM Join(X,G) to BD1, with PE1 as the Upstream | |||
Neighbor. | Neighbor. | |||
PE1's PIM routing instance will see the Join arrive on the BD1 | PE1's PIM routing instance will receive the Join arrive on the BD1 | |||
IRB interface. If X is not within the Tenant Domain, PE1 | IRB interface. If X is not within the Tenant Domain, PE1 | |||
handles the Join according to normal PIM procedures. This will | handles the Join according to normal PIM procedures. This will | |||
generally result in PE1 selecting an Upstream Neighbor and | generally result in PE1 selecting an Upstream Neighbor and | |||
sending it a Join(X,G). | sending it a Join(X,G). | |||
If X is within the Tenant Domain, but is attached to some other | If X is within the Tenant Domain, but is attached to some other | |||
PE, PE1 sends (if it hasn't already) an SBD-SMET route for | PE, 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 | (X,G). 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 | interface, and the OIF list will include the IRB interface to | |||
BD1. | BD1. | |||
The SBD-SMET route will pull the (X,G) traffic to PE1, and the | The SBD-SMET route will receive the (X,G) traffic to PE1, and the | |||
(X,G) state will result in the (X,G) traffic being forwarded to | (X,G) state will result in the (X,G) traffic being forwarded to | |||
C1. | C1. | |||
If X is within the Tenant Domain, but is attached to PE1 itself, | If X is within the Tenant Domain, but is attached to PE1 itself, | |||
no SBD-SMET route is sent. The IIF of the layer 3 (X,G) state | no 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 | will be the IRB interface to X's BD, and the OIF list will | |||
include the IRB interface to BD1. | include the IRB interface to BD1. | |||
2. C1 sends a PIM Join(X,G) to BD1, with either PE2 or C2 as the | 2. C1 sends a PIM Join(X,G) to BD1, with either PE2 or C2 as the | |||
Upstream Neighbor. | Upstream Neighbor. | |||
PE1's PIM routing instance will see the Join arrive on the BD1 | PE1's PIM routing instance will receive the Join on the BD1 | |||
IRB interface. If neither X nor Upstream Neighbor is within the | IRB interface. If neither X nor Upstream Neighbor is within the | |||
tenant domain, PE1 handles the Join according to normal PIM | tenant domain, PE1 handles the Join according to normal PIM | |||
procedures. This will NOT result in PE1 sending a Join(X,G). | procedures. This will NOT result in PE1 sending a Join(X,G). | |||
If either X or Upstream Neighbor is within the Tenant Domain, | If either X or Upstream Neighbor is within the Tenant Domain, | |||
PE1 sends (if it hasn't already) an SBD-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 | 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 | interface, and the OIF list will include the IRB interface to | |||
BD1. | BD1. | |||
The SBD-SMET route will pull the (X,G) traffic to PE1, and the | The SBD-SMET route will attract the (X,G) traffic to PE1, and the | |||
(X,G) state will result in the (X,G) traffic being forwarded to | (X,G) state will result in the (X,G) traffic being forwarded to | |||
C1. | C1. | |||
8. IANA Considerations | 8. IANA Considerations | |||
IANA is requested to assign new flags in the "Multicast Flags | IANA is requested to assign new flags in the "Multicast Flags | |||
Extended Community Flags" registry. These flags are: | Extended Community Flags" registry. These flags are: | |||
o IPMG | o IPMG | |||
skipping to change at page 71, line 9 ¶ | skipping to change at page 71, line 9 ¶ | |||
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., | [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., | |||
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation | Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation | |||
for Bit Index Explicit Replication (BIER) in MPLS and Non- | for Bit Index Explicit Replication (BIER) in MPLS and Non- | |||
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January | MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January | |||
2018, <https://www.rfc-editor.org/info/rfc8296>. | 2018, <https://www.rfc-editor.org/info/rfc8296>. | |||
Appendix A. Integrated Routing and Bridging | Appendix A. Integrated Routing and Bridging | |||
This Appendix provides a short tutorial on the interaction of routing | This Appendix provides a short tutorial on the interaction of routing | |||
and bridging. First it shows the traditional model, where bridging | and bridging. First it shows the traditional model, where bridging | |||
and routing are performed in separate boxes. Then it shows the model | and routing are performed in separate devices. Then it shows the model | |||
specified in [RFC9135], where a single box contains both routing and | specified in [RFC9135], where a single device contains both routing and | |||
bridging functions. The latter model is presupposed in the body of | bridging functions. The latter model is presupposed in the body of | |||
this document. | this document. | |||
Figure 1 shows a "traditional" router that only does routing and has | Figure 1 shows a "traditional" router that only does routing and has | |||
no L2 bridging capabilities. There are two LANs, LAN1 and LAN2. | no L2 bridging capabilities. There are two LANs, LAN1 and LAN2. | |||
LAN1 is realized by switch1, LAN2 by switch2. The router has an | LAN1 is realized by switch1, LAN2 by switch2. The router has an | |||
interface, "lan1" that attaches to LAN1 (via switch1) and an | interface, "lan1" that attaches to LAN1 (via switch1) and an | |||
interface "lan2" that attachs to LAN2 (via switch2). Each intreface | interface "lan2" that attachs to LAN2 (via switch2). Each intreface | |||
is configured, as an IP interface, with an IP address and a subnet | is configured, as an IP interface, with an IP address and a subnet | |||
mask. | mask. | |||
skipping to change at page 71, line 38 ¶ | skipping to change at page 71, line 38 ¶ | |||
|_________________| |__________________| | |_________________| |__________________| | |||
LAN1 LAN2 | LAN1 LAN2 | |||
Figure 1: Conventional Router with LAN Interfaces | Figure 1: Conventional Router with LAN Interfaces | |||
IP traffic (unicast or multicast) that remains within a single subnet | IP traffic (unicast or multicast) that remains within a single subnet | |||
never reaches the router. For instance, if H1 emits an ethernet | never reaches the router. For instance, if H1 emits an ethernet | |||
frame with H2's MAC address in the ethernet destination address | frame with H2's MAC address in the ethernet destination address | |||
field, the frame will go from H1 to Switch1 to H2, without ever | field, the frame will go from H1 to Switch1 to H2, without ever | |||
reaching the router. Since the frame is never seen by a router, the | reaching the router. Since the frame is never seen by a router, the | |||
IP datagram within the frame remains entirely unchanged; e.g., its | IP datagram within the frame remains entirely unchanged, e.g., its | |||
TTL is not decremented. The ethernet Source and Destination MAC | TTL is not decremented. The ethernet Source and Destination MAC | |||
addresses are not changed either. | addresses are not changed either. | |||
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 determines | 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 be routed. | 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 on LAN1. H1 | H1 uses ARP to map Router1's IP address to a MAC address on LAN1. H1 | |||
skipping to change at page 72, line 17 ¶ | skipping to change at page 72, line 17 ¶ | |||
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 field, and determines that | |||
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 decrements | Router1 now performs the IP processing of the datagram: it decrements | |||
the IP TTL, adjusts the IP header checksum (if present), may fragment | the IP TTL, adjusts the IP header checksum (if present), may fragment | |||
the packet is necessary, etc. Then the datagram (or its fragments) | the packet is necessary, etc. Then the datagram (or its fragments) | |||
are encapsulated in an ethernet header, with Router1's MAC address on | are encapsulated in an ethernet header, with Router1's MAC address on | |||
LAN2 as the MAC Source Address, and H3's MAC address on LAN2 (which | LAN2 as the MAC Source Address, and H3's MAC address on LAN2 (which | |||
Router1 determines via ARP) as the MAC Destination Address. Finally | Router1 determines via ARP) as the MAC Destination Address. Finally | |||
the packet is sent out the lan2 interface. | the packet is sent on the lan2 interface. | |||
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 is | encapsulates it in an ethernet frame whose MAC Destination Address is | |||
computed from the IP Destination Address. | computed from the IP Destination Address. | |||
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 the | copy of the frame, unchanged, from H1. The MAC Source Address in the | |||
ethernet encapsulation does not change, the IP TTL field does not get | ethernet encapsulation does not change, the IP TTL field does not get | |||
decremented, etc. | decremented, etc. | |||
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, will remove the ethernet encapsulation, | |||
and will determine how to dispatch the IP datagram based on Router1's | and will determine how to dispatch the IP datagram based on Router1's | |||
multicast forwarding states. If Router1 knows that there is a | multicast forwarding states. If Router1 knows that there is a | |||
receiver for the multicast datagram on LAN2, makes a copy of the | receiver for the multicast datagram on LAN2, it makes a copy of the | |||
datagram, decrements the TTL (and performs any other necessary IP | IP datagram, decrements the TTL (and performs any other necessary IP | |||
processing), then encapsulates the datagram in ethernet frame for | processing), then encapsulates the datagram in 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 from | Source Address on LAN2. The MAC Destination Address is computed from | |||
the IP Destination Address. Finally, the frame is sent out Router1's | the IP Destination Address. Finally, the frame is sent on Router1's | |||
LAN2 interface. | LAN2 interface. | |||
Figure 2 shows an Integrated Router/Bridge that supports the routing/ | Figure 2 shows an Integrated Router/Bridge that supports the routing/ | |||
bridging integration model of [RFC9135]. | bridging integration model of [RFC9135]. | |||
+------------------------------------------+ | +------------------------------------------+ | |||
| 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 | |||
Figure 2: Integrated Router/Bridge | Figure 2: Integrated Router/Bridge | |||
In Figure 2, a single box consists of one or more "L3 Routing | In Figure 2, a single device consists of one or more "L3 Routing | |||
Instances". The routing/forwarding tables of a given routing | Instances". The routing/forwarding tables of a given routing | |||
instance is known as an IP-VRF ([RFC9135]). In the context of EVPN, | instance is known as an IP-VRF [RFC9135]. In the context of EVPN, | |||
it is convenient to think of each routing instance as representing | it is convenient to think of each routing instance as representing | |||
the routing of a particular tenant. Each IP-VRF is attached to one | the routing of a particular tenant. Each IP-VRF is attached to one | |||
or more interfaces. | or more interfaces. | |||
When several EVPN PEs have a routing instance of the same tenant | When several EVPN PEs have a routing instance in the same tenant | |||
domain, those PEs advertise IP routes to the attached hosts. This is | domain, those PEs advertise IP routes to the attached hosts. This is | |||
done as specified in [RFC9135]. | done as specified in [RFC9135]. | |||
The integrated router/bridge shown in Figure 2 also attaches to a | The integrated router/bridge shown in Figure 2 also attaches to a | |||
number of "Broadcast Domains" (BDs). Each BD performs the functions | number of "Broadcast Domains" (BDs). Each BD performs the functions | |||
that are performed by the bridges in Figure 1. To the L3 routing | that are performed by the bridges in Figure 1. To the L3 routing | |||
instance, each BD appears to be a LAN. The interface attaching a | instance, each BD appears to be a LAN. The interface attaching a | |||
particular BD to a particular IP-VRF is known as an "IRB Interface". | particular BD to a particular IP-VRF is known as an "IRB Interface". | |||
From the perspective of L3 routing, each BD is a subnet. Thus each | From the perspective of L3 routing, each BD is a subnet. Thus each | |||
IRB interface is configured with a MAC address (which is the router's | IRB interface is configured with a MAC address (which is the router's | |||
skipping to change at page 74, line 48 ¶ | skipping to change at page 74, line 48 ¶ | |||
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 ethernet | BD. H1 thus uses ARP to find H4's MAC address, and sends an ethernet | |||
frame with H4's MAC address in the Destination MAC address field. | frame with H4's MAC address in the Destination MAC address field. | |||
The frame is received at PE1, but since the Destination MAC address | 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 remain on | is not PE1's MAC address, PE1 assumes that the frame is to remain on | |||
BD1. Therefore the packet inside the frame is NOT decapsulated, and | BD1. Therefore the packet inside the frame is NOT decapsulated, and | |||
is NOT send up the IRB interface to PE1's routing instance. Rather, | is NOT sent via the IRB interface to PE1's routing instance. Rather, | |||
standard EVPN intra-subnet procedures (as detailed in [RFC7432] are | standard EVPN intra-subnet procedures (as detailed in [RFC7432]) are | |||
used to deliver the frame to PE2, which then sends it to H4. | used to deliver the frame to PE2, which then sends it to H4. | |||
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 receives | PE1's MAC address in its Destination MAC Address field. PE1 receives | |||
the frame, and sees that the frame is addressed to it. PE1 thus | the frame, and sees that the frame is addressed to it. PE1 thus | |||
sends the frame up its IRB1 interface to the L3 routing instance. | sends the frame via its IRB1 interface to the L3 routing instance. | |||
Appropriate IP processing is done (e.g., TTL decrement). The L3 | Appropriate IP processing is done, e.g., TTL decrement. The L3 | |||
routing instance determines that the "next hop" for H5 is PE2, so the | routing instance determines that the "next hop" for H5 is PE2, so the | |||
packet is encapsulated (e.g., in MPLS) and sent across the backbone | packet is encapsulated (e.g., in MPLS) and sent across the backbone | |||
to PE2's routing instance. PE2 will see that the packet's | to PE2's routing instance. PE2 will see that the packet's | |||
destination, H5, is on BD2 segment-2, and will send the packet down | destination, H5, is on BD2 segment-2, and will send the packet via | |||
its IRB2 interface. This causes the IP packet to be encapsulated in | its IRB2 interface. This causes the IP packet to be encapsulated in | |||
an ethernet frame with PE2's MAC address (on BD2) in the Source | an ethernet frame with PE2's MAC address (on BD2) in the Source | |||
Address field and H5's MAC address in the Destination Address field. | Address field and H5's MAC address in the Destination Address field. | |||
Note that if H1 has an IP packet to send to H3, the forwarding of the | 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 sees | packet is handled entirely within PE1. PE1's routing instance sees | |||
the packet arrive on its IRB1 interface, and then transmits the | the packet arrive on its IRB1 interface, and then transmits the | |||
packet by sending it down its IRB2 interface. | packet by sending it via its IRB2 interface. | |||
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 assigned, as an "anycast address", to 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 are | EVPN PEs attached to that Tenant Domain. Thus although all hosts are | |||
provisioned with the same "default router address", the actual | provisioned with the same "default router address", the actual | |||
default router for a given host will be one of the PEs that is | default router for a given host will be the PEs that is | |||
attached to the same ethernet segment as the host. This provisioning | attached to the same ethernet segment as the host. This provisioning | |||
method ensures that IP packets from a given host are handled by the | method ensures that IP packets from a given host are handled by the | |||
closest EVPN PE that supports IRB. | closest EVPN PE that supports IRB. | |||
In the topology of Figure 3, one could imagine that H1 is configured | In the topology of Figure 3, one could imagine that H1 is configured | |||
with a default router address that belongs to PE2 but not to PE1. | with a default router address that belongs to PE2 but not to PE1. | |||
Inter-subnet routing would still work, but IP packets from H1 to H3 | Inter-subnet routing would still work, but IP packets from H1 to H3 | |||
would then follow the non-optimal path H1-->PE1-->PE2-->PE1-->H3. | would then follow the non-optimal path H1-->PE1-->PE2-->PE1-->H3. | |||
Sending traffic on this sort of path, where it leaves a router and | Sending traffic on this sort of path, where it leaves a router and | |||
then comes back to the same router, is sometimes known as | then comes back to the same router, is sometimes known as | |||
"hairpinning". Similarly, if PE2 supports IRB but PE1 dos not, the | "hairpinning". Similarly, if PE2 supports IRB but PE1 dos not, the | |||
same non-optimal path from H1 to H3 would have to be followed. To | same non-optimal path from H1 to H3 would have to be followed. To | |||
avoid hairpinning, each EVPN PE needs to support IRB. | avoid hairpinning, each EVPN PE needs to support IRB. | |||
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 Figure 3, suppose PE1 and PE2 | multicast traffic. Referring again to Figure 3, suppose PE1 and PE2 | |||
are functioning as IP multicast routers. Suppose also that H3 | are functioning as IP multicast routers. Also suppose that H3 | |||
transmits a multicast packet, and both H1 and H4 are interested in | transmits a multicast packet, and both H1 and H4 are interested in | |||
receiving that packet. PE1 will receive the packet from H3 via its | receiving that packet. PE1 will receive the packet from H3 via its | |||
IRB2 interface. The ethernet encapsulation from BD2 is removed, the | IRB2 interface. The ethernet encapsulation from BD2 is removed, the | |||
IP header processing is done, and the packet is then reencapsulated | IP header processing is done, and the packet is then reencapsulated | |||
for BD1, with PE1's MAC address in the MAC Source Address field. | for BD1, with PE1's MAC address in the MAC Source Address field. | |||
Then the packet is sent down the IRB1 interface. Layer 2 procedures | Then the packet is sent via the IRB1 interface. Layer 2 procedures | |||
(as defined in [RFC7432] would then be used to deliver a copy of the | (as defined in [RFC7432]) would then be used to deliver a copy of the | |||
packet locally to H1, and remotely to H4. | packet locally to H1, and remotely to H4. | |||
Please be aware that his document modifies the semantics, described | Please be aware that his 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 Section 1.5.1 and subsequent | an IRB interface. This is explained in Section 1.5.1 and subsequent | |||
sections. | sections. | |||
Authors' Addresses | Authors' Addresses | |||
Wen Lin | Wen Lin | |||
End of changes. 121 change blocks. | ||||
137 lines changed or deleted | 136 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |