Re: [bess] [Errata Verified] RFC9135 (7683)
Hi John I agree that there is a typo and that needs to be corrected (i.e., s/PE2/PE1 in line 4). With respect to “Notes”, I am not sure if I am reading it incorrectly: > Notes > - > PE1 will use ARP table for forwarding traffic to PE2 - seems like typo I am reading it as there is a “typo” in the statement but the above statement is correct! So, I don’t know why the commentator added “- seems like typo”! Cheers, Ali From: John Scudder Date: Monday, February 12, 2024 at 10:14 AM To: Ali Sajassi (sajassi) Cc: bess@ietf.org , The IESG , rfc-edi...@rfc-editor.org Subject: Re: [Errata Verified] RFC9135 (7683) 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) > 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 > Date: Friday, February 9, 2024 at 1:23 PM > To: vrkic.de...@gmail.com , Ali Sajassi (sajassi) > , Samer Salam (ssalam) , Samir Thoria > (sthoria) , jdr...@juniper.net , > jorge.raba...@nokia.com > Cc: j...@juniper.net , i...@ietf.org , > bess@ietf.org , i...@iana.org , > rfc-edi...@rfc-editor.org > 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 > 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 ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] [Errata Verified] RFC9135 (7683)
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) > 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 > Date: Friday, February 9, 2024 at 1:23 PM > To: vrkic.de...@gmail.com , Ali Sajassi (sajassi) > , Samer Salam (ssalam) , Samir Thoria > (sthoria) , jdr...@juniper.net , > jorge.raba...@nokia.com > Cc: j...@juniper.net , i...@ietf.org , > bess@ietf.org , i...@iana.org , > rfc-edi...@rfc-editor.org > 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 > 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 ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] [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 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 ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] [Errata Verified] RFC9135 (7683)
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 Date: Friday, February 9, 2024 at 1:23 PM To: vrkic.de...@gmail.com , Ali Sajassi (sajassi) , Samer Salam (ssalam) , Samir Thoria (sthoria) , jdr...@juniper.net , jorge.raba...@nokia.com Cc: j...@juniper.net , i...@ietf.org , bess@ietf.org , i...@iana.org , rfc-edi...@rfc-editor.org 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 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 ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
