Re: [bess] WGLC, IPR and implementation poll on draft-ietf-bess-evpn-mh-pa-02

Hi Stefane,

Yes, the document is much improved.  There's the last exchange below which
I didn't get a response to.  I think that would help convey the intent of
the authors more clearly.

Thanks,
Anoop

On Mon, Nov 8, 2021 at 4:01 AM <slitkows.ietf@gmail.com> wrote:

> Anoop,
>
>
>
> Could you confirm that you are fine with the changes proposed by Luc, so
> we can move the draft forward to next steps ?
>
>
>
> Thanks !
>
>
>
>
>
> *From:* Anoop Ghanwani <anoop@alumni.duke.edu>
> *Sent:* lundi 5 juillet 2021 21:39
> *To:* Luc André Burdet <laburdet.ietf@gmail.com>
> *Cc:* slitkows.ietf@gmail.com; bess-chairs@ietf.org; BESS <bess@ietf.org>
> *Subject:* Re: [bess] WGLC, IPR and implementation poll on
> draft-ietf-bess-evpn-mh-pa-02
>
>
>
> 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 <laburdet.ietf@gmail.com>
> 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  |  laburdet.ietf@gmail.com  |  Tel: +1 613 254
> 4814
>
>
>
>
>
> *From: *BESS <bess-bounces@ietf.org> on behalf of Anoop Ghanwani <
> anoop@alumni.duke.edu>
> *Date: *Tuesday, June 1, 2021 at 19:23
> *To: *"slitkows.ietf@gmail.com" <slitkows.ietf@gmail.com>
> *Cc: *"bess-chairs@ietf.org" <bess-chairs@ietf.org>, BESS <bess@ietf.org>
> *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 <slitkows.ietf@gmail.com> 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
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
>