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. |