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

[Neeraj Malhotra (nmalhotr)]

Hi,

Thanks Dhruv for the pointer (did not notice earlier that this was already 
allocated). Fixed in rev21.

Thanks,
Neeraj

From: Dhruv Dhody 
Date: Tuesday, December 5, 2023 at 8:12 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
Hi Neeraj,

On Wed, Dec 6, 2023 at 2:19 AM Neeraj Malhotra (nmalhotr) 
mailto: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<https://www.iana.org/go/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 mailto:d...@dhruvdhody.com>>
Date: Monday, December 4, 2023 at 11:36 PM
To: Neeraj Malhotra (nmalhotr) mailto:nmalh...@cisco.com>>
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org> 
mailto:rtg-...@ietf.org>>, 
bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-ietf-bess-evpn-unequal-lb@ietf.org<mailto:draft-ietf-bess-evpn-unequal-lb@ietf.org>
 
mailto: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

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 

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

[Neeraj Malhotra (nmalhotr)]

Hi Mallory,

Many thanks for the review and comments. Rev 19 of the document (just 
published) incorporates your comments below along with additional comments from 
Rtgdir early review. Please do let me know if you see anything else outstanding.

Thanks,
Neeraj

From: Mallory Knodel via Datatracker 
Date: Thursday, November 16, 2023 at 10:13 AM
To: gen-...@ietf.org 
Cc: bess@ietf.org , draft-ietf-bess-evpn-unequal-lb@ietf.org 

Subject: Genart early review of draft-ietf-bess-evpn-unequal-lb-18
Reviewer: Mallory Knodel
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. Please resolve these
comments along with any other comments you may receive.

For more information, please see the FAQ at
.

Document: draft-ietf-bess-evpn-unequal-lb
Reviewer: Mallory Knodel
Review Date: 16 Nov 2023

Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication.

Major issues: Section 3 as the Solution Overview seems out of step with the
remaining sections in that it properly describes the relationships between 4, 5
and 6, but it appears that 7-10 are additional over arching considerations that
might benefit from being extracted from the discussion of direct solutions.
Suggesting perhaps that 4, 5 and 6 be treated under the solution space, whereas
the remaining substantive sections 7-10 be presented as additional
considerations and tradeoffs but not direct descriptions of full solutions to
the problems outlined in the introduction.

Minor issues: Not all acronyms are properly expanded in order of their
first-time use which hinders readability. Seems 12. Operational Considerations
is superfluous and plenty of document dependencies also do not have this
section.

Nits/editorial comments: The focus of my review did not expose any
nits/editorial comments though I believe there are some that have persisted
across the various versions that I compared and I would encourage the authors
to do a full copy edit ahead of IESG submission.

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

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

[Neeraj Malhotra (nmalhotr)]

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.

* Section 6.3.1,
* Change L(min) to Lmin t to not be conffused by L(i)
[NM]: done.

* I am unsure of what you mean by "with PE(1) = 10, PE(2) = 10, PE(3) = 20"
which later changes to "with PE(1) = 10, PE(2) = 10, PE(3) = 10" * Other
documents do not use the word affinity, it was difficult for me to verify
the affinity formula and I left that for the WG to verify for correctness.
[NM]: fixed.

* Inconsistency between MUST and MAY -

   Depending on the chosen HRW hash function, the affinity function MUST be
   extended to include bandwidth increment in the computation.

   affinity function specified in [EVPN-PER-MCAST-FLOW-DF] MAY be
   extended as follows to incorporate bandwidth increment j:

   affinity or random function specified in [RFC8584] MAY be extended as
   follows to incorporate bandwidth increment j:

[NM]: fixed.

* Section 6.4, asks to add a new bullet (f) in
https://www.ietf.org/archive/id/draft-ietf-bess-evpn-pref-df-13.html#section-4.1
; Note that there is already a bullet f there!
[NM]: This section updates bullet f in [EVPN-PREF-DF]. I have updated the text 
to clearly state that.

### Section 9

* What should be the value-units in this case to be interpreted as relative
weight?
[NM]: 0x01. Added text to state that (this is now section 7.2 in rev19).

### Section 12

* Isn't there operation issues with the correct settings of "value-units" for
Generalized weight? How does an operator learn about the inconsistency? How
does the operator know this 

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

[Neeraj Malhotra]

Hi,

Support adoption.

Thanks,
Neeraj

On Mon, Nov 13, 2023 at 3:51 AM Jeffrey (Zhaohui) Zhang  wrote:

> Hi,
>
> This email begins a two-week WG adoption and IPR poll for
> draft-sajassi-bess-evpn-ip-aliasing-09 (
> https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-09
> ).
>
> Please review the draft and post any comments to the BESS working group
> list.
>
> 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, copying the BESS mailing list. The document will
> not progress without answers from all the authors and contributors.
>
> If you are not listed as an author or a contributor, then please
> explicitly respond to the IPR poll only if you are aware of any IPR that
> has not yet been disclosed in conformance with IETF rules.
>
> This poll for adoption closes on Monday, 27th of November, 2023.
>
> Thanks.
> Jeffrey
>
> Juniper Business Use Only
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Neeraj Malhotra]

Hi Dhruv,

Many thanks for the review. Will update the draft and respond by next week.

Thanks,
Neeraj

On Thu, Nov 16, 2023 at 3:01 AM Dhruv Dhody via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Dhruv Dhody
> Review result: Has Issues
>
> # RTGDIR review of draft-ietf-bess-evpn-unequal-lb-18
>
> Hello,
>
> I have been selected to do a routing directorate “early” review of this
> draft.
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
>
> The routing directorate will, on request from the working group chair,
> perform
> an “early” review of a draft before it is submitted for publication to the
> IESG. The early review can be performed at any time during the draft’s
> lifetime
> as a working group document. The purpose of the early review depends on the
> stage that the document has reached. As this document is
> post-working-group-last-call, my focus for the review was to determine
> whether
> the document is ready to be published.
>
> For more information about the Routing Directorate, please see
> https://wiki.ietf.org/en/group/rtg/RtgDir
>
> Document: draft-ietf-bess-evpn-unequal-lb-18
> Reviewer: Dhruv Dhody
> Review Date: 16 Nov 2023
> Intended Status: Standards Track
>
> ## Summary:
>
> The motivation for the draft is clear and described well. However, I have
> significant concerns about this document. It needs more work before being
> submitted to the IESG.
>
> ## 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)
>
> * 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.
>
> * 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.
>
> * The documents should add references to relevant RFCs when talking about
> existing EVPN features.
> * IRB
> *
>
> ### 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.
> 
> * 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?
>
> ### Section 4
>
> * Why SHOULD and not MUST in -
> 
> Implementations SHOULD support the default units of Mbps
> 
> * IMHO section 4.2 is better suited in the appendix
>
> ### Section 5
>
> * Section 5.1; Why SHOULD and not 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.
> 
> * 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.
> *
> 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.
>
> ### Section 6
>
> * The update procedure listed here "updates" other specifications. I
> wonder if
> this should be captured in metadata, abstract etc.
>
> * Section 6.3.1,
> * Change L(min) to Lmin t to not be conffused by L(i)
> * I am unsure of what you mean by "with PE(1) = 10, PE(2) = 10, PE(3)
> = 20"
> which later changes to "with PE(1) = 10, PE(2) = 10, PE(3) = 10" *
> Other
> documents do not use the word affinity, it was difficult for me to
> verify
> the affinity formula and I left that for the WG to verify for
> correctness.
> * Inconsistency between MUST and MAY -
> 
>Depending on the chosen HRW hash function, the affinity function MUST be
>extended to include bandwidth increment in the computation.
>
>affinity function specified in [EVPN-PER-MCAST-FLOW-DF] MAY be
>extended as follows to incorporate bandwidth increment j:
>
>affinity or random function specified in [RFC8584] MAY be extended as
>follows to incorporate bandwidth increment j:
> 
>
> * Section 6.4, asks to add a new bullet (f) in
>
> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-pref-df-13.html#section-4.1
> ; Note that there is already a bullet f there!
>
> ### Section 9
>
> * What should be the 

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

[Neeraj Malhotra]

Hi Mallory,

Many thanks for the review. Will update the draft and respond by next week.

Thanks,
Neeraj

On Thu, Nov 16, 2023 at 10:13 AM Mallory Knodel via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Mallory Knodel
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. Please resolve these
> comments along with any other comments you may receive.
>
> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-bess-evpn-unequal-lb
> Reviewer: Mallory Knodel
> Review Date: 16 Nov 2023
>
> Summary: This draft is basically ready for publication, but has nits that
> should be fixed before publication.
>
> Major issues: Section 3 as the Solution Overview seems out of step with the
> remaining sections in that it properly describes the relationships between
> 4, 5
> and 6, but it appears that 7-10 are additional over arching considerations
> that
> might benefit from being extracted from the discussion of direct solutions.
> Suggesting perhaps that 4, 5 and 6 be treated under the solution space,
> whereas
> the remaining substantive sections 7-10 be presented as additional
> considerations and tradeoffs but not direct descriptions of full solutions
> to
> the problems outlined in the introduction.
>
> Minor issues: Not all acronyms are properly expanded in order of their
> first-time use which hinders readability. Seems 12. Operational
> Considerations
> is superfluous and plenty of document dependencies also do not have this
> section.
>
> Nits/editorial comments: The focus of my review did not expose any
> nits/editorial comments though I believe there are some that have persisted
> across the various versions that I compared and I would encourage the
> authors
> to do a full copy edit ahead of IESG submission.
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comments on draft-malhotra-bess-evpn-centralized-anycast-gw

[Neeraj Malhotra (nmalhotr)]

Hi Jorge,

Many thanks for the review. Please see inline:


# Major comment: I believe section 5.1 is not correct:

“... GW MAC/IP MUST be advertised with a higher sequence number. ...”

And as per draft 7432bis:

“MAC Mobility extended community SHALL NOT be attached to routes which also 
have Default Gateway extended community on the sending side and SHALL be 
ignored on the receiving side.”

And section 7.13.1 in the 7432bis takes care of the GW MAC/IPs being protected 
and not subject to mobility. So IMHO the entire section 5.1 is not needed.

[NM]: Thanks for pointing me to this section. I do see that the need for 
sequence number can be avoided as per 7432bis. However, while 7432bis takes 
care of BGP best path selection, arbitration across local, bgp, and static 
route producers for the purpose of selecting the route to be installed in 
forwarding usually happens outside of BGP (in L2RIB). Section 5.1 is intended 
to ensure that a locally learnt MAC will not take precedence over BGP produced 
GW MAC route in the forwarding table. That said, one could arguably assume that 
the BGP best path selection in 7432bis implies forwarding route selection 
across bgp and local producers as well. Let me discuss with other co-authors 
and try to align this section with 7432bis in the next revision.

# Minor comments:

## If section 5.1 was the only new extension to EVPN, then it is not needed and 
the draft can be Informational?

[NM]: Besides section 5.1, there are procedures for L2 PE and CAG PE specified 
in section 3, for e.g., use of ARP snooping on L2 PEs to avoid ARP/ND sync. As 
well as re-origination procedures between L2-only fabric and Symmetric IRB 
fabric in section 6.1.1. While there isn’t any new specification for anything 
on the wire, L2-PE and CAG PE need to locally implement these procedures for 
the solution to work end to end. That seems like a standards track to me, but 
open to more input – will also discuss with co-authors.

## The following text:

”Optionally, the CAG IRB nodes may also have directly connected end-points.”

And this one:

“In case of VXLAN encapsulation, set of redundant CAG PEs provisioned as FHR 
for a common set of subnets MAY advertise the anycast GW MAC/IP RT-2 with an 
anycast VTEP IP as the next-hop.”

Are not really compatible. So you should consider to explain that single-homed 
local CAG ACs are only possible if anycast VTEPs are NOT used.

[NM]: Sure, makes sense. will clarify in the next revision that single homed 
local end-points are advertised with PIP as the next-hop VTEP.

## section 6.1.3 on split horizon groups on the CAGs should just follow 
RFC9014. I don’t think there is any new procedure here?

[NM]: ack. Will add a reference to RFC9014.


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

Re: [bess] A question about draft-sajassi-bess-evpn-l3-optimized-irb

[Neeraj Malhotra]

Hi Ali, Sasha,

minor comment in case it wasn't already clear - each PE still learns all
MACs in the control plane (for mobility procedures to work) but only
locally connected MACs are installed in the forwarding plane. Hence the
optimization. Ali, please confirm.

Thanks,
Neeraj

On Mon, Nov 6, 2023 at 11:37 AM Ali Sajassi (sajassi)  wrote:

> Hi Sasha,
>
>
>
> Each PE only learns local MAC addresses and NOT remote ones. So, lets says
> you have a subnet that is stretched across 10 PEs and each PE has 100
> locally connected hosts. So, the total number of MAC addresses for the
> subnet is 1000 (10X100) but each PE ONLY learns 100 MAC addresses. This is
> in contrast with the traditional EVPN-IRB where each PE learns all 1000 MAC
> addresses.
>
>
>
> Cheers,
>
> Ali
>
>
>
> *From: *BESS  on behalf of Alexander Vainshtein <
> alexander.vainsht...@rbbn.com>
> *Date: *Monday, November 6, 2023 at 5:31 AM
> *To: *draft-sajassi-bess-evpn-l3-optimized-...@ietf.org <
> draft-sajassi-bess-evpn-l3-optimized-...@ietf.org>
> *Cc: *bess@ietf.org , Nitsan Dolev 
> *Subject: *[bess] A question about
> draft-sajassi-bess-evpn-l3-optimized-irb
>
> Hi,
>
> This the question I have tried to ask during the meeting.
>
>
>
> The Introduction to draft in question
> 
>  claims “improving MAC scalability of customer bridges and PE devices
> significantly”.
>
> The first of these claims is easy to understand: each specific CE switch
> has to learn just one MAC address (that of the optimized IRB) in addition
> to MAC addresses of its locally attached hosts.
>
>
>
> But I have doubts about the second of these claims: to the best of my
> understanding, each PE attached to the subnet in question will learn MAC
> addresses of all attached hosts in the subnet.
>
>
>
> What, if anything, did I miss?
>
>
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
>
>
>
>
> *Disclaimer*
>
> This e-mail together with any attachments may contain information of
> Ribbon Communications Inc. and its Affiliates that is confidential and/or
> proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15

[Neeraj Malhotra (nmalhotr)]

Hi Stephane,

Thanks for catching all of these – have addressed them in rev17.

Regarding,

Section 5.1:
[SLI] I have a philosophical issue with the parent/child relationship you 
describe. If MAC is parent of MAC-IP, how could MAC be truly optional as a 
child cannot exist without its parent.

[NM]: child -> parent relationship explained in “section 5.1 Sequence number 
Inheritance” is a local view of a PE that *does* maintain both local MAC and 
local MAC-IP routes with corresponding sequence number attributes. Local MAC 
itself is NOT optional on a PE. It is only a separate advertisement of this MAC 
to other PEs that is optional (since the MAC reachability is already signaled 
together with MAC-IP route). I have updated the text in “section 3.1 Optional 
MAC Only RT-2” and “section 5.1 Sequence number Inheritance” to explicitly 
clarify this. Hope, this makes sense.

Thanks,
Neeraj

From: slitkows.i...@gmail.com 
Date: Monday, October 16, 2023 at 8:14 AM
To: Neeraj Malhotra (nmalhotr) , Stephane Litkowski 
(slitkows) , 
draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org 
, bess@ietf.org 

Cc: bess-cha...@ietf.org 
Subject: RE: Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15
Hi Neeraj,

Thanks for the updates.

Couple new « mistakes »:

  *   Abstract should not use xtarget references, you could use “RFC7432” as 
plain text but not using the reference tag. You should also not use normative 
language “IS REQUIRED” in the abstract.
  *   Introduction: s/envoronments/environment and 
s/containairized/containerized (same issue in terminology section)
  *   In Section 1.1, I think your section reference haven’t followed the new 
structure. Section 6 should be Section 4, Section 8 should be Section 6.

Few things, not addressed or that needs explanation:

Section 6.3:
[SLI] s/is required/IS REQUIRED

Section 6.5
“If this is a SYNCed MAC-IP on a local ES, it would also result in a derived 
SYNC MAC Mx route entry”
[SLI] I find the beg of the sentence of bit weird, could you improve it ?
[SLI2] The “If this is a” doesn’t sound good for a written document and not 
accurate enough. Could we say “ On receiving a” ?

Section 5.1:
[SLI] I have a philosophical issue with the parent/child relationship you 
describe. If MAC is parent of MAC-IP, how could MAC be truly optional as a 
child cannot exist without its parent.

Section 11:
You missed a “e” at the end of Patrice’s last name.
[SLI] My mistake, there was also a “t” missing: should be  “Brissette”

Brgds,

Stephane

From: Neeraj Malhotra (nmalhotr) 
Sent: Thursday, October 12, 2023 12:53 AM
To: Stephane Litkowski (slitkows) ; 
draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15


Hi Stephane,

Many thanks for the detailed review and comments. Have updated the document 
addressing all of the comments below.

Specifically regarding the issue of referencing rfc7432 or rfc7432bis, I have 
modified the reference to be on rfc7432 since existing 7432 is sufficient as a 
reference for all procedures covered in this document and it alleviates 
unnecessary dependency on publication of 7432bis.

Thanks,
Neeraj

From: Stephane Litkowski (slitkows) 
mailto:slitk...@cisco.com>>
Date: Wednesday, October 11, 2023 at 6:14 AM
To: 
draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org<mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org>
 
mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org>>,
 bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> 
mailto:bess-cha...@ietf.org>>
Subject: Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15
Hi Authors,

Please find below my review of the latest version of the draft:


Abstract:
The abstract refers to RFC7432bis but don’t make RFC7432bis as normative 
reference and also drafts is marked as updating RFC7432.
Here you should make a choice, either you base the draft on RFC7432 and not 
mention RFC7432bis, or base your draft on RFC7432bis, but then you should make 
it normative ref.
As a consequence, you’ll have a downref until RFC7432bis is published. I think 
this is a major issue that needs to be solved before moving fwd.


Introduction:
“EVPN-IRB enables advertising…”.
[SLI] Were you expecting to put a reference here instead of EVPN-IRB ? While 
EVPN and IRB are considered as well known, EVPN-IRB is a bit weird. But I guess 
it’s a reference to RFC9135. If yes, this must be modified. I would potentially 
right it as “EVPN IRB ([RFC9135]) enables…”. We need to have the reference 
immediately, not only at the end. Also in the document, you should choose 
between EVPN IRB and EVPN-IRB. Unfortunately, I see that RFC9135 is not 
consistent  But it’s good to have consistency here.



“While a fixed 1:1 mapping between IP and MAC is a common use case that is 
addressed via existing MAC

Re: [bess] Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15

[Neeraj Malhotra (nmalhotr)]

Hi Stephane,

Many thanks for the detailed review and comments. Have updated the document 
addressing all of the comments below.

Specifically regarding the issue of referencing rfc7432 or rfc7432bis, I have 
modified the reference to be on rfc7432 since existing 7432 is sufficient as a 
reference for all procedures covered in this document and it alleviates 
unnecessary dependency on publication of 7432bis.

Thanks,
Neeraj

From: Stephane Litkowski (slitkows) 
Date: Wednesday, October 11, 2023 at 6:14 AM
To: draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org 
, bess@ietf.org 

Cc: bess-cha...@ietf.org 
Subject: Chair review of draft-ietf-bess-evpn-irb-extended-mobility-15
Hi Authors,

Please find below my review of the latest version of the draft:


Abstract:
The abstract refers to RFC7432bis but don’t make RFC7432bis as normative 
reference and also drafts is marked as updating RFC7432.
Here you should make a choice, either you base the draft on RFC7432 and not 
mention RFC7432bis, or base your draft on RFC7432bis, but then you should make 
it normative ref.
As a consequence, you’ll have a downref until RFC7432bis is published. I think 
this is a major issue that needs to be solved before moving fwd.


Introduction:
“EVPN-IRB enables advertising…”.
[SLI] Were you expecting to put a reference here instead of EVPN-IRB ? While 
EVPN and IRB are considered as well known, EVPN-IRB is a bit weird. But I guess 
it’s a reference to RFC9135. If yes, this must be modified. I would potentially 
right it as “EVPN IRB ([RFC9135]) enables…”. We need to have the reference 
immediately, not only at the end. Also in the document, you should choose 
between EVPN IRB and EVPN-IRB. Unfortunately, I see that RFC9135 is not 
consistent  But it’s good to have consistency here.



“While a fixed 1:1 mapping between IP and MAC is a common use case that is 
addressed via existing MAC mobility procedure »
[SLI] I would add: “MAC mobility procedure, defined in [RFC7432]”

“VM move”.
[SLI] I guess you’ll need to expand VM on first use. Maybe adding a bit of 
context before would be helpful (IRB mobility scenarios in datacenter for 
instance).


“Content presented in this document is independent »
[SLI] “Content” is probably too wide IMO. I would write it as “The proposed 
solution is independent …”

“It is also largely”
[SLI] I would remove largely. Either it’s independent, or it’s not 

[SLI] I would personally remove the paragraphs “Content presented…” and “In 
addition to symmetric”, in favor of a slightly modified version of the last 
paragraph:
“

This document covers mobility for the following cases, independently of the 
overlay encapsulation (e.g.: MPLS, NVO 
Tunnel):¶

  *   Symmetric EVPN IRB 
overlay¶
  *   Asymmetric EVPN IRB 
overlay¶
  *   Routed EVPN 
overlay¶
“


Section 1.1:
As sections 3,4,5 are dealing with problem statement/background, wouldn’t it be 
better/more clear to group them in a big section ? You can keep your existing 
3,4,5 sections as subsections of the bigger one.

Section 2:
Please check https://www.rfc-editor.org/materials/abbrev.expansion.txt and I 
think you could remove from your list anything which is considered as well 
known. And also please check for abbrevations that require expansion on first 
use.


Section 4:
For readability purpose, I would always use the same naming conventions for the 
IP to MAC bindings, sometimes you use IP1-MAC1, sometimes IP1-M1 across the 
sections.

Section 5:
“It is possible for host to be learnt on say, PE1”
[SLI] I would just say: “It is possible for host VM route be learnt on PE1”


Section 6/7/8/9
[SLI] s/LOCAL/Local|local/g. Why using LOCAL as upper case ?

Section 7.1:
[SLI] I have a philosophical issue with the parent/child relationship you 
describe. If MAC is parent of MAC-IP, how could MAC be truly optional as a 
child cannot exist without its parent.

Section 8.1/8.2/8.4/8.5
[SLI] s/should be computed/MUST be computed/g. IMO, you cannot use “should” and 
then MUST in your bullets.

Section 8.3:
[SLI] s/is required/IS REQUIRED

Section 8.5
“If this is a SYNCed MAC-IP on a local ES, it would also result in a derived 
SYNC MAC Mx route entry”
[SLI] I find the beg of the sentence of bit weird, could you improve it ?

Section 8.6:
[SLI] Change title to “Interoperability”, same in the text of the section.
s/should be computed/MUST be computed . Why using should here and must in other 
cases, any reason ?

Section 10:
Why do you use DUPLICATE/FROZEN as upper case ? You need to make it lower case

Section 13:
You missed a “e” at the end of Patrice’s last name.

Re: [bess] WGLC, IPR, implementation poll for draft-ietf-bess-evpn-irb-extended-mobility

[Neeraj Malhotra (nmalhotr)]

Hi,

I am not aware of any undisclosed IPR.

Also, wanted to re-confirm that all comments during and since the last WGLC 
(including from RtgDir early review) have been addressed in the latest version.

I am aware of at least two implementations across Cisco and Arrcus.

Thanks,
Neeraj

From: slitkows.i...@gmail.com 
Date: Tuesday, September 19, 2023 at 12:45 AM
To: bess@ietf.org , 
draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org 

Cc: bess-cha...@ietf.org 
Subject: WGLC, IPR, implementation poll for 
draft-ietf-bess-evpn-irb-extended-mobility
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-irb-extended-mobility-14 [1]. Note that the document 
already had a WGLC and comments were raised by the WG. These comments are 
normally addressed by the Authors but feel free to review again and provide 
feedback.

This poll runs until Tuesday 3rd October.

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]. Please indicate 
if you are aware of any implementations.



Thank you,
Stephane, Matthew, Jeffrey

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

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

Re: [bess] RtgDir Early review: draft-ietf-bess-evpn-irb-extended-mobility-10.txt

[Neeraj Malhotra (nmalhotr)]

Hi Donald,

Great, many thanks.

Neeraj

From: Donald Eastlake 
Date: Monday, August 21, 2023 at 6:39 PM
To: Neeraj Malhotra (nmalhotr) 
Cc: bess-cha...@ietf.org , 
draft-ietf-bess-evpn-irb-extended-mobility@ietf.org 
, rtg-...@ietf.org 
, BESS 
Subject: Re: RtgDir Early review: 
draft-ietf-bess-evpn-irb-extended-mobility-10.txt
Hi Neeraj,

Yes, version -13 looks good.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Mon, Aug 21, 2023 at 1:21 PM Neeraj Malhotra (nmalhotr)
 wrote:
>
>
>
> Hi Donald,
>
>
>
> Thanks again for the additional points. I have addressed all of the 
> additional comments below in the latest rev13. Please do let me know if there 
> is any additional input before we can move further.
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> From: Donald Eastlake 
> Date: Wednesday, August 16, 2023 at 10:53 AM
> To: Neeraj Malhotra (nmalhotr) 
> Cc: bess-cha...@ietf.org , 
> draft-ietf-bess-evpn-irb-extended-mobility@ietf.org 
> , rtg-...@ietf.org 
> , BESS 
> Subject: Re: RtgDir Early review: 
> draft-ietf-bess-evpn-irb-extended-mobility-10.txt
>
> Hi Neeraj,
>
>
>
> Sorry for the delay in responding.
>
>
>
> Generally my comments have been incorporated and, I think, all my issues 
> addressed. However, some problems were introduced by the changes and there 
> are some nits:
>
> - The RFC 2119 & 8174 boilerplate language should presumably be in Section 2 
> but has disappeared from the draft.
>
> - Square bracketed references are not allowed in the Abstract. You need to 
> change those in the Abstract back to just "RFC 7432" or perhaps "RFC 7432bis".
>
> - Although in my comments I said the draft should be shown as updating "RFC 
> 7432", the Updates: line on the title page takes only numbers so it should 
> just say "7432".
>
>
>
> Also, the references to RFC 826 and RFC 4861 need the space removed at the 
> square bracketed reference in the text body and to be added to the References 
> section
>
> and you should update references:
>
> draft-ietf-bess-evpn-inter-subnet-forwarding -> RFC 9135
>
> draft-ietf-bess-evpn-proxy-arp-nd -> 9161
>
>
>
> I have no idea if the reason you state will be good enough for the IESG to 
> allow >5 authors.
>
>
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
>
>
>
>
> On Tue, Aug 15, 2023 at 4:00 PM Neeraj Malhotra (nmalhotr) 
>  wrote:
>
>
>
> Hi Donald,
>
>
>
> Rev12 of the draft also takes care of the missing note with respect to six 
> authors on the draft. Please do let me know if there is anything else beyond 
> the earlier review comments that needs to be addressed.
>
>
>
> If not, would like to request on behalf of all authors to move this forward.
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> From: Neeraj Malhotra (nmalhotr) 
> Date: Tuesday, August 1, 2023 at 4:23 PM
> To: Donald Eastlake , bess-cha...@ietf.org 
> , 
> draft-ietf-bess-evpn-irb-extended-mobility@ietf.org 
> 
> Cc: rtg-...@ietf.org , BESS 
> Subject: Re: RtgDir Early review: 
> draft-ietf-bess-evpn-irb-extended-mobility-10.txt
>
>
>
> Hi Donald,
>
>
>
> Many thanks for the details review and comments. I have published version 11 
> of the document that incorporates all of your comments. Please also see 
> inline below for some additional clarifications.
>
>
>
> This document repeatedly says that it may be considered a clarification of 
> RFC 7432. I believe it is true that the behavior specified in this document 
> is permitted by RFC 7432 but other behaviors are permitted and perhaps 
> common. In order to handle the mobility cases covered in this document the 
> behaviors in the document would have to be implemented or some other solution 
> adopted. Thus I think the title page header should show this document as 
> updating RFC 7432 and this should be mentioned in the Abstract and 
> Introduction.
>
>
>
> [NM]: Ack. I have updated the text in the abstract and introduction sections 
> to say that this document updates sequence number procedures defined in 
> [RFC7432] in addition to the title page header.
>
>
>
> It seems to me that the last paragraph of Section 7.2 ignores the case where 
> Mx-IPx with sequence number N movez to Mz-IPx where child IP-MACs under Mz 
> were currently being advertised with sequence number M where M > N. The 
> paragraph sa

Re: [bess] RtgDir Early review: draft-ietf-bess-evpn-irb-extended-mobility-10.txt

[Neeraj Malhotra (nmalhotr)]

Hi Donald,

Thanks again for the additional points. I have addressed all of the additional 
comments below in the latest rev13. Please do let me know if there is any 
additional input before we can move further.

Thanks,
Neeraj

From: Donald Eastlake 
Date: Wednesday, August 16, 2023 at 10:53 AM
To: Neeraj Malhotra (nmalhotr) 
Cc: bess-cha...@ietf.org , 
draft-ietf-bess-evpn-irb-extended-mobility@ietf.org 
, rtg-...@ietf.org 
, BESS 
Subject: Re: RtgDir Early review: 
draft-ietf-bess-evpn-irb-extended-mobility-10.txt
Hi Neeraj,

Sorry for the delay in responding.

Generally my comments have been incorporated and, I think, all my issues 
addressed. However, some problems were introduced by the changes and there are 
some nits:
- The RFC 2119 & 8174 boilerplate language should presumably be in Section 2 
but has disappeared from the draft.
- Square bracketed references are not allowed in the Abstract. You need to 
change those in the Abstract back to just "RFC 7432" or perhaps "RFC 7432bis".
- Although in my comments I said the draft should be shown as updating "RFC 
7432", the Updates: line on the title page takes only numbers so it should just 
say "7432".

Also, the references to RFC 826 and RFC 4861 need the space removed at the 
square bracketed reference in the text body and to be added to the References 
section
and you should update references:

draft-ietf-bess-evpn-inter-subnet-forwarding -> RFC 9135

draft-ietf-bess-evpn-proxy-arp-nd -> 9161


I have no idea if the reason you state will be good enough for the IESG to 
allow >5 authors.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com<mailto:d3e...@gmail.com>


On Tue, Aug 15, 2023 at 4:00 PM Neeraj Malhotra (nmalhotr) 
mailto:nmalh...@cisco.com>> wrote:

Hi Donald,

Rev12 of the draft also takes care of the missing note with respect to six 
authors on the draft. Please do let me know if there is anything else beyond 
the earlier review comments that needs to be addressed.

If not, would like to request on behalf of all authors to move this forward.

Thanks,
Neeraj

From: Neeraj Malhotra (nmalhotr) mailto:nmalh...@cisco.com>>
Date: Tuesday, August 1, 2023 at 4:23 PM
To: Donald Eastlake mailto:d3e...@gmail.com>>, 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> 
mailto:bess-cha...@ietf.org>>, 
draft-ietf-bess-evpn-irb-extended-mobility@ietf.org<mailto:draft-ietf-bess-evpn-irb-extended-mobility@ietf.org>
 
mailto:draft-ietf-bess-evpn-irb-extended-mobility@ietf.org>>
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org> 
mailto:rtg-...@ietf.org>>, BESS 
mailto:bess@ietf.org>>
Subject: Re: RtgDir Early review: 
draft-ietf-bess-evpn-irb-extended-mobility-10.txt

Hi Donald,

Many thanks for the details review and comments. I have published version 11 of 
the document that incorporates all of your comments. Please also see inline 
below for some additional clarifications.


This document repeatedly says that it may be considered a clarification of RFC 
7432. I believe it is true that the behavior specified in this document is 
permitted by RFC 7432 but other behaviors are permitted and perhaps common. In 
order to handle the mobility cases covered in this document the behaviors in 
the document would have to be implemented or some other solution adopted. Thus 
I think the title page header should show this document as updating RFC 7432 
and this should be mentioned in the Abstract and Introduction.



[NM]: Ack. I have updated the text in the abstract and introduction sections to 
say that this document updates sequence number procedures defined in [RFC7432] 
in addition to the title page header.



It seems to me that the last paragraph of Section 7.2 ignores the case where 
Mx-IPx with sequence number N movez to Mz-IPx where child IP-MACs under Mz were 
currently being advertised with sequence number M where M > N. The paragraph 
says the new Mz sequence number must be incremented to N+1 but if M>N I think 
it must be incremented to M+1. I have suggested changes to the last two 
paragraphs of Section 7.2 in the attached.



[NM]: that’s a really good catch. A later section (8) does cover this but the 
example in section 7.2 was missing this condition. Updated.



Drafts should generally be worded so the text will be correct in the final RFC. 
So both occurrences of "proposed" in this draft should be replaced by 
"specified" or "defined" and occurrences of "draft" in the body text should be 
replaced with "document".



[NM] updated.



Section 2.1 lists subsequent sections as Informative or Normative but omits 
Sections 3 and 7. I think Section 3 is Informative. The right category for 
Section 7 is a bit unclear but I'm inclined towards normative.



[NM]: Upd

Re: [bess] RtgDir Early review: draft-ietf-bess-evpn-irb-extended-mobility-10.txt

[Neeraj Malhotra (nmalhotr)]

Hi Donald,

Rev12 of the draft also takes care of the missing note with respect to six 
authors on the draft. Please do let me know if there is anything else beyond 
the earlier review comments that needs to be addressed.

If not, would like to request on behalf of all authors to move this forward.

Thanks,
Neeraj

From: Neeraj Malhotra (nmalhotr) 
Date: Tuesday, August 1, 2023 at 4:23 PM
To: Donald Eastlake , bess-cha...@ietf.org 
, draft-ietf-bess-evpn-irb-extended-mobility@ietf.org 

Cc: rtg-...@ietf.org , BESS 
Subject: Re: RtgDir Early review: 
draft-ietf-bess-evpn-irb-extended-mobility-10.txt

Hi Donald,

Many thanks for the details review and comments. I have published version 11 of 
the document that incorporates all of your comments. Please also see inline 
below for some additional clarifications.


This document repeatedly says that it may be considered a clarification of RFC 
7432. I believe it is true that the behavior specified in this document is 
permitted by RFC 7432 but other behaviors are permitted and perhaps common. In 
order to handle the mobility cases covered in this document the behaviors in 
the document would have to be implemented or some other solution adopted. Thus 
I think the title page header should show this document as updating RFC 7432 
and this should be mentioned in the Abstract and Introduction.



[NM]: Ack. I have updated the text in the abstract and introduction sections to 
say that this document updates sequence number procedures defined in [RFC7432] 
in addition to the title page header.



It seems to me that the last paragraph of Section 7.2 ignores the case where 
Mx-IPx with sequence number N movez to Mz-IPx where child IP-MACs under Mz were 
currently being advertised with sequence number M where M > N. The paragraph 
says the new Mz sequence number must be incremented to N+1 but if M>N I think 
it must be incremented to M+1. I have suggested changes to the last two 
paragraphs of Section 7.2 in the attached.



[NM]: that’s a really good catch. A later section (8) does cover this but the 
example in section 7.2 was missing this condition. Updated.



Drafts should generally be worded so the text will be correct in the final RFC. 
So both occurrences of "proposed" in this draft should be replaced by 
"specified" or "defined" and occurrences of "draft" in the body text should be 
replaced with "document".



[NM] updated.



Section 2.1 lists subsequent sections as Informative or Normative but omits 
Sections 3 and 7. I think Section 3 is Informative. The right category for 
Section 7 is a bit unclear but I'm inclined towards normative.



[NM]: Updated as above – except that I am also a bit unclear if section 7 
should be listed as normative as it is doing some ground work for the 
specifications in subsequent normative sections using some examples but is not 
meant to provide a complete specification. I have left it out for now, but 
happy to include it as normative if needed.



Section 10.2 refers to section 6.1 but there isn't any section 6.1. The bullet 
point in Section 10.2 seems essentially incomplete: What "MUST be higher than 
the "Mz" sequence number"?

In the last sentence of Section 4.3.1, it is not completely clear what "It" 
refers to. Assuming it is the interpretation in the previous sentence, I 
suggest "It could be interpreted as" -> "This interpretation could be 
considered".

"GW devices" occurs only once in this document in Section 2 and GW is never 
expanded. I suggest, assuming this is correct, that the phrase be replaced with 
"PE devices".

In section 9, since it is not expanded and not listed in the glossary, I think 
"EXT-COMM" -> "Extended Community".

Based on the usual order of RFC Sections and the RFC Editor's recommended table 
of contents, I think Sections 1 and 2 should be swapped.

The requirements language boilerplate at the beginning of Section 1 needs to be 
updated to the latest version also normatively referencing RFC 8174.



[NM]: incorporated all of the above comments and all inline changes in the 
marked-up document.



The document references RFC 7432 but I think it should reference the rfc7432bis 
draft instead.



[NM]: updated the reference link to point to RFC7432bis.



I am doubtful that there are truly no new security considerations. At a 
minimum, I would think the Security Consideration section (section 11) should 
refer readers to the Security Considerations sections of [EVPN-IRB] and 
rfc7432bis and should state that the methods specified in this document will 
increase the consumption of sequence numbers.



[NM]: added security section.



RFCs are generally limited to a maximum of five authors. This document lists 
six but does say why it needs to list that many. This could be in a first page 
note to be deleted before publication.

Re: [bess] RtgDir Early review: draft-ietf-bess-evpn-irb-extended-mobility-10.txt

[Neeraj Malhotra (nmalhotr)]

Hi Donald,

Many thanks for the details review and comments. I have published version 11 of 
the document that incorporates all of your comments. Please also see inline 
below for some additional clarifications.


This document repeatedly says that it may be considered a clarification of RFC 
7432. I believe it is true that the behavior specified in this document is 
permitted by RFC 7432 but other behaviors are permitted and perhaps common. In 
order to handle the mobility cases covered in this document the behaviors in 
the document would have to be implemented or some other solution adopted. Thus 
I think the title page header should show this document as updating RFC 7432 
and this should be mentioned in the Abstract and Introduction.



[NM]: Ack. I have updated the text in the abstract and introduction sections to 
say that this document updates sequence number procedures defined in [RFC7432] 
in addition to the title page header.



It seems to me that the last paragraph of Section 7.2 ignores the case where 
Mx-IPx with sequence number N movez to Mz-IPx where child IP-MACs under Mz were 
currently being advertised with sequence number M where M > N. The paragraph 
says the new Mz sequence number must be incremented to N+1 but if M>N I think 
it must be incremented to M+1. I have suggested changes to the last two 
paragraphs of Section 7.2 in the attached.



[NM]: that’s a really good catch. A later section (8) does cover this but the 
example in section 7.2 was missing this condition. Updated.



Drafts should generally be worded so the text will be correct in the final RFC. 
So both occurrences of "proposed" in this draft should be replaced by 
"specified" or "defined" and occurrences of "draft" in the body text should be 
replaced with "document".



[NM] updated.



Section 2.1 lists subsequent sections as Informative or Normative but omits 
Sections 3 and 7. I think Section 3 is Informative. The right category for 
Section 7 is a bit unclear but I'm inclined towards normative.



[NM]: Updated as above – except that I am also a bit unclear if section 7 
should be listed as normative as it is doing some ground work for the 
specifications in subsequent normative sections using some examples but is not 
meant to provide a complete specification. I have left it out for now, but 
happy to include it as normative if needed.



Section 10.2 refers to section 6.1 but there isn't any section 6.1. The bullet 
point in Section 10.2 seems essentially incomplete: What "MUST be higher than 
the "Mz" sequence number"?

In the last sentence of Section 4.3.1, it is not completely clear what "It" 
refers to. Assuming it is the interpretation in the previous sentence, I 
suggest "It could be interpreted as" -> "This interpretation could be 
considered".

"GW devices" occurs only once in this document in Section 2 and GW is never 
expanded. I suggest, assuming this is correct, that the phrase be replaced with 
"PE devices".

In section 9, since it is not expanded and not listed in the glossary, I think 
"EXT-COMM" -> "Extended Community".

Based on the usual order of RFC Sections and the RFC Editor's recommended table 
of contents, I think Sections 1 and 2 should be swapped.

The requirements language boilerplate at the beginning of Section 1 needs to be 
updated to the latest version also normatively referencing RFC 8174.



[NM]: incorporated all of the above comments and all inline changes in the 
marked-up document.



The document references RFC 7432 but I think it should reference the rfc7432bis 
draft instead.



[NM]: updated the reference link to point to RFC7432bis.



I am doubtful that there are truly no new security considerations. At a 
minimum, I would think the Security Consideration section (section 11) should 
refer readers to the Security Considerations sections of [EVPN-IRB] and 
rfc7432bis and should state that the methods specified in this document will 
increase the consumption of sequence numbers.



[NM]: added security section.



RFCs are generally limited to a maximum of five authors. This document lists 
six but does say why it needs to list that many. This could be in a first page 
note to be deleted before publication.



[NM]: missed adding this – let me wait a couple of days in case there are any 
additional comments and if not, update this by end of this week.

Nits:


Abstract: "Procedure to handle host mobility" -> "The procedure to handle host 
mobility"

Section 2, first sentence: "EVPN-IRB enables capability ..." -> "EVPN-IRB 
enables the capability ...

Section 2: "Purpose of this draft is to define additional ..." => "This 
document defines additional ... "

Section 4.3.1: "Complication with this ..." -> "The complication with this ..."

Section 8.8: "This sections is to be treated as optional ..." -> "This section 
is optional ..."

Although the above stuck out a bit more to me, there are many other nits 
including some spelling typos and a duplicated word, so I went 

Re: [bess] RtgDir Early review: draft-ietf-bess-evpn-irb-extended-mobility-10.txt

[Neeraj Malhotra (nmalhotr)]

Hi Donald,

Many thanks for a detailed review and input. Much appreciated.

Will get back with document updates and clarifications within a week.

Thanks,
Neeraj

From: Donald Eastlake 
Date: Monday, July 17, 2023 at 7:18 PM
To: bess-cha...@ietf.org , 
draft-ietf-bess-evpn-irb-extended-mobility@ietf.org 

Cc: rtg-...@ietf.org , BESS 
Subject: RtgDir Early review: draft-ietf-bess-evpn-irb-extended-mobility-10.txt

I have been selected to do a routing directorate “early” review of this draft.

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/

This is an early general readiness review of this draft.

For more information about the Routing Directorate, please see 
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-bess-evpn-irb-extended-mobility-10.txt
Reviewer: Donald Eastlake
Review Date: 2023 July 17
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved 
before it is submitted to the IESG.

Comments:


I would rate the readability of the draft as moderate. Hopefully some of my 
suggestions below will help.

I believe the technical quality is high and the document takes a reasonable 
approach to maintaining appropriate handling of sequence numbers when there is 
a mobility event that changes the pairing between MAC and IP addresses under 
various circumstances; however, I do have a few questions below.

This document repeatedly says that it may be considered a clarification of RFC 
7432. I believe it is true that the behavior specified in this document is 
permitted by RFC 7432 but other behaviors are permitted and perhaps common. In 
order to handle the mobility cases covered in this document the behaviors in 
the document would have to be implemented or some other solution adopted. Thus 
I think the title page header should show this document as updating RFC 7432 
and this should be mentioned in the Abstract and Introduction.

It seems to me that the last paragraph of Section 7.2 ignores the case where 
Mx-IPx with sequence number N movez to Mz-IPx where child IP-MACs under Mz were 
currently being advertised with sequence number M where M > N. The paragraph 
says the new Mz sequence number must be incremented to N+1 but if M>N I think 
it must be incremented to M+1. I have suggested changes to the last two 
paragraphs of Section 7.2 in the attached.

Drafts should generally be worded so the text will be correct in the final RFC. 
So both occurrences of "proposed" in this draft should be replaced by 
"specified" or "defined" and occurrences of "draft" in the body text should be 
replaced with "document".

Section 2.1 lists subsequent sections as Informative or Normative but omits 
Sections 3 and 7. I think Section 3 is Informative. The right category for 
Section 7 is a bit unclear but I'm inclined towards normative.

Section 10.2 refers to section 6.1 but there isn't any section 6.1. The bullet 
point in Section 10.2 seems essentially incomplete: What "MUST be higher than 
the "Mz" sequence number"?

In the last sentence of Section 4.3.1, it is not completely clear what "It" 
refers to. Assuming it is the interpretation in the previous sentence, I 
suggest "It could be interpreted as" -> "This interpretation could be 
considered".

"GW devices" occurs only once in this document in Section 2 and GW is never 
expanded. I suggest, assuming this is correct, that the phrase be replaced with 
"PE devices".

In section 9, since it is not expanded and not listed in the glossary, I think 
"EXT-COMM" -> "Extended Community".

Based on the usual order of RFC Sections and the RFC Editor's recommended table 
of contents, I think Sections 1 and 2 should be swapped.

The requirements language boilerplate at the beginning of Section 1 needs to be 
updated to the latest version also normatively referencing RFC 8174.

The document references RFC 7432 but I think it should reference the rfc7432bis 
draft instead.

I am doubtful that there are truly no new security considerations. At a 
minimum, I would think the Security Consideration section (section 11) should 
refer readers to the Security Considerations sections of [EVPN-IRB] and 
rfc7432bis and should state that the methods specified in this document will 
increase the consumption of sequence numbers.

RFCs are generally limited to a maximum of five authors. This document lists 
six but does say why it needs to list that many. This could be in a first page 
note to be deleted before publication.

Nits:


Abstract: "Procedure to handle host mobility" -> "The procedure to handle host 
mobility"

Section 2, first sentence: "EVPN-IRB enables capability ..." -> "EVPN-IRB 
enables the capability ...

Section 2: "Purpose of this draft is to define additional ..." => "This 
document defines additional ... "

Section 4.3.1: "Complication with this ..." -> "The complication with this ..."

Section 8.8: "This sections 

Re: [bess] Few queries on draft-ietf-bess-evpn-irb-extended-mobility

[Neeraj Malhotra]

Hi Saumya,

Many thanks for a detailed review and discussion. I have incorporated the
points from this discussion in the latest revision (07).

Thanks,
Neeraj

On Sat, Sep 11, 2021 at 12:37 AM Dikshit, Saumya 
wrote:

> Thanks again Neeraj J
>
> Please see Inline below with [SD2]
>
>
>
> Regards,
>
> Saumya.
>
>
>
> *From:* Neeraj Malhotra (nmalhotr) [mailto:nmalh...@cisco.com]
> *Sent:* Friday, September 10, 2021 3:41 PM
> *To:* Dikshit, Saumya ;
> draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org
> *Cc:* bess-cha...@ietf.org; bess@ietf.org
> *Subject:* Re: Few queries on draft-ietf-bess-evpn-irb-extended-mobility
>
>
>
>
>
> Hi Saumya,
>
>
>
> Thanks for the nudge  Please see inline below with [NM2],
>
>
>
> *>>>>
> Section 
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.8
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.8>*
>
> *“Following a host move from PE1 to PE2, the host's MAC is*
>
> *  discovered at PE2 as a local MAC via a data frames received from*
>
> *  the host.”*
>
> Do we need to call out the misconfiguration case, where a probe may lead to 
> DUP responses,
>
> one from the (local learning) access side and other one across the fabric 
> (overlay tunnel).
>
>
>
> [NM]: Implementation don’t normally handle ARP from the core side to protect 
> against such mis-configurations. This is an optional section that includes 
> suggestions for better convergence. Hence, want to refrain from being too 
> prescriptive about how n implementation may choose to protect from such 
> mis-configurations.
>
>  [SD] Without Arp-suppression, the neighbor learnings can happen from the
> fabric as well. Even without Arp-suppression, the first response can come
> from the fabric (and also via the EVPN control plane). Even GARPs, can be
> (selectively) allowed to flood  over the fabric as well. I know few of the
> campus deployments tend to do this. Hence the ask to capture this case
> explicitly.
>
>
>
> [NM2]: Regardless of ARP suppression being enabled or not, with a
> distributed anycast gateway, if the probe is flooded across the fabric, and
> there is a DUP host, ARP response from the DUP host should be consumed
> locally by the PE and not forwarded across the fabric.
>
> [SD2] this is where I beg to differ. In non-anycast (but same subnet
> gateways)  or anycast, if the ARP-request is generated by the remote host
> (same EVI/L2-VNI), the arp response will be (copied  + fwded-to-fabric) on
> the first-hop-vtep (from the responding host). Hence the confusion.
>
>
>
> Once this happens, sequence number based EVPN duplicate detection will
> apply. In other words, even if the host is DUP and ARP is flooded, one
> should not expect duplicate ARP response from the fabric side (barring a
> bug in the implementation). That said, for the specific convergence
> scenario mentioned here, one can also choose to implement the probe to be
> directed on the MAC port and not flooded. Regardless, this is an
> informational section focused on convergence aspects that are local to an
> implementation and don’t necessarily require any standardization.
>
> [SD2] if this is intended as a reference/informational section, +1 on
> skipping the probing details.
>
>
>
> Bringing in a discussion on duplicate scenarios here, IMO, will make it
> rather confusing.
>
>
>
> *>>>>
> Section 
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-10.4.1
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-10.4.1>*
>
> *“unfreezing the*
>
> *  route at the FROZEN location will result in the route being*
>
> *  advertised with a higher sequence number.”*
>
> Why are we tying probing with “unfreezing” ? FROZEN will typically
> indicate dropping of flows. Probing can still go on in parallel ?
>
> Can this be called out explicitly.
>
>
>
> [NM]: There is no probing requirement for unfreezing. This section is just
> explaining, how the unfreezing will resolve the scenario following removal
> of duplicate host from location A, regardless of whether the freezing and
> unfreezing is done at location A OR B (since duplicate procedure could
> cause freezing to happen at any of location A OR B). Hope, this clarifies.
>
> [SD] I think I did not put I across clearly. What I meant to convey is,
> that the probing can happen in tandem while the MAC was designated as
> DUPLICATE/FROZEN. It need not wait for an explicit higher sequence number
> to trigger the same. 

Re: [bess] WG adoption poll and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].

[Neeraj Malhotra]

Hi,

Support adoption.

Thanks,
Neeraj

On Tue, Sep 7, 2021 at 5:42 AM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> Hello,
>
>
>
> This email begins a two-week WG adoption poll for
> draft-mohanty-bess-ebgp-dmz-03 [1].
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> 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, copying the BESS mailing list. The document will
> not  progress without answers from all of the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> 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.
>
>
>
> This poll for adoption closes on September 21st 2021.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-mohanty-bess-ebgp-dmz-03/
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Few queries on draft-ietf-bess-evpn-irb-extended-mobility

[Neeraj Malhotra (nmalhotr)]

Hi Saumya,

Thanks for the nudge  Please see inline below with [NM2],

 Section 
 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.8

“Following a host move from PE1 to PE2, the host's MAC is

  discovered at PE2 as a local MAC via a data frames received from

  the host.”

Do we need to call out the misconfiguration case, where a probe may lead to DUP 
responses,

one from the (local learning) access side and other one across the fabric 
(overlay tunnel).



[NM]: Implementation don’t normally handle ARP from the core side to protect 
against such mis-configurations. This is an optional section that includes 
suggestions for better convergence. Hence, want to refrain from being too 
prescriptive about how n implementation may choose to protect from such 
mis-configurations.
 [SD] Without Arp-suppression, the neighbor learnings can happen from the 
fabric as well. Even without Arp-suppression, the first response can come from 
the fabric (and also via the EVPN control plane). Even GARPs, can be 
(selectively) allowed to flood  over the fabric as well. I know few of the 
campus deployments tend to do this. Hence the ask to capture this case 
explicitly.

[NM2]: Regardless of ARP suppression being enabled or not, with a distributed 
anycast gateway, if the probe is flooded across the fabric, and there is a DUP 
host, ARP response from the DUP host should be consumed locally by the PE and 
not forwarded across the fabric. Once this happens, sequence number based EVPN 
duplicate detection will apply. In other words, even if the host is DUP and ARP 
is flooded, one should not expect duplicate ARP response from the fabric side 
(barring a bug in the implementation). That said, for the specific convergence 
scenario mentioned here, one can also choose to implement the probe to be 
directed on the MAC port and not flooded. Regardless, this is an informational 
section focused on convergence aspects that are local to an implementation and 
don’t necessarily require any standardization. Bringing in a discussion on 
duplicate scenarios here, IMO, will make it rather confusing.

 Section 
 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-10.4.1

“unfreezing the

  route at the FROZEN location will result in the route being

  advertised with a higher sequence number.”
Why are we tying probing with “unfreezing” ? FROZEN will typically indicate 
dropping of flows. Probing can still go on in parallel ?
Can this be called out explicitly.

[NM]: There is no probing requirement for unfreezing. This section is just 
explaining, how the unfreezing will resolve the scenario following removal of 
duplicate host from location A, regardless of whether the freezing and 
unfreezing is done at location A OR B (since duplicate procedure could cause 
freezing to happen at any of location A OR B). Hope, this clarifies.
[SD] I think I did not put I across clearly. What I meant to convey is, that 
the probing can happen in tandem while the MAC was designated as 
DUPLICATE/FROZEN. It need not wait for an explicit higher sequence number to 
trigger the same. This help would expedite the convergence.

[NM2]: Periodic probing based on ARP refresh timers is completely independent 
and has no overlap with this, if that is what you are referring to? Above 
refers to event driven probing that is triggered by a route with a higher 
sequence number. Besides this, no one is continuously probing all hosts in the 
system. Perhaps, still missing the point?

 Section " 
 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-4.3.1;
  :
" [IP7, M1] is learnt as a new route at
   [PE3, PE4] and advertised to remote PEs with a sequence number of 0.
   As a result, L3 reachability to IP7 would be established across the
   overlay, however, MAC mobility procedure for MAC1 will not trigger as
   a result of this MAC-IP route advertisement"

If a host is moved with the same MAC, the following is still being following in 
current implementation(s):
- Either "MAC-only-route" or "MAC-IP-route" advertisement, the sequence number 
is bumped in both cases
- On receiving side,
  -  the sequence-number is picked up from "MAC-only-route" or 
"MAC-IP-route" and applied to MAC learnings
  - the bumped up sequence number leads a withdraw of "MAC-only" or 
"MAC-IP-route" from the inferior (earlier) publisher

Kindly help explain, if the text mentioned in “section 4.3.1” is creating some 
doubts regarding the way things operate with current standards.
Though I definitely believe that this literature does away with lot of existing 
ambiguities.
I think we need to paraphrase this section atleast.

[NM]: If the MAC-IP following a host move is learnt with a different IP, this 
draft explicitly calls out the procedure to associate sequence number with the 
MAC + inheritance to ensure that sequence 

Re: [bess] Few queries on draft-ietf-bess-evpn-irb-extended-mobility

[Neeraj Malhotra (nmalhotr)]

Hi Saumya,

Apologies for the delay, and many thanks for some good comments and questions. 
Please see answers inline:

Hello Authors of  draft-ietf-bess-evpn-irb-extended-mobility:

I have following queries and comments about this draft 
“draft-ietf-bess-evpn-inter-subnet-forwarding”.
Please help clarify.

Section 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.1

MUST be at least equal to corresponding SYNC MAC sequence number
  if one is present.
Can we formally define what a “SYNC MAC sequence number” ?

[NM]: sure, will define in the next revision. It refers to sequence number 
received with the MAC SYNCed from another PE sharing the same ESI.

Section 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.3

“MAC Mx with a sequence number that is higher than or equal to
   sequence number assigned to a LOCAL route for MAC Mx:
   o  PE MUST trigger probe and deletion procedure for all LOCAL IPs
  associated with MAC Mx.
   o  PE MUST trigger deletion procedure for LOCAL MAC route for Mx.

”
As per rfc7423, if equal sequence number is received, then the one published 
with lower vtep-ip is retained, and the other one is withdrawn.
While this section talks about probing it again.
This should be called out in the Interop section as well, for the co-existence 
of old rule and newly defined

[NM]: sure, that’s a good point. Will clarify in the next revision – 
essentially, the rule in RFC 7432 still needs to be applied to equal sequence 
number scenario, but a probe must as well be done for all associated IPs to 
handle transient race conditions. If indeed the host is attached to the PE with 
lower VTEP IP, a successful probe will force a sequence number increment and 
resolve the race OR lead to duplicate detection.

Quoting from  https://datatracker.ietf.org/doc/html/rfc7432#section-15:

“If two (or more) PEs advertise the same MAC

   address with the same sequence number but different Ethernet segment

   identifiers, a PE that receives these routes selects the route

   advertised by the PE with the lowest IP address as the best route”


 Section 
 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.6

“   an inter-op scenario with a different implementation could arise,

   where a PE implementation non-compliant with this document or with

   RFC 7432 assigns and 
advertises independent sequence numbers to MAC

   and MAC+IP routes”
How do we expect this implementation to inter-op, as it may expect two 
different MAC-only and MAC-IP advertisement from remote peers as well.?
Can we paraphrase this ?

[NM]: correct, for a scenario where no MAC route is advertised, a non-compliant 
implementation may send different sequence numbers for multiple MAC-IPs with 
the same MAC. Handling for such a scenario should be explicitly called out as 
well. Will add to next revision.


 Section 
 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.8

“Following a host move from PE1 to PE2, the host's MAC is

  discovered at PE2 as a local MAC via a data frames received from

  the host.”

Do we need to call out the misconfiguration case, where a probe may lead to DUP 
responses,

one from the (local learning) access side and other one across the fabric 
(overlay tunnel).



[NM]: Implementation don’t normally handle ARP from the core side to protect 
against such mis-configurations. This is an optional section that includes 
suggestions for better convergence. Hence, want to refrain from being too 
prescriptive about how n implementation may choose to protect from such 
mis-configurations.


 Section 
 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-10.4.1

“unfreezing the

  route at the FROZEN location will result in the route being

  advertised with a higher sequence number.”
Why are we tying probing with “unfreezing” ? FROZEN will typically indicate 
dropping of flows. Probing can still go on in parallel ?
Can this be called out explicitly.

[NM]: There is no probing requirement for unfreezing. This section is just 
explaining, how the unfreezing will resolve the scenario following removal of 
duplicate host from location A, regardless of whether the freezing and 
unfreezing is done at location A OR B (since duplicate procedure could cause 
freezing to happen at any of location A OR B). Hope, this clarifies.

 Section " 
 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-4.3.1;
  :
" [IP7, M1] is learnt as a new route at
   [PE3, PE4] and advertised to remote PEs with a sequence number of 0.
   As a result, L3 reachability to IP7 would be established across the
   overlay, however, MAC mobility procedure for MAC1 will not trigger as
   a 

Re: [bess] Few queries on draft-ietf-bess-evpn-irb-extended-mobility

[Neeraj Malhotra (nmalhotr)]

Hi Saumya,

Thanks for your comments/questions. Will respond by end of this week.

Thanks,
Neeraj

From: "Dikshit, Saumya" 
Date: Tuesday, August 17, 2021 at 12:25 AM
To: "Dikshit, Saumya" , 
"draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org" 

Cc: "bess-cha...@ietf.org" , "bess@ietf.org" 

Subject: RE: Few queries on draft-ietf-bess-evpn-irb-extended-mobility
Resent-From: 
Resent-To: , , 
, , , 

Resent-Date: Tuesday, August 17, 2021 at 12:25 AM

Hello Authors of draft-ietf-bess-evpn-irb-extended-mobility,

Please help me with below queries.

Thanks
Saumya.

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Dikshit, Saumya
Sent: Saturday, August 14, 2021 11:30 AM
To: draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org
Cc: bess-cha...@ietf.org; bess@ietf.org
Subject: [bess] Few queries on draft-ietf-bess-evpn-irb-extended-mobility

Changing the subject line and resending, Please ignore the previous email. 
Apology for mixing up things]

Hello Authors of  draft-ietf-bess-evpn-irb-extended-mobility:

I have following queries and comments about this draft 
“draft-ietf-bess-evpn-inter-subnet-forwarding”.
Please help clarify.

Section 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.1

MUST be at least equal to corresponding SYNC MAC sequence number
  if one is present.
Can we formally define what a “SYNC MAC sequence number” ?

Section 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.3

“MAC Mx with a sequence number that is higher than or equal to
   sequence number assigned to a LOCAL route for MAC Mx:
   o  PE MUST trigger probe and deletion procedure for all LOCAL IPs
  associated with MAC Mx.
   o  PE MUST trigger deletion procedure for LOCAL MAC route for Mx.

”
As per rfc7423, if equal sequence number is received, then the one published 
with lower vtep-ip is retained, and the other one is withdrawn.
While this section talks about probing it again.
This should be called out in the Interop section as well, for the co-existence 
of old rule and newly defined

Quoting from  https://datatracker.ietf.org/doc/html/rfc7432#section-15:

“If two (or more) PEs advertise the same MAC

   address with the same sequence number but different Ethernet segment

   identifiers, a PE that receives these routes selects the route

   advertised by the PE with the lowest IP address as the best route”


 Section 
 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.6

“   an inter-op scenario with a different implementation could arise,

   where a PE implementation non-compliant with this document or with

   RFC 7432 assigns and 
advertises independent sequence numbers to MAC

   and MAC+IP routes”
How do we expect this implementation to inter-op, as it may expect two 
different MAC-only and MAC-IP advertisement from remote peers as well.?
Can we paraphrase this ?


 Section 
 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.8

“Following a host move from PE1 to PE2, the host's MAC is

  discovered at PE2 as a local MAC via a data frames received from

  the host.”

Do we need to call out the misconfiguration case, where a probe may lead to DUP 
responses,

one from the (local learning) access side and other one across the fabric 
(overlay tunnel).


 Section 
 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-10.4.1

“unfreezing the

  route at the FROZEN location will result in the route being

  advertised with a higher sequence number.”
Why are we tying probing with “unfreezing” ? FROZEN will typically indicate 
dropping of flows. Probing can still go on in parallel ?
Can this be called out explicitly.

 Section " 
 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-4.3.1;
  :
" [IP7, M1] is learnt as a new route at
   [PE3, PE4] and advertised to remote PEs with a sequence number of 0.
   As a result, L3 reachability to IP7 would be established across the
   overlay, however, MAC mobility procedure for MAC1 will not trigger as
   a result of this MAC-IP route advertisement"

If a host is moved with the same MAC, the following is still being following in 
current implementation(s):
- Either "MAC-only-route" or "MAC-IP-route" advertisement, the sequence number 
is bumped in both cases
- On receiving side,
  -  the sequence-number is picked up from "MAC-only-route" or 
"MAC-IP-route" and applied to MAC learnings
  - the bumped up sequence number leads a withdraw of "MAC-only" or 
"MAC-IP-route" from the inferior (earlier) publisher

Kindly help explain, if the text mentioned in “section 4.3.1” is creating some 
doubts regarding the way things operate with current standards.
Though I definitely believe that this literature 

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

[Neeraj Malhotra]

Hi,

fyi, have addressed all comments on this thread and some more comments from
co-authors in the latest revision (rev14).

Thanks,
Neeraj


On Wed, May 12, 2021 at 2:07 PM Neeraj Malhotra 
wrote:

>
> Hi Bruno, Sergey,
>
> Thanks for the additional comments and discussion. To summarize, I plan to
> address the following comments by this weekend:
>
> *[Bruno] §4.1 & 5.2 have 3 iterations of “this attribute is to be
> ignored”. I’m afraid one could read this as “this BGP attribute is to be
> ignored”. Surely we mean “this(theses) EVPN Link Bandwidth extended
> community(ies) is(are) to be ignored”.*
>
>
> [NM]: ack.
>
>
> *[Sergey] could we also expand text in section 5.2 “Remote PE behavior” a
> little bit to include an example for non-aliased case where a MAC has been
> learned only from a subset of PEs.*
>
>
> [NM]: Although not ultra important, I think for completeness it will be
> good to allow inclusion of the EC in RT-2 for non-aliasing ECMP use cases.
> It is a simple extension similar to RT-5. Will add.
>
>
> *[Bruno] in the draft §5.2 uses “remote PE” for the ingress PE while §4.1
> uses “remote PE” for the egress PE  (“A receiving PE MUST check for
> consistent 'Value-Units' received in the EVPN link bandwidth exteneded
> community from each remote PE in an Ethernet Segment. » I’d assume that
> terminology in §4.1 need to be fixed.*
>
>
> [NM]: ack.
>
>
> Please see inline for the following comment:
>
>
> *[Bruno] Stricto census, what is needed is a single instance of this
> sub-type and _Value-Units_. In order to accommodate one ingress PE in a
> domain using “Weight in units of Mbps” and another ingress PE in a
> different domain using “Generalized Weight”, one could imagine an egress PE
> advertising 2 communities/both units. I have a slight preference for
> allowing both, but up to you.*
>
>
> [NM]: Yes, strictly speaking, this is correct. However, for simplicity, I
> am inclined to have local/egress PEs that are part of the Ethernet Segment
> specify a single / consistent weight unit they are going to use and have
> the receiving/ingress PEs simply follow, rather than give ingress PEs a
> choice of which units to choose out of multiple received units based on
> some specified or locally provisioned precedence (implementation and
> provisioning overhead as Sergey also commented).
>
>
> Thanks,
>
> Neeraj
>
> On Tue, May 11, 2021 at 11:20 PM Rabadan, Jorge (Nokia - US/Mountain View)
>  wrote:
>
>> Thanks Sergey. I agree with that, for Layer 2 aliasing.
>>
>> For RT5 routes the extended community goes directly with the RT5 as
>> stated in the document.
>>
>>
>>
>> The IP aliasing draft, that we will refresh soon, will reference to this
>> draft and will allow the extended community to be advertised with A-D per
>> EVI routes in the IP-VRF context.
>>
>>
>>
>> Thanks.
>>
>> Jorge
>>
>>
>>
>> *From: *Fomin, Sergey (Nokia - US/Mountain View) 
>> *Date: *Wednesday, May 12, 2021 at 2:07 AM
>> *To: *Neeraj Malhotra , Rabadan, Jorge (Nokia -
>> US/Mountain View) 
>> *Cc: *slitkows.i...@gmail.com , BESS <
>> bess@ietf.org>, bruno.decra...@orange.com 
>> *Subject: *RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>>
>> Hi Neeraj, Jorge & all,
>>
>>
>>
>> Just wanted to clarify my previous message after a short chat with Jorge:
>> when I say “non-aliasing” case, I mean a scenario where eth. a-d per EVI
>> route is not used or generated [by PEs-1/2/3 in this example].
>>
>> It is indeed a relatively rare scenario which doesn’t bring much value,
>> so I’m open to drop support for it in this draft and just require eth. a-d
>> per EVI route to be present (=aliasing enabled) to support the procedures
>> described in this document.
>>
>>
>>
>> Thank you,
>>
>> --
>>
>> Sergey
>>
>> *From:* BESS  *On Behalf Of *Fomin, Sergey (Nokia
>> - US/Mountain View)
>> *Sent:* Tuesday, May 11, 2021 12:48 PM
>> *To:* bruno.decra...@orange.com; Neeraj Malhotra 
>> *Cc:* Rabadan, Jorge (Nokia - US/Mountain View) ;
>> slitkows.i...@gmail.com; BESS 
>> *Subject:* Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>>
>>
>>
>> Hi Neeraj & Bruno,
>>
>>
>>
>> Bruno,
>>
>> *   > Stricto census, what is needed is a single instance of
>> this sub-type and _Value-Units_. In order to accommodate one ingress PE in
>> a domain using “Weight in units of Mbps” and another ingress PE in a
&

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

[Neeraj Malhotra]

Hi Bruno, Sergey,

Thanks for the additional comments and discussion. To summarize, I plan to
address the following comments by this weekend:

*[Bruno] §4.1 & 5.2 have 3 iterations of “this attribute is to be ignored”.
I’m afraid one could read this as “this BGP attribute is to be ignored”.
Surely we mean “this(theses) EVPN Link Bandwidth extended community(ies)
is(are) to be ignored”.*


[NM]: ack.


*[Sergey] could we also expand text in section 5.2 “Remote PE behavior” a
little bit to include an example for non-aliased case where a MAC has been
learned only from a subset of PEs.*


[NM]: Although not ultra important, I think for completeness it will be
good to allow inclusion of the EC in RT-2 for non-aliasing ECMP use cases.
It is a simple extension similar to RT-5. Will add.


*[Bruno] in the draft §5.2 uses “remote PE” for the ingress PE while §4.1
uses “remote PE” for the egress PE  (“A receiving PE MUST check for
consistent 'Value-Units' received in the EVPN link bandwidth exteneded
community from each remote PE in an Ethernet Segment. » I’d assume that
terminology in §4.1 need to be fixed.*


[NM]: ack.


Please see inline for the following comment:


*[Bruno] Stricto census, what is needed is a single instance of this
sub-type and _Value-Units_. In order to accommodate one ingress PE in a
domain using “Weight in units of Mbps” and another ingress PE in a
different domain using “Generalized Weight”, one could imagine an egress PE
advertising 2 communities/both units. I have a slight preference for
allowing both, but up to you.*


[NM]: Yes, strictly speaking, this is correct. However, for simplicity, I
am inclined to have local/egress PEs that are part of the Ethernet Segment
specify a single / consistent weight unit they are going to use and have
the receiving/ingress PEs simply follow, rather than give ingress PEs a
choice of which units to choose out of multiple received units based on
some specified or locally provisioned precedence (implementation and
provisioning overhead as Sergey also commented).


Thanks,

Neeraj

On Tue, May 11, 2021 at 11:20 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Thanks Sergey. I agree with that, for Layer 2 aliasing.
>
> For RT5 routes the extended community goes directly with the RT5 as stated
> in the document.
>
>
>
> The IP aliasing draft, that we will refresh soon, will reference to this
> draft and will allow the extended community to be advertised with A-D per
> EVI routes in the IP-VRF context.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Fomin, Sergey (Nokia - US/Mountain View) 
> *Date: *Wednesday, May 12, 2021 at 2:07 AM
> *To: *Neeraj Malhotra , Rabadan, Jorge (Nokia -
> US/Mountain View) 
> *Cc: *slitkows.i...@gmail.com , BESS <
> bess@ietf.org>, bruno.decra...@orange.com 
> *Subject: *RE: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
> Hi Neeraj, Jorge & all,
>
>
>
> Just wanted to clarify my previous message after a short chat with Jorge:
> when I say “non-aliasing” case, I mean a scenario where eth. a-d per EVI
> route is not used or generated [by PEs-1/2/3 in this example].
>
> It is indeed a relatively rare scenario which doesn’t bring much value, so
> I’m open to drop support for it in this draft and just require eth. a-d per
> EVI route to be present (=aliasing enabled) to support the procedures
> described in this document.
>
>
>
> Thank you,
>
> --
>
> Sergey
>
> *From:* BESS  *On Behalf Of *Fomin, Sergey (Nokia
> - US/Mountain View)
> *Sent:* Tuesday, May 11, 2021 12:48 PM
> *To:* bruno.decra...@orange.com; Neeraj Malhotra 
> *Cc:* Rabadan, Jorge (Nokia - US/Mountain View) ;
> slitkows.i...@gmail.com; BESS 
> *Subject:* Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>
> Hi Neeraj & Bruno,
>
>
>
> Bruno,
>
> *   > Stricto census, what is needed is a single instance of
> this sub-type and _Value-Units_. In order to accommodate one ingress PE in
> a domain using “Weight in units of Mbps” and another ingress PE in a
> different domain using “Generalized Weight”, one could imagine an egress PE
> advertising 2 communities/both units.*
>
> By "egress PE", I'm assuming, you mean "local PE" in terms of this RFC
> (with an attached ES)?
>
> I'm not opposed to the idea, thought it adds a layer of implementation
> complexity.
>
> If you see this as a valid use case (somewhat exotic, for sure), it might
> be worth relaxing the requirement; in this case, we also should add a
> remark along the lines that “remote PE” logic how to select between 2
> types/sets of LBW communities is left up to the implementer / may be
> configurable; and support for attaching 2 types of communities at the same

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

[Neeraj Malhotra]

ontents
>- Section 6.2 contains a reference to a non-existing example in
>    Section 3 ("Considering the same example as in Section 3, ...), probably
>should point to 5.2?
>- Inconsistent spelling of "per ES/per-ES" (as in "Ethernet A-D per
>ES"). Probably should be whitespaced, not dashed (it is spelled this way in
>7432)
>
>
>
> --
>
> Sergey
>
>
>
> *From:* BESS  *On Behalf Of *
> bruno.decra...@orange.com
> *Sent:* Monday, May 10, 2021 5:55 AM
> *To:* Neeraj Malhotra 
> *Cc:* Rabadan, Jorge (Nokia - US/Mountain View) ;
> Sergey Fomin ; slitkows.i...@gmail.com; BESS <
> bess@ietf.org>
> *Subject:* Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>
> Hi Neeraj, co-authors,
>
>
>
> Thanks for taking into account the comments.
>
> -11 addresses my comments.
>
>
>
> Two comments on the new text:
>
> “EVPN Link Bandwidth Extended Community value field is to be treated
>
>as a 6 octet unsigned integer representing total bandwidth of PE's
>
>all physical links in an ethernet segment, expressed in Mbits/sec
>
>(MegabitsPerSecond). »
>
>
>
>
>
> Actually with your latest change introducing the new field “Value-unit”,
> bandwidth is encoded in only 5 octets (not 6). (I’m assuming that the new
> field “Value-unit” is not to be used when computing the ratio of bandwidth
> as this would make no sense).
>
>
>
> §5.2 Does not say anything with regards to the new field “Value-unit”. A
> priori, the ratio of bandwidth is only to be computed on bandwidth/EC using
> the same unit, no?
>
>
>
> Thanks,
>
> Regards,
>
> --Bruno
>
>
>
> *From:* Neeraj Malhotra [mailto:neeraj.i...@gmail.com
> ]
> *Sent:* Saturday, May 8, 2021 1:29 AM
> *To:* Sergey Fomin 
> *Cc:* DECRAENE Bruno TGI/OLN ; Rabadan, Jorge
> (Nokia - US/Mountain View) ;
> slitkows.i...@gmail.com; BESS 
> *Subject:* Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>
>
>
> Hi Sergey, Bruno,
>
>
>
> Many thanks for the detailed review and comments. Discussed with
> co-authors and have enhanced the 'value' encoding to explicitly encode
> weight units as default or generalized as suggested below. I have
> published a revision that incorporates all comments discussed on this
> thread, as well as some additional editorial comments from Jorge. Please
> let me know if there are any additional comments (in particular on section
> 4).
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> On Fri, May 7, 2021 at 12:33 PM Sergey Fomin  wrote:
>
> Hi Neeraj,
>
> thank you for the feedback.
>
>
>
> I agree that allocating a new code point for every possible calculation
> method would be cumbersome.
>
> How about a middle ground solution, with allocation of just a few values
> (even 2 would suffice: 1 for BW in whatever units we decide; the other
> "catch-all" generalized weight)?
>
> This way operators will get at least basic visibility & cfg. error
> prevention mechanism in place (I have a preference towards explicit
> signaling from ops point of view; but would be glad to hear operators
> opinion on this one).
>
>
>
> My concern with the current text is, while striving for maximum
> flexibility, we may end up in a situation where 2 implementations won't be
> able to interoperate with each other (e.g. vendor X decides to implement
> link BW as a metric, vendor Y decides to implement link count as a metric -
> since support for any method of weight calculation is completely
> optional). I believe we, as a technical community, should give guidance on
> implementing sensible defaults (i.e. "an implementation SHOULD support BW
> weight calculation method") where it makes sense.
>
>
>
> --
>
> Sergey
>
>
>
>
>
> 07.05.2021, 09:18, "Neeraj Malhotra" :
>
>
>
> Hi Sergey,
>
>
>
> Thanks for the comments. We would like to avoid adding another code point
> within the value field, as every new encoding of the "weight" will require
> a new code point. Agree that we should specify the default units (for which
> the consensus on the thread appears to be Mbps), but would rather leave it
> to implementations to support any additional units such as number of links,
> configured weight, or anything else, than have a standardized code point
> for each unit. Please let me know if this sounds fine. I will fix the units
> in section 5.2, and the text in section 4.1 as suggested by you and Bruno.
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> On Thu, May 6, 2021 at 9:19 PM  wrote:
>
> Hi Bruno

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

[Neeraj Malhotra]

Hi Bruno,

Thanks for catching this. Fixed both in the latest revision.

Neeraj

On Mon, May 10, 2021 at 5:54 AM  wrote:

> Hi Neeraj, co-authors,
>
>
>
> Thanks for taking into account the comments.
>
> -11 addresses my comments.
>
>
>
> Two comments on the new text:
>
> “EVPN Link Bandwidth Extended Community value field is to be treated
>
>as a 6 octet unsigned integer representing total bandwidth of PE's
>
>all physical links in an ethernet segment, expressed in Mbits/sec
>
>(MegabitsPerSecond). »
>
>
>
>
>
> Actually with your latest change introducing the new field “Value-unit”,
> bandwidth is encoded in only 5 octets (not 6). (I’m assuming that the new
> field “Value-unit” is not to be used when computing the ratio of bandwidth
> as this would make no sense).
>
>
>
> §5.2 Does not say anything with regards to the new field “Value-unit”. A
> priori, the ratio of bandwidth is only to be computed on bandwidth/EC using
> the same unit, no?
>
>
>
> Thanks,
>
> Regards,
>
> --Bruno
>
>
>
> *From**:* Neeraj Malhotra [mailto:neeraj.i...@gmail.com]
> *Sent:* Saturday, May 8, 2021 1:29 AM
> *To:* Sergey Fomin 
> *Cc:* DECRAENE Bruno TGI/OLN ; Rabadan, Jorge
> (Nokia - US/Mountain View) ;
> slitkows.i...@gmail.com; BESS 
> *Subject:* Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>
>
>
> Hi Sergey, Bruno,
>
>
>
> Many thanks for the detailed review and comments. Discussed with
> co-authors and have enhanced the 'value' encoding to explicitly encode
> weight units as default or generalized as suggested below. I have
> published a revision that incorporates all comments discussed on this
> thread, as well as some additional editorial comments from Jorge. Please
> let me know if there are any additional comments (in particular on section
> 4).
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> On Fri, May 7, 2021 at 12:33 PM Sergey Fomin  wrote:
>
> Hi Neeraj,
>
> thank you for the feedback.
>
>
>
> I agree that allocating a new code point for every possible calculation
> method would be cumbersome.
>
> How about a middle ground solution, with allocation of just a few values
> (even 2 would suffice: 1 for BW in whatever units we decide; the other
> "catch-all" generalized weight)?
>
> This way operators will get at least basic visibility & cfg. error
> prevention mechanism in place (I have a preference towards explicit
> signaling from ops point of view; but would be glad to hear operators
> opinion on this one).
>
>
>
> My concern with the current text is, while striving for maximum
> flexibility, we may end up in a situation where 2 implementations won't be
> able to interoperate with each other (e.g. vendor X decides to implement
> link BW as a metric, vendor Y decides to implement link count as a metric -
> since support for any method of weight calculation is completely
> optional). I believe we, as a technical community, should give guidance on
> implementing sensible defaults (i.e. "an implementation SHOULD support BW
> weight calculation method") where it makes sense.
>
>
>
> --
>
> Sergey
>
>
>
>
>
> 07.05.2021, 09:18, "Neeraj Malhotra" :
>
>
>
> Hi Sergey,
>
>
>
> Thanks for the comments. We would like to avoid adding another code point
> within the value field, as every new encoding of the "weight" will require
> a new code point. Agree that we should specify the default units (for which
> the consensus on the thread appears to be Mbps), but would rather leave it
> to implementations to support any additional units such as number of links,
> configured weight, or anything else, than have a standardized code point
> for each unit. Please let me know if this sounds fine. I will fix the units
> in section 5.2, and the text in section 4.1 as suggested by you and Bruno.
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> On Thu, May 6, 2021 at 9:19 PM  wrote:
>
> Hi Bruno, Jorge, et al.,
>
>
>
> Jorge,
>
> *> Among the co-authors we also discussed the possibility of defining two
> ECs: one for BW and one for a generalized-weight, so that the remote PE can
> catch if the multi-homed PEs were indeed using the same meaning of the
> weight. However, we thought it was easier/simpler to use a generalized
> value in a single EC sub-type, and add the sentence below. *
>
> Have you considered reserving a byte in the value field to signal a weight
> type? Similar to how it is done with DF election framework (and allocate a
> few right away, e.g. 0 for physical link BW, 1 for link count, 2 for

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

[Neeraj Malhotra]

Hi Sergey, Bruno,

Many thanks for the detailed review and comments. Discussed with co-authors
and have enhanced the 'value' encoding to explicitly encode weight units as
default or generalized as suggested below. I have published a revision that
incorporates all comments discussed on this thread, as well as some
additional editorial comments from Jorge. Please let me know if there are
any additional comments (in particular on section 4).

Thanks,
Neeraj

On Fri, May 7, 2021 at 12:33 PM Sergey Fomin  wrote:

> Hi Neeraj,
> thank you for the feedback.
>
> I agree that allocating a new code point for every possible calculation
> method would be cumbersome.
> How about a middle ground solution, with allocation of just a few values
> (even 2 would suffice: 1 for BW in whatever units we decide; the other
> "catch-all" generalized weight)?
> This way operators will get at least basic visibility & cfg. error
> prevention mechanism in place (I have a preference towards explicit
> signaling from ops point of view; but would be glad to hear operators
> opinion on this one).
>
> My concern with the current text is, while striving for maximum
> flexibility, we may end up in a situation where 2 implementations won't be
> able to interoperate with each other (e.g. vendor X decides to implement
> link BW as a metric, vendor Y decides to implement link count as a metric -
> since support for any method of weight calculation is completely
> optional). I believe we, as a technical community, should give guidance on
> implementing sensible defaults (i.e. "an implementation SHOULD support BW
> weight calculation method") where it makes sense.
>
> --
> Sergey
>
>
> 07.05.2021, 09:18, "Neeraj Malhotra" :
>
>
> Hi Sergey,
>
> Thanks for the comments. We would like to avoid adding another code point
> within the value field, as every new encoding of the "weight" will require
> a new code point. Agree that we should specify the default units (for which
> the consensus on the thread appears to be Mbps), but would rather leave it
> to implementations to support any additional units such as number of links,
> configured weight, or anything else, than have a standardized code point
> for each unit. Please let me know if this sounds fine. I will fix the units
> in section 5.2, and the text in section 4.1 as suggested by you and Bruno.
>
> Thanks,
> Neeraj
>
> On Thu, May 6, 2021 at 9:19 PM  wrote:
>
> Hi Bruno, Jorge, et al.,
>
>
>
> Jorge,
>
> *> Among the co-authors we also discussed the possibility of defining two
> ECs: one for BW and one for a generalized-weight, so that the remote PE can
> catch if the multi-homed PEs were indeed using the same meaning of the
> weight. However, we thought it was easier/simpler to use a generalized
> value in a single EC sub-type, and add the sentence below. *
>
> Have you considered reserving a byte in the value field to signal a weight
> type? Similar to how it is done with DF election framework (and allocate a
> few right away, e.g. 0 for physical link BW, 1 for link count, 2 for
> manually configured weight, ...). This would help not only with interop
> cases, but to prevent & diagnose potential configuration mistakes as well.
>
>
>
> For interop reasons, I would support Bruno & argue that it makes sense to
> use "SHOULD" normative language at least for one way of calculation (e.g.
> BW).
>
>
>
> A couple of minor comments on newly-introduced text in -09 and -10:
>
>1. Revision -10 introduced a curious change in section 5.2 “Remote PE
>Behavior”, replacing “1000 Mbps” with “1000 megabytes” in an example. It is
>not correct in the current form, since right above it there is an explicit
>statement that links are Gigabit Ethernet: *"As an example, for a CE
>dual-homed to PE-1, PE-2, PE-3 via 2, 1, and 1 GE physical links
>respectively".*
>
> (keeping the Mbps units there would be appropriate, since this is a weight
> calculation, not a community encoding example)
>
>1. Section 4.1 “Usage of EVPN Link Bandwidth Extended Community”:
>
> *“An implementation may support one or more of the above ways of encoding
> the value."* -> I would assume this should be "MUST support at least
> one", since every other possible option is included in bullet#2?
>
>
>
> --
>
> Sergey
>
> *From:* BESS  *On Behalf Of *
> bruno.decra...@orange.com
> *Sent:* Thursday, May 6, 2021 5:46 AM
> *To:* Rabadan, Jorge (Nokia - US/Mountain View) ;
> Neeraj Malhotra 
> *Cc:* slitkows.i...@gmail.com; bess@ietf.org
> *Subject:* Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

[Neeraj Malhotra]

Hi Sergey,

Thanks for the comments. We would like to avoid adding another code point
within the value field, as every new encoding of the "weight" will require
a new code point. Agree that we should specify the default units (for which
the consensus on the thread appears to be Mbps), but would rather leave it
to implementations to support any additional units such as number of links,
configured weight, or anything else, than have a standardized code point
for each unit. Please let me know if this sounds fine. I will fix the units
in section 5.2, and the text in section 4.1 as suggested by you and Bruno.

Thanks,
Neeraj

On Thu, May 6, 2021 at 9:19 PM  wrote:

> Hi Bruno, Jorge, et al.,
>
>
>
> Jorge,
>
> *> Among the co-authors we also discussed the possibility of defining two
> ECs: one for BW and one for a generalized-weight, so that the remote PE can
> catch if the multi-homed PEs were indeed using the same meaning of the
> weight. However, we thought it was easier/simpler to use a generalized
> value in a single EC sub-type, and add the sentence below. *
>
> Have you considered reserving a byte in the value field to signal a weight
> type? Similar to how it is done with DF election framework (and allocate a
> few right away, e.g. 0 for physical link BW, 1 for link count, 2 for
> manually configured weight, ...). This would help not only with interop
> cases, but to prevent & diagnose potential configuration mistakes as well.
>
>
>
> For interop reasons, I would support Bruno & argue that it makes sense to
> use "SHOULD" normative language at least for one way of calculation (e.g.
> BW).
>
>
>
> A couple of minor comments on newly-introduced text in -09 and -10:
>
>1. Revision -10 introduced a curious change in section 5.2 “Remote PE
>Behavior”, replacing “1000 Mbps” with “1000 megabytes” in an example. It is
>not correct in the current form, since right above it there is an explicit
>statement that links are Gigabit Ethernet: *"As an example, for a CE
>dual-homed to PE-1, PE-2, PE-3 via 2, 1, and 1 GE physical links
>respectively".*
>
> (keeping the Mbps units there would be appropriate, since this is a weight
> calculation, not a community encoding example)
>
>1. Section 4.1 “Usage of EVPN Link Bandwidth Extended Community”:
>
> *“An implementation may support one or more of the above ways of encoding
> the value."* -> I would assume this should be "MUST support at least
> one", since every other possible option is included in bullet#2?
>
>
>
> --
>
> Sergey
>
> *From:* BESS  *On Behalf Of *
> bruno.decra...@orange.com
> *Sent:* Thursday, May 6, 2021 5:46 AM
> *To:* Rabadan, Jorge (Nokia - US/Mountain View) ;
> Neeraj Malhotra 
> *Cc:* slitkows.i...@gmail.com; bess@ietf.org
> *Subject:* Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>
> Hi Jorge,
>
>
>
> Thanks for the feedback.
>
>
>
> Regarding the first point, I can live with the current text. But I think I
> would prefer that the text favour one option, and leave it to the
> responsibility of the SP for others usages. E.g.
>
>
>
> OLD:
>
> EVPN Link Bandwidth Extended Community value field is to be treated
>
>as a 6 octet unsigned integer that may be set to:
>
>
>
>o  total bandwidth of PE's all physical links in an ethernet segment,
>
>   expressed in bytes/sec.
>
>
>
>o  or a generalized weight that may be set to link count, locally
>
>   configured weight, or a value computed based on an attribute other
>
>   than link bandwidth.
>
>
>
>An implementation may support one or more of the above ways of
>
>encoding the value.  Operator MUST ensure consistent encoding of this
>
>value across all PEs in an ethernet segment.  Procedures related to
>
>signaling and handling of this extended community defined in this
>
>document use "total bandwidth in bytes/sec" encoding as an example to
>
>illustrate its usage.
>
>
>
> NEW:
>
>EVPN Link Bandwidth Extended Community value field is to be treated
>
>as a 6 octet unsigned integer representing total bandwidth of PE's all
> physical links in an ethernet segment,
>
>   expressed in bytes/sec.
>
>
>
> Note however that the load balancing algorithm defines in this document
> uses ratio of Link Bandwidths hence the operator may choose a different
> unit or use the community as
>
> a generalized weight that may be set to link count, locally
>
>   configured weight, or a value computed based on an attribute other
>
>   than link bandwidth. In

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

[Neeraj Malhotra]

Hi Bruno,

Many thanks for the review comments. We have revised the draft addressing
your comments.

More inline.

Thanks,
Neeraj

On Mon, May 3, 2021 at 2:20 AM  wrote:

> Hi Stéphane, authors,
>
>
>
> I have not followed the discussions on this document, but I’ll nonetheless
> raise one point  regarding the bandwidth community (better safe than
> sorry).
>
> - why has [BGP-LINK-BW] been moved to informational reference while its
> reading seem mandatory?
>

[NM]: There was a leftover reference to this in one of the sections that
has been fixed now to use new EVPN EC. With this, reference to
[BGP-LINK-BW] is purely informational (as was intended).


> - A new EVPN Link Bandwidth extended community is defined, but I could not
> find its specification. I guess that this is the same format as
> [BGP-LINK-BW] but transitive. Could this be explicitly stated?
>

[NM]: clarified in section 4.


> - [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per
> second. Could the unit of the new EVPN Link Bandwidth extended community be
> also clearly spelled out? Especially give the history on this (cf below).
> Also in order to avoid misleading the readers could the examples use the
> correct unit (vs bits per seconds as writen)
>

[NM]: done.


> - 10 years ago or so, I had raised a similar point (distinction between
> bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1
> major implementation had implemented and deployed “bytes per second” as per
> the spec, while another implementation had implemented and deployed “bits
> per second” which is the typical unit of link bandwidth. Given the
> deployments, none was willing to change its implementation as it would be a
> non-backward compatible change with themselves. What’s the status on this?
> Could we have an implementation status on this?
>

[NM]: I don't have this information. Perhaps someone else could comment.


>
>
> Thanks
>
> Regards,
>
> --Bruno
>
>
>
>
>
> *From**:* BESS [mailto:bess-boun...@ietf.org] *On Behalf Of *
> slitkows.i...@gmail.com
> *Sent:* Monday, May 3, 2021 9:21 AM
> *To:* bess@ietf.org
> *Subject:* [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>
> Hi WG,
>
>
>
>
>
> We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
>
>
>
> I'm opening a new short Working Group Last Call (to be closed on 5/10) to
>
> get any last comments before moving to the next step.
>
> However, the document having normative references to EVPN PREF DF, and 
> PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are 
> ready.
>
>
>
>  Feel free to send comments to the list before next Monday.
>
>
>
>
>
> Thanks,
>
>
>
>
>
> Stephane
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
>
>
>
>
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG and IPR poll adoption poll for draft-krattiger-evpn-modes-interop

[Neeraj Malhotra]

Hi,

Support adoption. Indeed, much needed!!

Thanks,
Neeraj

On Mon, Apr 19, 2021 at 11:06 AM  wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-krattiger-evpn-modes-interop-03 [1].
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> 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, copying the BESS mailing list. The document will
> not  progress without answers from all of the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> 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.
>
>
>
> This poll for adoption closes on 4th May 2021.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
>
>
> [1]  https://datatracker.ietf.org/doc/draft-krattiger-evpn-modes-interop/
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-irb-extended-mobility-01

[Neeraj Malhotra]

Hi Stephane,

Just fyi - new revision that addresses comments on this thread has been
uploaded.

Thanks,
Neeraj

On Thu, Feb 11, 2021 at 12:20 AM  wrote:

> Hi Authors,
>
>
>
> Please address the comments raised by the WG members before we move
> forward.
>
> I have fixed the dependency to the individual draft, so now the IPR
> appears on the WG doc.
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
> *From:* Acee Lindem (acee) 
> *Sent:* lundi 18 janvier 2021 18:25
> *To:* slitkows.i...@gmail.com; bess@ietf.org
> *Cc:* bess-cha...@ietf.org
> *Subject:* Re: [bess] WG Last Call, IPR and Implementation Poll for
> draft-ietf-bess-evpn-irb-extended-mobility-01
>
>
>
> Hi Stephane, et al,
>
> I did another quick read of the draft and I support publication. I think
> it would be good to state in the introduction which sections of the draft
> our normative and which are informative.
>
> Thanks,
>
> Acee
>
>
>
> *From: *BESS  on behalf of "slitkows.i...@gmail.com"
> 
> *Date: *Monday, January 18, 2021 at 3:58 AM
> *To: *"bess@ietf.org" 
> *Cc: *"bess-cha...@ietf.org" 
> *Subject: *[bess] WG Last Call, IPR and Implementation Poll for
> draft-ietf-bess-evpn-irb-extended-mobility-01
>
>
>
> This email starts a two-week working group last call for
> draft-ietf-bess-evpn-irb-extended-mobility-01 [1]
>
>
>
>
>
>
>
> 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 February 1st.
>
>
>
>
>
>
>
> 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.
>
>
>
> In addition, we are polling for knowledge of implementations of this
> draft, per the BESS policy in [2].
>
>
>
>
>
> Thank you,
>
>
>
> Matthew & Stephane
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> 
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-irb-extended-mobility-01

[Neeraj Malhotra]

Hi,

Thanks Stephane. Will update very soon.

Neeraj

> On Feb 11, 2021, at 12:20 AM, slitkows.i...@gmail.com wrote:
> 
> 
> Hi Authors,
>  
> Please address the comments raised by the WG members before we move forward.
> I have fixed the dependency to the individual draft, so now the IPR appears 
> on the WG doc.
>  
> Brgds,
>  
> Stephane
>  
>  
> From: Acee Lindem (acee)  
> Sent: lundi 18 janvier 2021 18:25
> To: slitkows.i...@gmail.com; bess@ietf.org
> Cc: bess-cha...@ietf.org
> Subject: Re: [bess] WG Last Call, IPR and Implementation Poll for 
> draft-ietf-bess-evpn-irb-extended-mobility-01
>  
> Hi Stephane, et al,
> I did another quick read of the draft and I support publication. I think it 
> would be good to state in the introduction which sections of the draft our 
> normative and which are informative.
> Thanks,
> Acee
>  
> From: BESS  on behalf of "slitkows.i...@gmail.com" 
> 
> Date: Monday, January 18, 2021 at 3:58 AM
> To: "bess@ietf.org" 
> Cc: "bess-cha...@ietf.org" 
> Subject: [bess] WG Last Call, IPR and Implementation Poll for 
> draft-ietf-bess-evpn-irb-extended-mobility-01
>  
> This email starts a two-week working group last call for 
> draft-ietf-bess-evpn-irb-extended-mobility-01 [1]
>  
>  
>  
> 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 February 1st.
>  
>  
>  
> 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.
>  
> In addition, we are polling for knowledge of implementations of this draft, 
> per the BESS policy in [2].   
>  
>  
> Thank you,
>  
> Matthew & Stephane
>  
> [1] 
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>  
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-irb-extended-mobility-01

[Neeraj Malhotra]

Hi,

Thanks Anoop. Sure, will add the security consideration section.

Neeraj

On Fri, Jan 29, 2021 at 9:04 PM Anoop Ghanwani 
wrote:

> The security considerations section is empty.  Is it possible to have that
> updated before the WGLC?
>
> I will try to review and provide more detailed comments.
>
> On Mon, Jan 18, 2021 at 12:58 AM  wrote:
>
>> This email starts a two-week working group last call for
>> draft-ietf-bess-evpn-irb-extended-mobility-01 [1]
>>
>>
>>
>>
>>
>>
>>
>> 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 February 1st.
>>
>>
>>
>>
>>
>>
>>
>> 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.
>>
>>
>>
>> In addition, we are polling for knowledge of implementations of this
>> draft, per the BESS policy in [2].
>>
>>
>>
>>
>>
>> Thank you,
>>
>>
>>
>> Matthew & Stephane
>>
>>
>>
>> [1]
>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
>>
>> [2]
>> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>> 
>>
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-irb-extended-mobility-01

[Neeraj Malhotra]

Hi,

missed mentioning earlier that there are known implementations of this draft.

Thanks,
Neeraj

> On Feb 2, 2021, at 12:06 AM, Neeraj Malhotra  wrote:
> 
> 
> 
> Hi,
> 
> Support as co-author. Not aware of any undisclosed IPR.
> 
> Thanks,
> Neeraj
> 
>> On Mon, Jan 18, 2021 at 12:58 AM  wrote:
>> This email starts a two-week working group last call for 
>> draft-ietf-bess-evpn-irb-extended-mobility-01 [1]
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> 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 February 1st.
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> 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.
>> 
>>  
>> 
>> In addition, we are polling for knowledge of implementations of this draft, 
>> per the BESS policy in [2].   
>> 
>>  
>> 
>>  
>> 
>> Thank you,
>> 
>>  
>> 
>> Matthew & Stephane
>> 
>>  
>> 
>> [1] 
>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
>> 
>> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>> 
>>  
>> 
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-irb-extended-mobility-01

[Neeraj Malhotra]

Hi,

Support as co-author. Not aware of any undisclosed IPR.

Thanks,
Neeraj

On Mon, Jan 18, 2021 at 12:58 AM  wrote:

> This email starts a two-week working group last call for
> draft-ietf-bess-evpn-irb-extended-mobility-01 [1]
>
>
>
>
>
>
>
> 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 February 1st.
>
>
>
>
>
>
>
> 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.
>
>
>
> In addition, we are polling for knowledge of implementations of this
> draft, per the BESS policy in [2].
>
>
>
>
>
> Thank you,
>
>
>
> Matthew & Stephane
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> 
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01

[Neeraj Malhotra]

Hi,

Support.

Thanks,
Neeraj

> On Dec 10, 2020, at 11:05 AM, Dongling Duan (duan) 
>  wrote:
> 
> 
> Support
>  
> Regards
> Dongling Duan
>  
> From: BESS  On Behalf Of Bocci, Matthew (Nokia - GB)
> Sent: Wednesday, December 9, 2020 1:23 AM
> To: bess@ietf.org
> Cc: draft-mohanty-bess-weighted-...@ietf.org
> Subject: [bess] WG adoption and IPR poll for 
> draft-mohanty-bess-weighted-hrw-01
>  
> Hello,
>  
> This email begins a two-week WG adoption poll for 
> draft-mohanty-bess-weighted-hrw-01 [1].
>  
> Please review the draft and post any comments to the BESS working group list.
>  
> 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, copying the BESS mailing list. The document will 
> not  progress without answers from all of the authors and contributors.
>  
> Currently, there are no IPR disclosures against this document.
>  
> 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.
>  
> This poll for adoption closes on 23rd December 2020.
>  
> Regards,
> Matthew and Stephane
>  
> [1]  https://datatracker.ietf.org/doc/draft-mohanty-bess-weighted-hrw/
>  
>  
>  
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] New Extended Community for draft-ietf-bess-evpn-unequal-lb

[Neeraj Malhotra]

Hi Jeff,

Many thanks for the confirmation and detailed explanation / review. We will
move forward with the new code point for EVPN.

With respect to your comment in the last paragraph, your understanding is
correct - primary use case for this attribute is for it to be carried in
Type 1 route within and across EVPN domains. It would not be stripped at
the domain border. Will update the text to make sure this is clear.

Thanks,
Neeraj

On Wed, Nov 11, 2020 at 12:09 PM Jeffrey Haas  wrote:

> Neeraj,
>
> Thanks for reminding me to comment on the draft's Link Bandwidth
> procedures.
>
> The existing link bandwidth feature, defined in an expired Internet-Draft,
> is a non-transitive extended community.
>
> Part of the comments I'd given at prior BESS sessions at the microphone
> was that Juniper has used a similar code point with the transitive
> behavior.  This does create an interoperability problem between the
> published non-transitive and Juniper's transitive extended community.
>
> Part of that discussion was with regards to whether this was motivation
> for Juniper to help clean up that situation.  I believe that based on the
> text in your current draft that making using of the transitive code point
> used by Juniper is likely not a good fit for your EVPN use case.  Based on
> that, I believe the request in the Internet-Draft for a new transitive code
> point is appropriate and I have no objections or further concerns.
>
> By using split code points for general purpose BGP link bandwidth and EVPN
> link bandwidth, we accommodate not only load balancing at the EVPN level,
> but help avoid confusion when EVPN routes' nexthops may recursively resolve
> in some situations across other BGP transport routes that may have their
> own link bandwidth available.  Exactly how that interaction in recursive
> resolution is implemented will likely be somewhat vendor dependent as it
> currently is for existing BGP use cases of link-bandwidth.
>
> Section 4.2 notes that the signaling may be used in an inter-as
> situation.  If my reading of the draft is correct, then the expected use
> case is primarily to add the new EVPN link bandwidth route on Type 1
> routes.  If so, containing the scoping of the distribution of those routes
> is mostly limited to a set of EVPN domains that interact with each other.
> You may wish to consider whether guidance for stripping this new Extended
> Community at such domain borders is necessary or not.
>
> Thanks for addressing my concerns.
>
> -- Jeff
>
>
> On Oct 14, 2020, at 2:24 PM, Neeraj Malhotra 
> wrote:
> Hi John, Jeff,
>
> FYI - latest revision of this draft corrects the BW attribute to be
> transitive inline with Ali's explanation below:
> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-07.txt
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-07.txt__;!!NEt6yMaO-gk!WpGNLTp80vY1SOBO7xUowqXjTj64Jwdl9QBfcynQ1zzzTYjC43p-e0M7uc4hpSk$>.
> Please do let us know if there are any further concerns.
>
> 4.2.  EVPN Link Bandwidth Extended Community
>
>
>
>A new EVPN Link Bandwidth extended community is defined to signal
>
>local ES link bandwidth to remote PEs.  This extended-community is
>
>defined of type 0x06 (EVPN).  IANA is requested to assign a 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.
>
>
>
>Link bandwidth extended community described in [BGP-LINK-BW] for
>
>layer 3 VPNs was considered for re-use here.  This Link bandwidth
>
>extended community is however defined in [BGP-LINK-BW] as optional
>
>non-transitive.  Since it is not possible to change deployed behavior
>
>of extended-community defined in [BGP-LINK-BW], it was decided to
>
>define a new one.  In inter-AS scenarios, link-bandwidth needs to be
>
>signaled to eBGP neighbors.  When signaled across AS boundary, this
>
>attribute can be used to achieve optimal load-balancing towards
>
>source PEs from a different AS.  This is applicable both when next-
>
>hop is changed or unchanged across AS boundaries.
>
>
>
> Thanks,
>
> Neeraj
>
>
> On Thu, Jul 30, 2020 at 11:14 PM Ali Sajassi (sajassi)  40cisco@dmarc.ietf.org> wrote:
>
>> John, Jeff:
>>
>>
>>
>> During the presentation of draft-ietf-bess-evpn-unequal-lb -03 at the
>> BESS WG meeting, you had a question/concern regarding why we are defining a
>> new EC if we are doing conditional transitive. First, I’d like to make a
>> correction to the preso by

Re: [bess] WGLC and IPR poll on draft-ietf-bess-evpn-ipvpn-interworking-03

[Neeraj Malhotra]

Hi,

Support.

Thanks,
Neeraj


On Mon, Nov 9, 2020 at 12:20 AM  wrote:

> Hello WG,
>
>
>
> This email starts a three weeks Working Group Last Call on
> draft-ietf-bess-evpn-ipvpn-interworking-03 [1]. We add an additional week
> due to the upcoming IETF meeting.
>
>
>
> This poll runs until * the 30th Of  November *.
>
>
>
> 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-ipvpn-interworking/
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] New Extended Community for draft-ietf-bess-evpn-unequal-lb

[Neeraj Malhotra]

Hi John, Jeff,

Could you please confirm that you are fine with the revised text below or if 
you have any further input?

Thanks,
Neeraj

> On Oct 14, 2020, at 11:24 AM, Neeraj Malhotra  wrote:
> 
> 
> 
> Hi John, Jeff,
> 
> FYI - latest revision of this draft corrects the BW attribute to be 
> transitive inline with Ali's explanation below: 
> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-07.txt. 
> Please do let us know if there are any further concerns.
> 
> 4.2.  EVPN Link Bandwidth Extended Community
>  
>A new EVPN Link Bandwidth extended community is defined to signal
>local ES link bandwidth to remote PEs.  This extended-community is
>defined of type 0x06 (EVPN).  IANA is requested to assign a 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.
>  
>Link bandwidth extended community described in [BGP-LINK-BW] for
>layer 3 VPNs was considered for re-use here.  This Link bandwidth
>extended community is however defined in [BGP-LINK-BW] as optional
>non-transitive.  Since it is not possible to change deployed behavior
>of extended-community defined in [BGP-LINK-BW], it was decided to
>define a new one.  In inter-AS scenarios, link-bandwidth needs to be
>signaled to eBGP neighbors.  When signaled across AS boundary, this
>attribute can be used to achieve optimal load-balancing towards
>source PEs from a different AS.  This is applicable both when next-
>hop is changed or unchanged across AS boundaries.
> 
> 
> Thanks,
> Neeraj
> 
>> On Thu, Jul 30, 2020 at 11:14 PM Ali Sajassi (sajassi) 
>>  wrote:
>> John, Jeff:
>> 
>>  
>> 
>> During the presentation of draft-ietf-bess-evpn-unequal-lb -03 at the BESS 
>> WG meeting, you had a question/concern regarding why we are defining a new 
>> EC if we are doing conditional transitive. First, I’d like to make a 
>> correction to the preso by saying that the transitivity is not conditional 
>> and we will correct this in the next rev of the draft. So, the EC is simply 
>> transitive at all time. Given the EC defined in 
>> draft-ietf-idr-link-bandwidth-07.txt is non-transitive, we cannot use this 
>> EC for our application. That’s why we are defining a new one.
>> 
>>  
>> 
>> Cheers,
>> 
>> Ali
>> 
>>  
>> 
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] draft-ietf-bess-evpn-unequal-lb / meeting agenda

[Neeraj Malhotra (nmalhotr)]

Hi Stephane, Mankamana,

Regarding "draft-ietf-bess-evpn-unequal-lb", I don't think we need a dedicated 
slot for this in the meeting next week, but we would like to ask for WGLC. This 
draft has been revised to address the concerns that were raised in the last 
BESS meeting, specifically related to link BW attribute definition (please see 
attached thread).

Could you please put on your agenda for next week's meeting to poll the WG that 
there are no further concerns?

Thanks,
Neeraj

--- Begin Message ---


-- Forwarded message -----
From: Neeraj Malhotra 
Date: Wed, Oct 14, 2020 at 11:24 AM
Subject: Re: [bess] New Extended Community for draft-ietf-bess-evpn-unequal-lb
To: Ali Sajassi (sajassi) 
Cc: John Scudder , Jeff Haas , 
bess@ietf.org 



Hi John, Jeff,

FYI - latest revision of this draft corrects the BW attribute to be transitive 
inline with Ali's explanation below: 
https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-07.txt. Please 
do let us know if there are any further concerns.

4.2.  EVPN Link Bandwidth Extended Community
 
   A new EVPN Link Bandwidth extended community is defined to signal
   local ES link bandwidth to remote PEs.  This extended-community is
   defined of type 0x06 (EVPN).  IANA is requested to assign a 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.
 
   Link bandwidth extended community described in [BGP-LINK-BW] for
   layer 3 VPNs was considered for re-use here.  This Link bandwidth
   extended community is however defined in [BGP-LINK-BW] as optional
   non-transitive.  Since it is not possible to change deployed behavior
   of extended-community defined in [BGP-LINK-BW], it was decided to
   define a new one.  In inter-AS scenarios, link-bandwidth needs to be
   signaled to eBGP neighbors.  When signaled across AS boundary, this
   attribute can be used to achieve optimal load-balancing towards
   source PEs from a different AS.  This is applicable both when next-
   hop is changed or unchanged across AS boundaries.


Thanks,
Neeraj

On Thu, Jul 30, 2020 at 11:14 PM Ali Sajassi (sajassi) 
 wrote:
John, Jeff:

 

During the presentation of draft-ietf-bess-evpn-unequal-lb -03 at the BESS WG 
meeting, you had a question/concern regarding why we are defining a new EC if 
we are doing conditional transitive. First, I’d like to make a correction to 
the preso by saying that the transitivity is not conditional and we will 
correct this in the next rev of the draft. So, the EC is simply transitive at 
all time. Given the EC defined in draft-ietf-idr-link-bandwidth-07.txt is 
non-transitive, we cannot use this EC for our application. That’s why we are 
defining a new one. 

 

Cheers,

Ali

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

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

Re: [bess] New Extended Community for draft-ietf-bess-evpn-unequal-lb

[Neeraj Malhotra]

Hi John, Jeff,

FYI - latest revision of this draft corrects the BW attribute to be
transitive inline with Ali's explanation below:
https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-07.txt.
Please do let us know if there are any further concerns.

4.2.  EVPN Link Bandwidth Extended Community



   A new EVPN Link Bandwidth extended community is defined to signal

   local ES link bandwidth to remote PEs.  This extended-community is

   defined of type 0x06 (EVPN).  IANA is requested to assign a 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.



   Link bandwidth extended community described in [BGP-LINK-BW] for

   layer 3 VPNs was considered for re-use here.  This Link bandwidth

   extended community is however defined in [BGP-LINK-BW] as optional

   non-transitive.  Since it is not possible to change deployed behavior

   of extended-community defined in [BGP-LINK-BW], it was decided to

   define a new one.  In inter-AS scenarios, link-bandwidth needs to be

   signaled to eBGP neighbors.  When signaled across AS boundary, this

   attribute can be used to achieve optimal load-balancing towards

   source PEs from a different AS.  This is applicable both when next-

   hop is changed or unchanged across AS boundaries.



Thanks,

Neeraj


On Thu, Jul 30, 2020 at 11:14 PM Ali Sajassi (sajassi)  wrote:

> John, Jeff:
>
>
>
> During the presentation of draft-ietf-bess-evpn-unequal-lb -03 at the BESS
> WG meeting, you had a question/concern regarding why we are defining a new
> EC if we are doing conditional transitive. First, I’d like to make a
> correction to the preso by saying that the transitivity is not conditional
> and we will correct this in the next rev of the draft. So, the EC is simply
> transitive at all time. Given the EC defined in
> draft-ietf-idr-link-bandwidth-07.txt is non-transitive, we cannot use this
> EC for our application. That’s why we are defining a new one.
>
>
>
> Cheers,
>
> Ali
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Neeraj Malhotra]

Hi,

Support as co-author. Not aware of any IPR.

Thanks,
Neeraj


On Fri, Jan 17, 2020 at 12:56 AM  wrote:

> 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
>
> [2] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[Neeraj Malhotra]

Hi,

Support adoption.

Thanks,
Neeraj

> On Nov 27, 2019, at 4:36 AM, Bocci, Matthew (Nokia - GB) 
>  wrote:
> 
> Hello,
>  
> This email begins a two-weeks WG adoption poll for 
> draft-litkowski-bess-rfc5549revision-00 [1] .
>  
> Please review the draft and post any comments to the BESS working group list.
>  
> 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, copying the BESS mailing list. The document won't 
> progress without answers from all the authors and contributors.
>  
> Currently, there are no IPR disclosures against this document.
>  
> 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.
>  
> This poll for adoption closes on Wednesday 11th December 2019.  
>  
> Regards,
> Matthew
>  
> [1] https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/
>  
>  
>  
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll for draft-sajassi-bess-evpn-mvpn-seamless-interop

[Neeraj Malhotra]

Hi,

Support.

Thanks,
Neeraj

> On Oct 28, 2019, at 3:10 AM,  
>  wrote:
> 
> Hello,
>  
> This email begins a two-weeks WG adoption poll for 
> draft-sajassi-bess-evpn-mvpn-seamless-interop [1] ..
>  
> Please review the draft and post any comments to the BESS working group list.
>  
> 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, copying the BESS mailing list. The document won't 
> progress without answers from all the authors and contributors.
> Currently, there are no IPR disclosures against this document.
>  
> 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.
>  
> This poll for adoption closes on 11th November 2019.  
>  
> Regards,
> Matthew and Stephane
>  
> [1] 
> https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-mvpn-seamless-interop/
>  
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-pref-df

[Neeraj Malhotra]

Hi,

Support.

Thanks,
Neeraj

> On Oct 22, 2019, at 7:46 AM,  
>  wrote:
> 
> Hello WG,
>  
> This email starts a two weeks Working Group Last Call on 
> draft-ietf-bess-evpn-pref-df-04 [1].
>  
> This poll runs until * the 5th Of November *.
>  
> 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-pref-df/
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-keyupate-bess-evpn-virtual-hub-02

[Neeraj Malhotra]

Hi,

Support adoption.

Few comments below that may be considered for next revision following
adoption:

   - assume that proxy ARP behavior described in section 5.2 applies to
   proxy for a remote host only (not local hosts). would be good to clarify.
   - Fix terminology - "PE" and "NVE" used interchangeably across the
   document, e.g., section 5.3. Best to use "PE" everywhere.
   - Mass withdraw - consider propagating per-ES A-D routes to all V-spokes
   upfront as they do not result in any forwarding programming by themselves.
   Making advertisement / withdraw of these routes dependent on host routes
   advertised to remote v-spokes may result in  unnecessary complexity and
   exposure to race conditions.
   - IRB behavior described in section 6.3 seems to be applicable to
   symmetric IRB only. Would be good to clarify if symmetric IRB
   implementation is assumed for this draft.


Thanks,

Neeraj

On Wed, Sep 4, 2019 at 1:36 AM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> This email begins a two-week poll for adoption for
> draft-keyupate-bess-evpn-virtual-hub-02
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> 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, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
>
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond to the IPR poll only if you are aware of any IPR that
> has not yet been disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on Wednesday 18th September 2019.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-igmp-mld-proxy

[Neeraj Malhotra]

Hi,

Support.

Thanks,
Neeraj

On Mon, Jun 17, 2019 at 1:53 AM  wrote:

> Hello Working Group,
>
>
>
> This email starts a three weeks Working Group Last Call on
>  draft-ietf-bess-evpn-igmp-mld-proxy [1].
>
>
>
> This poll runs until *the 28th 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.
>
>
>
> We have several IPRs already 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-igmp-mld-proxy/
>
> [2]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
>
>
>
>
>
> [image: Orange logo] 
>
>
>
> *Stephane Litkowski *
> Network Architect
> Orange/SCE/EQUANT/OINIS/NET
>
> Orange Expert Future Networks
>
> phone: +33 2 23 *06* 49 83
> 
>  NEW !
> mobile: +33 6 71 63 27 50
> 
>  NEW !
> stephane.litkow...@orange.com
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption and IPR poll for draft-malhotra-bess-evpn-irb-extended-mobility-04

[Neeraj Malhotra]

Hi,

Support as co-author. Not aware of any undisclosed IPRs.

Thanks,
Neeraj


On Tue, Mar 5, 2019 at 12:42 AM  wrote:

> Hi,
>
>
>
> This email begins a two-week poll for adoption of 
> draft-malhotra-bess-evpn-irb-extended-mobility-04
>
> [1]
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> 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, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> 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.
>
>
>
> This poll for adoption closes on 19th March 2019.
>
>
>
> Regards,
>
> Stephane and Matthew
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-irb-extended-mobility/
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Last Call: (Framework for EVPN Designated Forwarder Election Extensibility) to Proposed Standard

[Neeraj Malhotra]

Hi,

Very solid and understandable. Couple of minor comments [NM]:

Section 2.1: Layer-2 devices are particularly susceptible to
forwarding loops because of the broadcast nature of the Ethernet
traffic.

[NM]: better to refer to "Layer-2 services" instead of "Layer-2
devices" as the CE or PE devices themselves may be layer-3 capable.

Section 4.2: Note that while the DF election algorithm in [RFC7432]
uses PE address and vlan as inputs, this document uses Ethernet Tag,
PE address and ESI as inputs.

[NM]: I think the text in this context uses "vlan" and "Ethernet Tag"
interchangeably. Since the above is trying to emphasize the use of
"ESI" in this document as the key differentiation, clearer to have
other two variables (vlan and PE address) read the same, or else it
makes you wonder if there is a difference between vlan and ethernet
tag in this context.

Thanks,

Neeraj


On Tue, Dec 4, 2018 at 4:59 PM The IESG  wrote:

>
> The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
> consider the following document: - 'Framework for EVPN Designated Forwarder
> Election Extensibility'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2018-12-18. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>The Designated Forwarder (DF) in EVPN networks is the Provider Edge
>(PE) router responsible for sending broadcast, unknown unicast and
>multicast (BUM) traffic to a multi-homed Customer Equipment (CE)
>device, on a given VLAN on a particular Ethernet Segment (ES). The DF
>is selected out of a list of candidate PEs that advertise the same
>Ethernet Segment Identifier (ESI) to the EVPN network. By default,
>EVPN uses a DF Election algorithm referred to as "Service Carving"
>and it is based on a modulus function (V mod N) that takes the number
>of PEs in the ES (N) and the VLAN value (V) as input. This default DF
>Election algorithm has some inefficiencies that this document
>addresses by defining a new DF Election algorithm and a capability to
>influence the DF Election result for a VLAN, depending on the state
>of the associated Attachment Circuit (AC). In addition, this document
>creates a registry with IANA, for future DF Election Algorithms and
>Capabilities. It also presents a formal definition and clarification
>of the DF Election Finite State Machine.
>
>
>
>
>
> The file can be obtained via
>
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/
>
> IESG discussion can be tracked via
>
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Last Call: (Framework for EVPN Designated Forwarder Election Extensibility) to Proposed Standard

[Neeraj Malhotra]

Hi,

Very solid and understandable. Couple of minor comments [NM]:

Section 2.1: Layer-2 devices are particularly susceptible to
forwarding loops because of the broadcast nature of the Ethernet
traffic.

[NM]: better to refer to "Layer-2 services" instead of "Layer-2
devices" as the CE or PE devices themselves may be layer-3 capable.

Section 4.2: Note that while the DF election algorithm in [RFC7432]
uses PE address and vlan as inputs, this document uses Ethernet Tag,
PE address and ESI as inputs.

[NM]: I think the text in this context uses "vlan" and "Ethernet Tag"
interchangeably. Since the above is trying to emphasize the use of
"ESI" in this document as the key differentiation, clearer to have
other two variables (vlan and PE address) read the same, or else it
makes you wonder if there is a difference between vlan and ethernet
tag in this context.


Thanks,

Neeraj


On Tue, Dec 4, 2018 at 4:59 PM The IESG  wrote:

>
> The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
> consider the following document: - 'Framework for EVPN Designated Forwarder
> Election Extensibility'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2018-12-18. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>The Designated Forwarder (DF) in EVPN networks is the Provider Edge
>(PE) router responsible for sending broadcast, unknown unicast and
>multicast (BUM) traffic to a multi-homed Customer Equipment (CE)
>device, on a given VLAN on a particular Ethernet Segment (ES). The DF
>is selected out of a list of candidate PEs that advertise the same
>Ethernet Segment Identifier (ESI) to the EVPN network. By default,
>EVPN uses a DF Election algorithm referred to as "Service Carving"
>and it is based on a modulus function (V mod N) that takes the number
>of PEs in the ES (N) and the VLAN value (V) as input. This default DF
>Election algorithm has some inefficiencies that this document
>addresses by defining a new DF Election algorithm and a capability to
>influence the DF Election result for a VLAN, depending on the state
>of the associated Attachment Circuit (AC). In addition, this document
>creates a registry with IANA, for future DF Election Algorithms and
>Capabilities. It also presents a formal definition and clarification
>of the DF Election Finite State Machine.
>
>
>
>
>
> The file can be obtained via
>
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/
>
> IESG discussion can be tracked via
>
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll for draft-malhotra-bess-evpn-unequal-lb-04

[Neeraj Malhotra]

Hi,

Support WG adoption as co-author. I am not aware of any IPR related to this
document.

Thanks,
Neeraj


On Tue, Sep 4, 2018 at 12:29 AM  wrote:

> Hi WG,
>
>
>
> This email begins a two-week poll for BESS working group adoption
> draft-malhotra-bess-evpn-unequal-lb-04 [1]
>
>
>
> Please review the draft and post any comments to the BESS working group
> list, stating whether or not you support adoption.
>
>
>
> 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, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
>
>
> 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.
>
>
>
> The poll for working group adoption closes on Tue 18th September.
>
>
>
> Regards,
>
> Stéphane and Matthew
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-unequal-lb/
>
>
>
>
>
>
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

[Neeraj Malhotra]

Hi,

Support.

Thanks,
Neeraj

On Wed, Aug 8, 2018 at 7:03 AM  wrote:

> Hello working group,
>
>
>
> This email starts a two-week Working Group Last Call on
> draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].
>
>
>
> A significant amount of update has been introduced since the previous
> WGLC. Please review the updates and provide your feedback.
>
>
>
> This poll runs until *the 22th of August*.
>
>
>
>
>
> Thank you
>
>
>
> Stéphane, Matthew
>
> bess chairs
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll and IPR poll for draft-sajassi-bess-evpn-per-mcast-flow-df-election

[Neeraj Malhotra]

Hi,

Support WH adoption.

Thanks,
Neeraj

> 
>> On Wed, 8 Aug 2018 at 06:38,  wrote:
>> Hi WG,
>> 
>>  
>> 
>> This email begins a two-week poll for BESS working group adoption of 
>> draft-sajassi-bess-evpn-per-mcast-flow-df-election-01 [1]
>> 
>>  
>> 
>> Please review the draft and post any comments to the BESS working group 
>> list, stating whether or not you support adoption.
>> 
>>  
>> 
>> 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, copying the BESS mailing list. The document won't 
>> progress without answers from all the authors and contributors.
>> 
>>  
>> 
>> 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.
>> 
>>  
>> 
>> The poll for working group adoption closes on Wed 22th Aug.  
>> 
>>  
>> 
>> Regards,
>> 
>> Stéphane and Matthew
>> 
>>  
>> 
>> [1] 
>> https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-per-mcast-flow-df-election/
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> _
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
>> falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or privileged 
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and 
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been 
>> modified, changed or falsified.
>> Thank you.
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG last call and IPR Poll for draft-ietf-bess-evpn-proxy-arp-nd-04

[Neeraj Malhotra]

Hi,

I support.

Thanks,
Neeraj

Sent from my iPhone

> On Aug 8, 2018, at 7:25 AM, Bocci, Matthew (Nokia - GB) 
>  wrote:
> 
> This email begins a two-week working group last call for 
> draft-ietf-bess-evpn-proxy-arp-nd-04.txt
> Please review the draft and post any comments to the BESS working group list.
> 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, copying the BESS mailing list. The document won't 
> progress without answers from all the authors and contributors.
>  
> Currently there is one IPR declaration against this document.
>  
> 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 implementations.
>  
> The working group last call closes on Wednesday 22nd August 2018. 
>  
> Regards,
> Matthew and Stéphane
>  
>  
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Slot requests for BESS WG session - IETF 102 - Montreal

[Neeraj Malhotra]

Hi Stephane,

I would like to request the following slots:

Draft: Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing,
draft-malhotra-bess-evpn-unequal-lb-02
Time: 10 mins
Reason to present: Significant additions to draft scope to include new DF
election procedures, WG adoption poll
Presenters: Neeraj Malhotra OR Ali Sajassi

Draft: Extended Mobility Procedures for EVPN-IRB,
draft-malhotra-bess-evpn-irb-extended-mobility-02
Time: 10 mins
Reason to present: WG adoption poll
Presenters: Neeraj Malhotra OR Ali Sajassi

Thanks,
Neeraj





On Tue, Jun 12, 2018 at 3:13 AM,  wrote:

> All,
>
>
>
> It is time we start building the BESS WG agenda for Montreal.
>
>
>
> Please send us your request for a presentation slot, indicating draft
> name, speaker, and desired duration (covering presentation and discussion).
> If it is not the first presentation of the draft, please give a reason why
> it is required to have a new presentation slot.
>
>
>
>
>
> Thank you
>
>
>
> Stephane & Matthew
>
>
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Slots requests for BESS WG session - IETF 99 - Prague

[Neeraj Malhotra (nmalhotr)]

Hi Martin,

Extended Mobility Procedures for EVPN-IRB 
(draft-malhotra-bess-evpn-irb-extended-mobility)
Speaker: Neeraj Malhotra
10 minutes

Thanks,
Neeraj

> On Jun 21, 2017, at 1:33 AM, Martin Vigoureux <martin.vigour...@nokia.com> 
> wrote:
> 
> All,
> 
> it is time we start building the BESS WG agenda for Prague.
> The IETF agenda (still preliminary) is available at:
> https://datatracker.ietf.org/meeting/99/agenda.html
> 
> The BESS WG session (2h) is scheduled on
> Thursday, July 20, 2017 / Afternoon session II / 15:50-17:50 (local time)
> 
> Please send us your request for a presentation slot, indicating
> draft name, speaker, and desired duration (covering presentation and
> discussion).
> 
> Please send the requests no later than the 5th of July.
> Thank you
> 
> M
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

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