rfc9744v2.txt | rfc9744.txt | |||
---|---|---|---|---|
skipping to change at line 213 ¶ | skipping to change at line 213 ¶ | |||
AC to a VPWS service tunnel (e.g., a VPWS service instance) and then | AC to a VPWS service tunnel (e.g., a VPWS service instance) and then | |||
signaling the VPWS service tunnel via an Ethernet A-D per EVI route | signaling the VPWS service tunnel via an Ethernet A-D per EVI route | |||
with the Ethernet Tag field set to a 24-bit VPWS service instance | with the Ethernet Tag field set to a 24-bit VPWS service instance | |||
identifier (which is unique within the EVI) and the ESI field set to | identifier (which is unique within the EVI) and the ESI field set to | |||
a 10-octet identifier of the ES corresponding to that AC. | a 10-octet identifier of the ES corresponding to that AC. | |||
Therefore, a PE device that receives such EVPN routes can associate | Therefore, a PE device that receives such EVPN routes can associate | |||
the VPWS service tunnel to the remote ES using the ESI field. | the VPWS service tunnel to the remote ES using the ESI field. | |||
Additionally, when the remote ES fails and the PE receives the "mass | Additionally, when the remote ES fails and the PE receives the "mass | |||
withdrawal" message associated with the failed ES per [RFC7432], a PE | withdrawal" message associated with the failed ES per [RFC7432], a PE | |||
device can quickly update its BGP list of available remote entries to | device can quickly update its next-hop adjacency list (adjacency | |||
invalidate all VPWS service tunnels sharing the ESI field and achieve | list) for all VPWS service tunnels sharing the ESI field and achieve | |||
fast convergence for multi-homing scenarios. Even if fast | fast convergence for multi-homing scenarios. Even if fast | |||
convergence was not needed, there would still be a need for signaling | convergence were not needed, there would still be a need for | |||
each AC failure (via its corresponding VPWS service tunnel) | signaling each AC failure (via its corresponding VPWS service tunnel) | |||
associated with the failed ES so that the BGP path list for each of | associated with the failed ES so that the adjacency list gets updated | |||
them gets updated accordingly and the packets are sent to a backup PE | and the packets are sent to a backup PE (in case of Single-Active | |||
(in case of Single-Active multi-homing) or to other PEs in the | multi-homing) or to other PEs in the redundancy group (in case of | |||
redundancy group (in case of All-Active multi-homing). In the | All-Active multi-homing). In the absence of updating the adjacency | |||
absence of updating the BGP path list, the traffic for that VPWS | list properly, the traffic for that VPWS service tunnel will be | |||
service tunnel will be black-holed. | dropped by the egress PE with a failed ES/AC. | |||
When a single VPWS service tunnel carries multiple ACs across various | When a single VPWS service tunnel carries multiple ACs across various | |||
ESs (physical interfaces) without signaling the ACs via EVPN BGP to | ESs (physical interfaces) without signaling the ACs via EVPN BGP to | |||
remote PE devices, those remote PE devices lack the information to | remote PE devices, those remote PE devices lack the information to | |||
associate the received ES with these ACs or with their local ACs. | associate the received ES with these ACs or with their local ACs. | |||
They also lack the association between the VPWS service tunnel (e.g., | They also lack the association between the VPWS service tunnel (e.g., | |||
EVPN service label) and the far-end ACs. This means that, while the | EVPN service label) and the far-end ACs. This means that, while the | |||
remote PEs can associate their local ACs with the VPWS service | remote PEs can associate their local ACs with the VPWS service | |||
tunnel, they cannot make similar associations for the far-end ACs. | tunnel, they cannot make similar associations for the far-end ACs. | |||
skipping to change at line 262 ¶ | skipping to change at line 262 ¶ | |||
destination PE, thereby potentially wasting network resources. | destination PE, thereby potentially wasting network resources. | |||
This waste of network resources during a connection failure may be | This waste of network resources during a connection failure may be | |||
transient, as it can be detected and prevented at the application | transient, as it can be detected and prevented at the application | |||
layer in certain cases. Section 3.2 outlines a solution for such | layer in certain cases. Section 3.2 outlines a solution for such | |||
single-homing VPWS services. | single-homing VPWS services. | |||
For VPWS services where one of the endpoints is multi-homed, there | For VPWS services where one of the endpoints is multi-homed, there | |||
are two options: | are two options: | |||
1. Signal each AC via BGP, allowing the path list to be updated upon | 1. Signal each AC via BGP, allowing the adjacency list to be updated | |||
a failure affecting those ACs. This solution is described in | upon a failure affecting those ACs. This solution is described | |||
Section 3.3 and is referred to as the "VLAN-signaled FXC | in Section 3.3 and is referred to as the "VLAN-signaled FXC | |||
service". | service". | |||
2. Bundle several ACs on an ES together per destination endpoint | 2. Bundle several ACs on an ES together per destination endpoint | |||
(e.g., ES, MAC-VRF, etc.) and associate such a bundle with a | (e.g., ES, MAC-VRF, etc.) and associate such a bundle with a | |||
single VPWS service tunnel. This approach is similar to the VLAN | single VPWS service tunnel. This approach is similar to the VLAN | |||
bundle service interface described in [RFC8214]. This solution | bundle service interface described in [RFC8214]. This solution | |||
is described in Section 3.2.1. | is described in Section 3.2.1. | |||
3. Solution | 3. Solution | |||
skipping to change at line 641 ¶ | skipping to change at line 641 ¶ | |||
to the backup PE is the same as the one described above. | to the backup PE is the same as the one described above. | |||
5.2. Attachment Circuit Failure | 5.2. Attachment Circuit Failure | |||
In the event of an AC failure, the VLAN-Signaled and default FXC | In the event of an AC failure, the VLAN-Signaled and default FXC | |||
modes exhibit distinct behaviors: | modes exhibit distinct behaviors: | |||
* Default FXC (Figure 1): In the default mode, a VLAN or AC failure | * Default FXC (Figure 1): In the default mode, a VLAN or AC failure | |||
is not signaled. Consequently, in case of an AC failure, such as | is not signaled. Consequently, in case of an AC failure, such as | |||
VID1 on CE2, there is nothing to prevent PE3 from directing | VID1 on CE2, there is nothing to prevent PE3 from directing | |||
traffic from CE4 to PE1, leading to a potential black hole. | traffic from CE4 to PE1, leading to a potential packet loss at the | |||
Application layer OAM may be utilized if per-VLAN fault | egress PE with a failed AC. Application layer OAM may be utilized | |||
propagation is necessary in this scenario. | if per-VLAN fault propagation is necessary in this scenario. | |||
* VLAN-Signaled FXC (Figure 2): In the case of a VLAN or AC failure, | * VLAN-Signaled FXC (Figure 2): In the case of a VLAN or AC failure, | |||
such as VID1 on CE2, this triggers the withdrawal of the Ethernet | such as VID1 on CE2, this triggers the withdrawal of the Ethernet | |||
A-D per-EVI route for the corresponding Normalized VID, | A-D per-EVI route for the corresponding Normalized VID, | |||
specifically Ethernet-Tag 2. Upon receiving the route withdrawal, | specifically Ethernet-Tag 2. Upon receiving the route withdrawal, | |||
PE3 will remove PE1 from its outgoing path list for traffic | PE3 will remove PE1 from its outgoing adjacency list for traffic | |||
originating from CE4. | originating from CE4. | |||
5.3. PE Port Failure | 5.3. PE Port Failure | |||
In the event of a PE port failure, the failure will be signaled, and | In the event of a PE port failure, the failure will be signaled, and | |||
the other PE will assume forwarding in both scenarios: | the other PE will assume forwarding in both scenarios: | |||
* Default FXC (Figure 1): In the case of a port failure, such as p2, | * Default FXC (Figure 1): In the case of a port failure, such as p2, | |||
the route for Service Tunnel 2 (sv.T2) will be withdrawn. Upon | the route for Service Tunnel 2 (sv.T2) will be withdrawn. Upon | |||
receiving the fault notification, PE3 will remove PE1 from its | receiving the fault notification, PE3 will remove PE1 from its | |||
path list for traffic originating from CE4 and CE5. | adjacency list for traffic originating from CE4 and CE5. | |||
* VLAN-Signaled FXC (Figure 2): A port failure, such as p2, triggers | * VLAN-Signaled FXC (Figure 2): A port failure, such as p2, triggers | |||
the withdrawal of the Ethernet A-D per EVI routes for normalized | the withdrawal of the Ethernet A-D per EVI routes for normalized | |||
VIDs 2 and 3, along with the withdrawal of the Ethernet A-D per-ES | VIDs 2 and 3, along with the withdrawal of the Ethernet A-D per-ES | |||
route for p2's ES. Upon receiving the fault notification, PE3 | route for p2's ES. Upon receiving the fault notification, PE3 | |||
will remove PE1 from its path list for the traffic originating | will remove PE1 from its adjacency list for the traffic | |||
from CE4 and CE5. | originating from CE4 and CE5. | |||
5.4. PE Node Failure | 5.4. PE Node Failure | |||
In the case of PE node failure, the operation is similar to the steps | In the case of PE node failure, the operation is similar to the steps | |||
described above, albeit that EVPN route withdrawals are performed by | described above, albeit that EVPN route withdrawals are performed by | |||
the route reflector instead of the PE. | the route reflector instead of the PE. | |||
6. Security Considerations | 6. Security Considerations | |||
Since this document describes a muxing capability that leverages | Since this document describes a muxing capability that leverages | |||
End of changes. 7 change blocks. | ||||
20 lines changed or deleted | 20 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |