Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-unequal-lb-18

[Dhruv Dhody]

Hi Neeraj,

On Wed, Dec 6, 2023 at 2:19 AM Neeraj Malhotra (nmalhotr) <
nmalh...@cisco.com> wrote:

>
>
> Hi Dhruv,
>
>
>
> rev20 incorporates all of the additional points below.
>
>
>
> Regarding,
>
>
>
> “* In cases where allocations are already made under FCFS, please state
> that
> instead of asking IANA to make the allocation again!”
>
>
>
> I am not aware of any allocations that have already been made. Have
> updated the text in this section (now section 10) to call out all requested
> allocations as “suggested” values.
>
>
>
> Please do let me know in case you see anything else missing.
>
>
>

Dhruv: See
https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn

0x10 EVPN Link Bandwidth Extended Community [
draft-ietf-bess-evpn-unequal-lb-15
] 2022-03-11

Thus, this text needs to change --

A new EVPN Link Bandwidth extended community is defined to signal local ES
> link bandwidth to ingress PEs. This extended community is defined of type
> 0x06 (EVPN). IANA is requested to assign a suggested sub-type value of 0x10
> for the EVPN Link bandwidth extended community, of type 0x06 (EVPN). EVPN
> Link Bandwidth extended community is defined as transitive.¶



It would also be a good idea to clearly identify the registry here "EVPN
Extended Community Sub-Types".

Thanks!
Dhruv



> Thanks,
>
> Neeraj
>
>
>
> *From: *Dhruv Dhody 
> *Date: *Monday, December 4, 2023 at 11:36 PM
> *To: *Neeraj Malhotra (nmalhotr) 
> *Cc: *rtg-...@ietf.org , bess@ietf.org ,
> draft-ietf-bess-evpn-unequal-lb@ietf.org <
> draft-ietf-bess-evpn-unequal-lb@ietf.org>
> *Subject: *Re: Rtgdir early review of draft-ietf-bess-evpn-unequal-lb-18
>
> Thanks Neeraj! Thanks for taking my comments into consideration!
>
> Looking at -19 some additional points!
>
> - No reference should be added in the abstract
> - Note to the IESG in the abstract, can be moved to the shepherd report
> and provided the assigned shepherd agrees with your justification.
> - s/advertisong/advertising/
> - I am worried about the use of "operators SHOULD" in Section 8 i.e. we
> are using SHOULD for how operators need to behave instead of how the
> implementations ought to handle these operational issues.
> - This is missed:
> ### Section 14
>
> * In cases where allocations are already made under FCFS, please state that
> instead of asking IANA to make the allocation again!
>
> Thanks!
> Dhruv
>
>
>
>
>
> On Tue, Dec 5, 2023 at 8:08 AM Neeraj Malhotra (nmalhotr) <
> nmalh...@cisco.com> wrote:
>
>
>
> Hi Dhruv,
>
>
>
> Many thanks for a very detailed review and comments. I have just published
> version 19 that significantly revises the document to incorporate all of
> your comments as well as comments from Genart early review. Please see
> additional clarifications inline below. Please do let me know in case you
> see anything else outstanding.
>
>
>
> Thanks,
>
> Neeraj
>
>
>
>
>
> ## Comments:
>
> ### General
>
> * Request the shepherd to make sure that there is a valid justification
> for 6
> authors. Better yet just make it 5 authors (you have 3 authors from the
> same
> affiliation and one author marked as editor)
>
> [NM]: added justification for 6 authors.
>
> * Please follow the RFC style guide. For instance, the Introduction should
> be
> the first section as per -
> https://www.rfc-editor.org/rfc/rfc7322.html#section-4.8.1. The best would
> be to
> have a new Introduction section that briefly introduces the concept and
> change
> section 2 to "Motivation" or something like that.
>
> [NM]: done
>
>
> * Use of some words in all capital letters -  OR, ALL, NOT. This should be
> avoided so as not to confuse with RFC2119 keywords which have special
> meaning
> when in capital.
>
> [NM]: done
>
> * The documents should add references to relevant RFCs when talking about
> existing EVPN features.
> * IRB
> *
>
> [NM]: done
>
>
> ### Section 1
>
> * Please update the Requirements Language template to -
> 
>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>"OPTIONAL" in this document are to be interpreted as described in
>BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>capitals, as shown here.
> 
>
> [NM]: done
>
>
> * Please add references for the terms where possible. Definitions such as
> "Egress PE" and "Ingress PE" refer to RT-1, RT-2, and RT-5 especially needs
> one. Also, can the local PE and Ingress PE be different?
>
> [NM]: done. Made the terminology consistent to use “Ingress/Egress PE” and
> removed “Local/Remote PE” terminology.
>
> ### Section 4
>
> * Why SHOULD and not MUST in -
> 
> Implementations SHOULD support the default units of Mbps
> 
>
> [NM]: done. Corrected to MUST.
>
>
> * IMHO section 4.2 is better suited in the appendix
>
> [NM]: done
>
> ### Section 5
>
> * Section 5.1; Why SHOULD and 

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-unequal-lb-18

[Neeraj Malhotra (nmalhotr)]

Hi Dhruv,

rev20 incorporates all of the additional points below.

Regarding,

“* In cases where allocations are already made under FCFS, please state that
instead of asking IANA to make the allocation again!”

I am not aware of any allocations that have already been made. Have updated the 
text in this section (now section 10) to call out all requested allocations as 
“suggested” values.

Please do let me know in case you see anything else missing.

Thanks,
Neeraj

From: Dhruv Dhody 
Date: Monday, December 4, 2023 at 11:36 PM
To: Neeraj Malhotra (nmalhotr) 
Cc: rtg-...@ietf.org , bess@ietf.org , 
draft-ietf-bess-evpn-unequal-lb@ietf.org 

Subject: Re: Rtgdir early review of draft-ietf-bess-evpn-unequal-lb-18
Thanks Neeraj! Thanks for taking my comments into consideration!

Looking at -19 some additional points!

- No reference should be added in the abstract
- Note to the IESG in the abstract, can be moved to the shepherd report and 
provided the assigned shepherd agrees with your justification.
- s/advertisong/advertising/
- I am worried about the use of "operators SHOULD" in Section 8 i.e. we are 
using SHOULD for how operators need to behave instead of how the 
implementations ought to handle these operational issues.
- This is missed:
### Section 14

* In cases where allocations are already made under FCFS, please state that
instead of asking IANA to make the allocation again!

Thanks!
Dhruv


On Tue, Dec 5, 2023 at 8:08 AM Neeraj Malhotra (nmalhotr) 
mailto:nmalh...@cisco.com>> wrote:

Hi Dhruv,

Many thanks for a very detailed review and comments. I have just published 
version 19 that significantly revises the document to incorporate all of your 
comments as well as comments from Genart early review. Please see additional 
clarifications inline below. Please do let me know in case you see anything 
else outstanding.

Thanks,
Neeraj



## Comments:

### General

* Request the shepherd to make sure that there is a valid justification for 6
authors. Better yet just make it 5 authors (you have 3 authors from the same
affiliation and one author marked as editor)
[NM]: added justification for 6 authors.

* Please follow the RFC style guide. For instance, the Introduction should be
the first section as per -
https://www.rfc-editor.org/rfc/rfc7322.html#section-4.8.1. The best would be to
have a new Introduction section that briefly introduces the concept and change
section 2 to "Motivation" or something like that.
[NM]: done

* Use of some words in all capital letters -  OR, ALL, NOT. This should be
avoided so as not to confuse with RFC2119 keywords which have special meaning
when in capital.
[NM]: done

* The documents should add references to relevant RFCs when talking about
existing EVPN features.
* IRB
*
[NM]: done

### Section 1

* Please update the Requirements Language template to -

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

[NM]: done

* Please add references for the terms where possible. Definitions such as
"Egress PE" and "Ingress PE" refer to RT-1, RT-2, and RT-5 especially needs
one. Also, can the local PE and Ingress PE be different?
[NM]: done. Made the terminology consistent to use “Ingress/Egress PE” and 
removed “Local/Remote PE” terminology.

### Section 4

* Why SHOULD and not MUST in -

Implementations SHOULD support the default units of Mbps

[NM]: done. Corrected to MUST.

* IMHO section 4.2 is better suited in the appendix
[NM]: done

### Section 5

* Section 5.1; Why SHOULD and not MUST?
[NM]: done. Corrected to MUST.

* Section 5.1; Consider adding the reasoning behind

   EVPN link bandwidth extended community SHOULD NOT be attached to per-
   EVI RT-1 or to EVPN RT-2.

[NM]: done

* Section 5.2; If the extended commuity is silently ignored, how would an
operator learn about it? At least a requirement for a log should be added. *
[NM]: done

Section 5.2; How is the weighted path list computed when the normalized weight
is in fractions i.e. L(1, 10) = 2500 Mbps and thus W(1, 10) = 2.5? I am
guessing you assume it is an integer (same as BW Increment) but it is not
stated.
[NM]: The method in this section is only an example. Weighted pathlist 
computation is a local implementation choice. That said, divide by HCF method 
in this example will always result in integer weights, although the computed 
weight values using this example method may not always to be reasonably 
programmed in HW. I have added another paragraph to explicitly clarify this as 
well as that this is an implementation choice.

### Section 6

* The update procedure listed here "updates" other specifications. I wonder if
this should be captured in metadata, abstract etc.
[NM]: Added additional text to abstract.

* 

[bess] I-D Action: draft-ietf-bess-evpn-unequal-lb-20.txt

[internet-drafts]

Internet-Draft draft-ietf-bess-evpn-unequal-lb-20.txt is now available. It is
a work item of the BGP Enabled ServiceS (BESS) WG of the IETF.

   Title:   Weighted Multi-Path Procedures for EVPN Multi-Homing
   Authors: Neeraj Malhotra
Ali Sajassi
Jorge Rabadan
John Drake
Avinash Lingala
Samir Thoria
   Name:draft-ietf-bess-evpn-unequal-lb-20.txt
   Pages:   22
   Dates:   2023-12-05

Abstract:

   EVPN enables all-active multi-homing for a CE (Customer Equipment)
   device connected to two or more PE (Provider Equipment) devices via a
   LAG (Link Aggregation), such that bridged and routed traffic from
   remote PEs to hosts attached to the Ethernet Segment can be equally
   load balanced (it uses Equal Cost Multi Path) across the multi-homing
   PEs.  EVPN also enables multi-homing for IP subnets advertised in IP
   Prefix routes, so that routed traffic from remote PEs to those IP
   subnets can be load balanced.  This document defines extensions to
   EVPN procedures to optimally handle unequal access bandwidth
   distribution across a set of multi-homing PEs in order to:

   *  provide greater flexibility, with respect to adding or removing
  individual multi-homed PE-CE links.

   *  handle multi-homed PE-CE link failures that can result in unequal
  PE-CE access bandwidth across a set of multi-homing PEs.

   In order to achieve the above, it specifies signaling extensions and
   procedures to:

   *  Loadbalance bridged and routed traffic across egress PEs in
  proportion to PE-CE link bandwidth or a generalized weight
  distribution.

   *  Achieve BUM (Broadcast, UnknownUnicast, Multicast) DF (Designated
  Forwarder) election distribution for a given ES (Ethernet Segment)
  across the multi-homing PE set in proportion to PE-CE link
  bandwidth.  Section 6 of this document further updates RFC 8584,
  draft-ietf-bess-evpn-per-mcast-flow-df-election and draft-ietf-
  bess-evpn-pref-df in order for the DF election extension defined
  in this document to work across different DF election algorithms.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-20

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-unequal-lb-20

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess