I support publication of this draft. EVPN MH port active active/backup MLAG is an important feature for operators.
Gyan On Mon, Jul 5, 2021 at 3:39 PM Anoop Ghanwani <[email protected]> wrote: > Thanks Luc. > > Would it be possible to add a line in section 4 along the lines of: > > "While the various algorithms for DF election are discussed in Sections > 4.2-4.4, unlike all-active load balancing, the choice of algorithm in this > solution doesn't impact performance in any way since there is only one > active link." > > Anoop > > On Mon, Jul 5, 2021 at 11:31 AM Luc André Burdet <[email protected]> > wrote: > >> Thank you for your careful review Anoop; >> >> I have uploaded -03 which I believe addresses all comments. >> >> >> >> Regarding the section specifying procedures for all DF Election >> algorithms: it is included per a previous review comment, primarily to be >> comprehensive for all existing DF Algos. I agree the *result* may >> generally not vary much but the details of the procedure need to be >> specified. I hope this clears up any confusion. >> >> >> >> Regards, >> >> Luc André >> >> >> >> Luc André Burdet | Cisco | [email protected] | Tel: +1 613 >> 254 4814 >> >> >> >> >> >> *From: *BESS <[email protected]> on behalf of Anoop Ghanwani < >> [email protected]> >> *Date: *Tuesday, June 1, 2021 at 19:23 >> *To: *"[email protected]" <[email protected]> >> *Cc: *"[email protected]" <[email protected]>, BESS <[email protected]> >> *Subject: *Re: [bess] WGLC, IPR and implementation poll on >> draft-ietf-bess-evpn-mh-pa-02 >> >> >> >> >> >> I support publication of this document. The following are my comments. >> >> >> >> == >> >> Abstract >> >> >> >> - I think it would be better to list the RFC rather than say "EVPN >> standard", since EVPN standard is an evolving term. >> >> - "support of port-active" -> "support for port-active" >> >> - The last line of the abstract should be moved to the introduction. >> >> >> >> Section 1 >> >> >> >> - "The determinism provided by active-standby per interface is also >> required for certain QOS features to work." >> >> Can you provide an example of this? >> >> - Change >> >> "A new term of load-balancing mode, port-active load- balancing is then >> defined." >> >> to >> >> "A new load-balancing mode, port-active load-balancing is defined." >> >> >> >> - Change >> >> "This draft describes how that new redundancy mode can be supported via >> EVPN" >> to >> "This draft describes how that new load balancing mode can be supported >> via EVPN" >> >> (Just for consistency, I think it would be better to search the >> doc throughout and make sure that "redundancy" is not being used in place >> of "load balancing", since we are defining a new load balancing method, not >> a new redundancy method/topology.) >> >> >> >> - Is "Bundle-Ethernet interfaces" a well-known term? I think it may be >> better to drop Bundle. I am not sure if what is meant here is "members of >> a LAG". >> >> >> >> - "multi-homing to CE" -> "multi-homing to the CE". >> >> >> >> Section 2 >> >> >> >> - Change >> >> "form a bundle and operate as a Link Aggregation Group (LAG)" >> >> to >> >> "form and operate as a Link Aggregation Group (LAG)" >> >> (In EVPN bundling normally refers to many:1 mapping of VLAN to >> VNI/service instance). >> >> >> >> - Include reference for ICCP. >> >> >> >> - Change >> >> "CE device connected to Multi-homing PEs may has" >> >> to >> >> "CE device connected to multi-homing PEs may have" >> >> >> >> - Change >> >> "Links in the Ethernet Bundle" >> >> to >> >> "links in the LAG" >> >> >> >> - Change >> >> "Any discrepancies from this list is left for future study." >> >> to >> >> "Any discrepancies from this list are left for future study." >> >> >> >> Section 3 >> >> >> >> - Missing period at the end of (b). >> >> >> >> - Layer2 attributes -> Layer-2 attributes. >> >> >> >> Section 4.2/4.3 >> >> >> >> I got a bit confused here. The draft discusses Modulo, HRW. Do we >> essentially end up with a single active link, but just that which link is >> chosen is dependent on the algorithm? If so, what is the benefit of doing >> so? I can see why multiple algorithms are of value when we are doing >> VLAN-based load balancing to multiple active links. >> >> >> >> Section 5 >> >> >> >> - "Bundle-Ethernet" -> "LAG" >> >> >> >> Section 5.1 >> >> >> >> - "per ES routes for fast convergence" -> "per ES route for fast >> convergence" >> >> >> >> Section 5.2 >> >> >> >> - "per EVI routes" -> "per EVI route" >> >> >> >> Section 7 >> >> >> >> - spurious 'g'. >> >> >> >> - missing period under the second sub-bullet of point 'f'. >> >> >> >> >> >> On Mon, May 31, 2021 at 12:31 AM <[email protected]> wrote: >> >> Hello WG, >> >> >> >> >> >> This email starts a two weeks Working Group Last Call on >> >> draft-ietf-bess-evpn-mh-pa-02 [1]. >> >> >> >> >> >> This poll runs until * the 7th of June *. >> >> >> >> >> >> 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. The Document won't progress without answers from >> >> all the Authors and Contributors. >> >> >> >> There is currently no IPR disclosed. >> >> >> >> >> >> 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. >> >> >> >> >> >> We are also polling for any existing implementation as per [2]. >> >> >> >> >> >> Thank you, >> >> >> >> Stephane & Matthew >> >> >> >> >> >> [1] >> >> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-pa/ >> >> >> >> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw >> >> >> >> _______________________________________________ >> BESS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bess >> >> _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
