Hi Muthu,
(Speaking as co-chair) Thanks for the feedback on the intended status. This has to be clarified however this is not a blocking point for the adoption. We have time to figure out the intended status of the document with the authors/WG and adjust the text accordingly. Brgds, Stephane From: Muthu Arul Mozhi Perumal <[email protected]> Sent: vendredi 23 avril 2021 13:15 To: [email protected] Cc: [email protected]; [email protected] Subject: Re: [bess] WG and IPR poll adoption poll for draft-krattiger-evpn-modes-interop I support the adoption. However, have a few comments: The intended status of the draft is Informational, but it doesn't look right. The abstract says: This document specifies how the different EVPN functional modes and types can interoperate with each other. This document doesn't aim to redefine the existing functional modes but extend them for interoperability. In addition, the draft has multiple normative statements. Hence, believe the intended status should be standards track instead.. Section 4.2 says: With PE2 operating in Symmetric IRB and with enabled interop mode, the MAC/IP route from PE1 (Asymmetric IRB) is processed in the respective bridging, routing and adjacency table. Based on the Route- Target for MAC-VRF1, the MAC address M1 will be imported into MAC- VRF1 respectively and placed within BD0. In addition, the host- binding information M1/IP1 MUST be installed within PE2s adjacency table. For a PE operating in symmetric IRB mode, it is not required to install M1/P1 in the ARP/ND/adjacency table as per draft-ietf-bess-evpn-inter-subnet-forwarding. Hence, I think this draft is updating/extending draft-ietf-bess-evpn-inter-subnet-forwarding. The draft has the foll. description for Figure 2: The IRB interfaces for a common MAC-VRF/BD on PE1 and PE2 use the same IP address. With the difference of the IRB modes between PE1 (Asymmetric IRB) and PE2 (Symmetric IRB), there is a difference in the MPLS Label presence as part of the MAC/IP routes exchanged between the PEs. I guess it should say "same IP address and MAC address". Otherwise, it is not necessary to install M1/P1 in PE2's adj table. If PE2 receives a packet destined to P1, PE2 will initiate a glean procedure causing the host having (M1, P1) to respond. The response will reach PE2, so PE2 will install in its adjacency. The problem occurs only when both PE1 and PE2 use the same anycast default gateway IP and MAC addresses (which is also the recommended option as per draft-ietf-bess-evpn-inter-subnet-forwarding), in which case the response from the host will be locally consumed by PE1. Regards, Muthu On Mon, Apr 19, 2021 at 11:36 PM <[email protected] <mailto:[email protected]> > wrote: Hello, This email begins a two-weeks WG adoption poll for draft-krattiger-evpn-modes-interop-03 [1]. Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document will not progress without answers from all of the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 4th May 2021. Regards, Matthew and Stephane [1] https://datatracker.ietf.org/doc/draft-krattiger-evpn-modes-interop/ _______________________________________________ BESS mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
