RFC Errata
Found 5 records.
Status: Verified (4)
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/
Errata ID: 8375
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2025-04-06
Verifier Name: Gunter Van de Velde
Date Verified: 2025-05-02
Section 6.3 says:
The ingress PE gets the destination TS's MAC address for that TS's IP address from its ARP table or NDP cache. It encapsulates the packet with that destination MAC address and a source MAC address corresponding to that IRB interface and sends the packet to its destination subnet MAC-VRF/BT.
It should say:
The ingress PE gets the destination TS's MAC address for that TS's IP address from its ARP table or NDP cache. It encapsulates the packet with that destination MAC address and a source MAC address corresponding to that IRB interface. In addition, if all following conditions for the EVPN instance in question are met: - uses MPLS encapsulation - implements VLAN-aware bundle service interface as defined in Section 6.3 of RFC 7432 then the VLAN tag with the "normalized VID" of the corresponding BT is pushed on the customer IP packet. The resulting packet is sent to its destination subnet MAC-VRF/BT.
Notes:
Section 6.3 of RFC 743 OPTIONALLY allows a MAC-VRF that implements VLAN-aware bundle service interface and uses MPLS encapsulation to advertise the same label for all its broadcast domains. This option is only allowed when each broadcast domain in such a MAC-VRF is represented by the same VID in all the PEs. With this option, a VLAN tag with the "normalized" VID of the specific ingress domain MUST be present when the packet crosses the underlay, and MUST be used for identification of the specific broadcast domain in the egress PE.
In the case of inter-subnet forwarding, the original VLAN tag of IP packets undergoing such forwarding does not identify the broadcast domain to which the packet would be sent.
Errata ID: 8478
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2025-06-24
Verifier Name: Gunter Van de Velde
Date Verified: 2025-06-26
Section 3 says:
IP-VRF is identified by its corresponding Route Target and Route Distinguisher, and MAC-VRF is also identified by its corresponding Route Target and Route Distinguisher. If operating in EVPN VLAN-based mode, then a receiving PE that receives an EVPN route with a MAC-VRF Route Target can identify the corresponding bridge table; however, if operating in EVPN VLAN-aware bundle mode, then the receiving PE needs both the MAC-VRF Route Target and VLAN ID in order to identify the corresponding bridge table.
It should say:
IP-VRF is identified by its corresponding Route Target and Route Distinguisher, and MAC-VRF is also identified by its corresponding Route Target and Route Distinguisher. If operating in EVPN VLAN-based mode, then a receiving PE that receives an EVPN route with a MAC-VRF Route Target can identify the corresponding bridge table; however, if operating in EVPN VLAN-aware bundle mode, then the receiving PE needs both the MAC-VRF Route Target and Ethernet Tag ID in the NLRI of the route in order to identify the corresponding bridge table.
Notes:
MAC/IP Advertisement (EVPN Type 2) routes for IP-->MAC pairs do not carry any information about VLAN IDs used in encapsulation of ARP (or NA) messages that trigger their advertisement.
Instead, they carry Ethernet Tag IDs of Broadcast Domains in which these messages have been received which may represent the original VLAN ID or the so-called "normalized" VLAN ID of the Broadcast Domain as defined in Section 6.3 of RFC 7432.
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/