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
>