rfc9625v2.txt   rfc9625.txt 
skipping to change at line 965 skipping to change at line 965
In this case, the route is associated with the BD in EVI-1 In this case, the route is associated with the BD in EVI-1
that is identified (in the context of EVI-1) by the Tag ID that is identified (in the context of EVI-1) by the Tag ID
field of the route's NLRI. (If EVI-1 contains only a single field of the route's NLRI. (If EVI-1 contains only a single
BD, the Tag ID is likely to be zero.) BD, the Tag ID is likely to be zero.)
This is the case where the route is for a BD to which the This is the case where the route is for a BD to which the
receiving PE is attached, but the route also carries the receiving PE is attached, but the route also carries the
SBD-RT. In this case, the receiving PE associates the route SBD-RT. In this case, the receiving PE associates the route
with the ordinary BD, not with the SBD. with the ordinary BD, not with the SBD.
NB: According to the above rules, the mapping from BD to RT is a Note that according to the above rules, the mapping from BD to RT is
many-to-one or one-to-one mapping. A route that an EVPN PE a many-to-one or one-to-one mapping. A route that an EVPN PE
originates for a particular BD carries that BD's RT, and an EVPN PE originates for a particular BD carries that BD's RT, and an EVPN PE
that receives the route associates it with a BD as described above. that receives the route associates it with a BD as described above.
However, RTs are not used only to help identify the BD to which a However, RTs are not used only to help identify the BD to which a
route belongs; they may also be used by BGP to determine the path route belongs; they may also be used by BGP to determine the path
along which the route is distributed and to determine which PEs along which the route is distributed and to determine which PEs
receive the route. There may be cases where it is desirable to receive the route. There may be cases where it is desirable to
originate a route for a particular BD but have that route distributed originate a route for a particular BD but have that route distributed
to only some of the EVPN PEs attached to that BD. Or one might want to only some of the EVPN PEs attached to that BD. Or one might want
the route distributed to some intermediate set of systems, where it the route distributed to some intermediate set of systems, where it
might be modified or replaced before being propagated further. Such might be modified or replaced before being propagated further. Such
skipping to change at line 2428 skipping to change at line 2428
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 an L3 Gateway One way of handling this is the following. When an L3 Gateway
receives (S,G) traffic from other than an IRB interface, and the receives (S,G) traffic that is from an interface other than IRB, and
traffic corresponds to a Layer 3 (*,G) state, the L3 Gateway can the 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
skipping to change at line 2455 skipping to change at line 2455
an FHR, the DR for a given BD would send the PIM Register messages an FHR, the DR for a given BD would send the PIM Register messages
for sources on that BD). Although, note that the DR for the SBD does for sources on that BD). Although, note 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.
NB: If it is possible that more than one BD contains a tenant Note that if it is possible that more than one BD contains a tenant
multicast router, then a PE receiving a SMET route for that BD MUST multicast router, then a PE receiving a SMET route for that BD MUST
NOT reconstruct IGMP/MLD Join Reports from the SMET route and MUST NOT reconstruct IGMP/MLD Join Reports from the SMET route and MUST
NOT transmit any such IGMP/MLD Join Reports on its local ACs NOT transmit any such IGMP/MLD Join Reports on its local ACs
attaching to that BD. Otherwise, multicast traffic may be attaching to that BD. Otherwise, multicast traffic may be
duplicated. duplicated.
6.1.2. Interworking with MVPN 6.1.2. Interworking with MVPN
In this section, we specify the procedures necessary to allow EVPN In this section, we specify the procedures necessary to allow EVPN
PEs running OISM procedures to interwork with L3VPN PEs that run BGP- PEs running OISM procedures to interwork with L3VPN PEs that run BGP-
skipping to change at line 3374 skipping to change at line 3374
[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 a model, where bridging and routing
and routing are performed in separate devices. Then, it shows the are performed in separate devices. Then, it shows the model
model specified in [RFC9135], where a single device contains both specified in [RFC9135], where a single device contains both routing
routing and bridging functions. The latter model is presupposed in and bridging functions. The latter model is presupposed in the body
the body of this document. of this document.
Figure 2 shows a traditional router that only does routing and has no Figure 2 shows the model where a router only does routing and has no
L2 bridging capabilities. There are two LANs: LAN1 and LAN2. LAN1 L2 bridging capabilities. There are two LANs: LAN1 and LAN2. LAN1
is realized by switch1, and LAN2 is realized by switch2. The router is realized by switch1, and LAN2 is realized by switch2. The router
has an interface, lan1, that attaches to LAN1 (via switch1) and an has an interface, lan1, that attaches to LAN1 (via switch1) and an
interface, lan2, that attaches to LAN2 (via switch2). Each interface interface, lan2, that attaches to LAN2 (via switch2). Each interface
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.
+-------+ +--------+ +-------+ +-------+ +--------+ +-------+
| | lan1| |lan2 | | | | lan1| |lan2 | |
H1 -----+Switch1+--------+ Router1+--------+Switch2+------H3 H1 -----+Switch1+--------+ Router1+--------+Switch2+------H3
 End of changes. 5 change blocks. 
11 lines changed or deleted 11 lines changed or added

This html diff was produced by rfcdiff 1.48.