Re: [bess] [Errata Verified] RFC9135 (7683)

[John Scudder <[e-mail]>]

Hi Ali,

I already verified this. I can request that the note be revised, but I wanted to double-check if you really disagree with it, or if you were just reading fast. The note says:

   "PE1 will use ARP table for forwarding traffic to PE2”

You say:

   "PE1 does use the ARP table for forwarding traffic to PE2”

Those statements are equivalent (the note says “will use”, and you say “does use the”, there is no other difference), so I guess either you mistakenly read the note as saying “will not”, or you left out a “not” in your statement, is in “does not”. For now, I am assuming it was a mistaken reading and the note is not wrong.

Thanks,

—John

> On Feb 11, 2024, at 3:23 PM, Ali Sajassi (sajassi) <sajassi=[e-mail]> wrote:
> 
> Yes, there is a typo in the 4th line and “PE2” needs to be replaced with “PE1” as reflected in “Corrected text”.  However the note that says: “PE1 will use ARP table for forwarding traffic to PE2 - seems like typo”, is incorrect. PE1 does use the ARP table for forwarding traffic to PE2 since the IRB is asymmetric.
>  Cheers,
> Ali
>  From: RFC Errata System <[e-mail]>
> Date: Friday, February 9, 2024 at 1:23 PM
> To: [e-mail] <[e-mail]>, Ali Sajassi (sajassi) <[e-mail]>, Samer Salam (ssalam) <[e-mail]>, Samir Thoria (sthoria) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> Subject: [Errata Verified] RFC9135 (7683)
> The following errata report has been verified for RFC9135,
> "Integrated Routing and Bridging in Ethernet VPN (EVPN)". 
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7683
> 
> --------------------------------------
> Status: Verified
> Type: Technical
> 
> Reported by: Denis Vrkic <[e-mail]>
> Date Reported: 2023-10-19
> Verified by: John Scudder (IESG)
> 
> Section: 4.2.
> 
> Original Text
> -------------
>   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.
> 
> Corrected Text
> --------------
>   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
> 
> --------------------------------------
> 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