Re: [bess] [Technical Errata Reported] RFC9135 (7686)

[John Scudder]

Hi Authors and all,

While we are looking at RFC 9135, please look at this one too. Looks reasonable.

Thanks and happy Friday,

—John

> On Oct 20, 2023, at 10:39 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC9135,
> "Integrated Routing and Bridging in Ethernet VPN (EVPN)".
> 
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7686__;!!NEt6yMaO-gk!Bv40CvO596tIrUqB8Ny93blSg-Ou7E6QfK7hNtizTCvfc_Dtl8A83hkLnmj8y6nqZy7mVbWMztGjuGmjA0e6QA$
> 
> --
> Type: Technical
> Reported by: Denis Vrkic 
> 
> Section: 6.1
> 
> Original Text
> -
> 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.
> 
> Corrected Text
> --
> 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
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --
> RFC9135 (draft-ietf-bess-evpn-inter-subnet-forwarding-15)
> --
> Title   : Integrated Routing and Bridging in Ethernet VPN (EVPN)
> Publication Date: October 2021
> Author(s)   : A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan
> Category: PROPOSED STANDARD
> Source  : BGP Enabled ServiceS
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Technical Errata Reported] RFC9135 (7686)

[Ali Sajassi (sajassi)]

Hi John,

I am inclined to reject this errata for the following reasons:


  1.  The original text in section 6.1 is correct and the proposed text is 
incorrect. When a MAC/IP pair is learned a result of local ARP/ND procedure, 
the local IP-VRF table is populated. If it is not populated, then local routing 
from one VLAN/subnet to another one in the same PE won’t work!
  2.  The description in 4.2 is misunderstood. The operation of asymmetric IRB 
is simpler because there is no glean procedure as the one for symmetric IRB. 
Also, there are no RT-5 route advertisement for asymmetric IRB and thus they 
are not installed in route table (IP-VRF) for asymmetric IRB. I think the 
errata author has confused the subnet routes with individual host IP addresses.

Cheers,
Ali

From: John Scudder 
Date: Friday, February 9, 2024 at 1:30 PM
To: bess@ietf.org 
Cc: Ali Sajassi (sajassi) , Samer Salam (ssalam) 
, Samir Thoria (sthoria) , Jorge Rabadan 
(Nokia) , Alvaro Retana , 
Andrew Alston - IETF , matthew.bo...@nokia.com 
, slitkows.i...@gmail.com , 
Jeffrey (Zhaohui) Zhang , vrkic.de...@gmail.com 
, John Drake 
Subject: Re: [Technical Errata Reported] RFC9135 (7686)
Hi Authors and all,

While we are looking at RFC 9135, please look at this one too. Looks reasonable.

Thanks and happy Friday,

—John

> On Oct 20, 2023, at 10:39 AM, RFC Errata System  
> wrote:
>
> The following errata report has been submitted for RFC9135,
> "Integrated Routing and Bridging in Ethernet VPN (EVPN)".
>
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7686__;!!NEt6yMaO-gk!Bv40CvO596tIrUqB8Ny93blSg-Ou7E6QfK7hNtizTCvfc_Dtl8A83hkLnmj8y6nqZy7mVbWMztGjuGmjA0e6QA$
>
> --
> Type: Technical
> Reported by: Denis Vrkic 
>
> Section: 6.1
>
> Original Text
> -
> 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.
>
> Corrected Text
> --
> 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
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC9135 (draft-ietf-bess-evpn-inter-subnet-forwarding-15)
> --
> Title   : Integrated Routing and Bridging in Ethernet VPN (EVPN)
> Publication Date: October 2021
> Author(s)   : A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan
> Category: PROPOSED STANDARD
> Source  : BGP Enabled ServiceS
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess