RFC Errata
Found 3 records.
Status: Verified (2)
RFC 9135, "Integrated Routing and Bridging in Ethernet VPN (EVPN)", October 2021
Source of RFC: bess (rtg)
Errata ID: 7683
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Denis Vrkic
Date Reported: 2023-10-19
Verifier Name: John Scudder
Date Verified: 2024-02-09
Section 4.2. says:
2. However, if PE2 is configured for asymmetric IRB mode, PE2 will
advertise TS4 MAC/IP information in a MAC/IP Advertisement route
with a zero Label2 field and no Route Target identifying IP-VRF1.
In this case, PE2 will install TS4 information in its ARP table
and BT1. When a packet from TS2 to TS4 arrives at PE1, a longest
prefix match on IP-VRF1's route table will yield the local IRB
interface to BT1, where a subsequent ARP and bridge table lookup
will provide the information for an asymmetric forwarding mode to
PE2.
It should say:
2. However, if PE2 is configured for asymmetric IRB mode, PE2 will
advertise TS4 MAC/IP information in a MAC/IP Advertisement route
with a zero Label2 field and no Route Target identifying IP-VRF1.
In this case, PE1 will install TS4 information in its ARP table
and BT1. When a packet from TS2 to TS4 arrives at PE1, a longest
prefix match on IP-VRF1's route table will yield the local IRB
interface to BT1, where a subsequent ARP and bridge table lookup
will provide the information for an asymmetric forwarding mode to
PE2.
Notes:
PE1 will use ARP table for forwarding traffic to PE2 - seems like typo
Errata ID: 7684
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Denis Vrkic
Date Reported: 2023-10-19
Verifier Name: John Scudder
Date Verified: 2024-02-12
Section 6.1 says:
This route is advertised along with the following extended community: * Tunnel Type Extended Community
It should say:
This route is advertised along with the following extended community: * Encapsulation Extended Community
Notes:
I guess that solud be Encapsulation Extended Community (or maybe Tunnel Encapsulation Attribute)
Verifier notes:
See https://mailarchive.ietf.org/arch/msg/bess/TgQR3NHd6wgcYow0B76i7ToBmr0/
Status: Rejected (1)
RFC 9135, "Integrated Routing and Bridging in Ethernet VPN (EVPN)", October 2021
Source of RFC: bess (rtg)
Errata ID: 7686
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Denis Vrkic
Date Reported: 2023-10-20
Rejected by: John Scudder
Date Rejected: 2024-02-12
Section 6.1 says:
6.1. Control Plane - Advertising PE When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address of an attached TS (e.g., via an ARP request or ND Neighbor Solicitation), it populates its MAC-VRF/BT, IP-VRF, and ARP table or NDP cache just as in the case for symmetric IRB.
It should say:
6.1. Control Plane - Advertising PE When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address of an attached TS (e.g., via an ARP request or ND Neighbor Solicitation), it populates its MAC-VRF/BT and ARP table or NDP cache.
Notes:
- advertising PE (egress PE) is not advertising Label2 ("the MPLS Label2 field MUST NOT be included in this route.")
- so this must be asymmetric egress PE
- in 4.2 is stated that: "the asymmetric IRB mode simplifies the forwarding model
and saves space in the IP-VRF route table, since host routes are not installed in the route table."
- so i guess that, advertising PE in asymmetric mode, is NOT leaning/storing local IP to IP-VRF table only ARP (bound to IP-VRF) and MAC into MAC-VRF
--VERIFIER NOTES--
See https://mailarchive.ietf.org/arch/msg/bess/9pvIR6OysyFKso9rDRb-CJj7we8/