Subject: Re: [bess] WGLC , IPR and implementation poll for draft-ietf-bess-evpn-unequal-lb-03

From: <[email-masked]>
Date: Tue, 4 Feb 2020 14:54:07 +0100

This poll is now closed without any objection to progress.

However (expect if I have missed it), I haven't heard about any
implementation.

Is there any known implementation ? If NO, is the WG against progressing the
document without an implementation ?

Feedback required by the end of the week.

Thanks,

From: [email-masked] <[email-masked]> 
Sent: vendredi 17 janvier 2020 09:56
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: WGLC , IPR and implementation poll for
draft-ietf-bess-evpn-unequal-lb-03 

Hi WG,

This email starts a two weeks Working Group Last Call on
draft-ietf-bess-evpn-unequal-lb-03 [2]

Please review the draft and send any comments to the BESS list. Also, please
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Fri 31th January 2019.

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.  

We are also polling for any existing implementation as per [1]. Please
indicate if you are aware of any implementations.

 Thank you,

Stephane

[1]
<https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw>
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

[2]  <https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/>
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 4 Feb 2020 12:17:21 -0800

yes/support

Cheers,
Jeff
> From: BESS <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
> Date: Friday, January 17, 2020 at 12:56 AM
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: [bess] WGLC , IPR and implementation poll for draft-ietf-bess-evpn-unequal-lb-03
>
> Hi WG,
>
> This email starts a two weeks Working Group Last Call on draft-ietf-bess-evpn-unequal-lb-03 [2]
>
> Please review the draft and send any comments to the BESS list. Also, please indicate if you support publishing the draft as a standards track RFC.
>
> 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.
> We are also polling for any existing implementation as per [1]. Please indicate if you are aware of any implementations.
>  Thank you,
> Stephane
>
> [1] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> [2] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 7 Feb 2020 23:27:21 -0800

I decided to look at the draft and will send my mostly editorial comments
in a day or so.  Sorry for the delay.

But what I find really surprising is that the draft made it through WGLC
without IANA considerations or security considerations sections.  I thought
those were mandatory.  I haven't been to an IETF meeting in a while.  Has
something changed?

Anoop

On Tue, Feb 4, 2020 at 5:54 AM <[email-masked]> wrote:

> However (expect if I have missed it), I haven’t heard about any
> implementation.
>
>
>
> Is there any known implementation ? If NO, is the WG against progressing
> the document without an implementation ?
>
>
>
> *From:* [email-masked] <[email-masked]>
> *Sent:* vendredi 17 janvier 2020 09:56
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* WGLC , IPR and implementation poll for
> Please review the draft and send any comments to the BESS list. Also,
> please indicate if you support publishing the draft as a standards track
> RFC.
>
>
>
> 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).
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Sat, 8 Feb 2020 16:39:31 -0800

Here are my comments.

==

Procedural (Chairs can make a call on which of these must be addressed)

- Draft is missing IANA considerations and security considerations sections.
- 6 front page authors may cause issues as the draft moves forward.
- pg 8

It is work in progress with authors of [BGP-LINK-
BW] to allow for this attribute to be used as transitive in inter-AS
scenarios.

Has this issue been resolved?  It seems like it should be resolved one way
or another before the draft is allowed to progress to RFC.

Editorial

- general

Suggest adding a section for acronyms.  Many are used and they are not all
well known and some like BW have a new meaning in this draft.

Link bundle, LAG bundle, LAG are all used interchangeably.  Suggest use
only LAG.

Load balance, load-balance, load sharing, load-sharing used
interchangeably.  Suggest use "load balance" everywhere.

What is the difference between EXT-COMM and extended community?  Suggest
use "extended community" everywhere.

In the terminology section, "LOCAL" and "REMOTE" PE are defined, yet
throughout the doc, a mix of LOCAL/local and REMOTE/remote are used.
Suggest make consistent and use non-capitalized versions.  These are
well-understood terms.

- pg 2
There are 2 section 3.1's.

- pg 4
Missing period at end of 3rd bullet.

- pg 5
In title for section 1.1, "PE CE" -> "PE-CE"
"Consider a CE1" -> "Consider CE1"
"link bundle represented" -> "the LAG represented"
"it's bandwidth" -> "its bandwidth"
"it MUST add a link" -> "it must add a link"  (MUST should only be used for
something this spec is mandating, not an observation.)

- pg 6
"hosts MUST also be load-balanced" -> "hosts must also be load balanced"
(there are 2 instances of this, one at the top of the page, one at the
bottom)
In title for section 1.2, "PE CE" -> "PE-CE"

- pg 7
"with Lx being the number of links / bandwidth..." -> "with Lx being the
total bandwidth across all links..."
"Solution proposed..." -> "The solution proposed..."
"who's overlay..." -> "whose overlay"

-pg 8
"advertise a additional..." -> "advertise an additional..."

-pg 10
"link-bandwidth" -> "link bandwidth"

- pg 12
"compute a random hash..." -> "computes a random hash..."
"IP address of PE at ordinal i" -> "IP address of PE(i)"
"PE that has the highest hash..." -> "The PE that has the highest hash..."
"one per-bandwidth..." -> "one per bandwidth..."

- pg 14
"[WEIGHTED-HRW] document describes..." -> "[WEIGHTED-HRW] describes..."

- pg 16
"PE_CE" -> "PE-CE"
There appears to be a formatting issue with the 2nd bullet in section 6.
Missing periods at the end of the first 3 bullets.

- pg 17
Section 7 title "with non-EVPN routing" -> "With Non-EVPN Routing"
Missing periods at end of bullets.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Feb 2020 00:39:52 -0500

I support.  I think this is a very important feature that provides
flexibility to operators In upgrading edge bandwidth.  Sorry to chime in
late after the poll closed.

Since this draft is an introduction of a new feature to support EVPN
unequal load balancing,  have any vendors implemented this feature yet.

Also have any vendors see any issues with the evpn unequal cost lb solution
depiction in the draft.  I don’t know of any operators that have
implemented.

Kind regards

Gyan

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]