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

[Satya Mohanty (satyamoh)]

I support the adoption of this draft to the WG.

Thanks,
Satya

From: BESS  on behalf of Jeffrey (Zhaohui) Zhang 

Date: Monday, November 13, 2023 at 3:51 AM
To: 'BESS' 
Cc: 'bess-cha...@ietf.org' , 
draft-sajassi-bess-evpn-ip-alias...@ietf.org 

Subject: [bess] WG Adoption and IPR poll for 
draft-sajassi-bess-evpn-ip-aliasing-09
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] Review of draft-ietf-bess-ebgp-dmz-03

[Satya Mohanty (satyamoh)]

Hi Sue,

Thanks for your comments. Yes, we are in discussion with other vendors 
regarding link-bandwidth and we will together put a document that will consider 
all the aspects that you have mentioned. Indeed, the transitive or 
non-transitive implementation across vendors poses a challenge to 
implementation.
Yes, we will refresh draft-ietf-idr-link-bandwidth possibly with new authors. 
That was also one of the points in our offline discussions.

Regarding your comment and alluding to entropy label, we will need further 
internal discussion.
BTW, (2) use-cases, it seems your last sentence is truncated. Maybe a typo.

Thanks,
--Satya

From: BESS  on behalf of Susan Hares 
Date: Thursday, July 27, 2023 at 4:36 PM
To: BESS 
Cc: Andrew Alston 
Subject: [bess] Review of draft-ietf-bess-ebgp-dmz-03
Bess chairs:

The IDR WG was queried for a review of this document.  No responses were made.
I wrote an IDR chair review is contained on the IDR section of the IETF 
community wiki:
https://wiki.ietf.org/en/group/idr/draft-ietf-bess-ebgp-dmz


Summary:
The IDR chairs note that authors are discussing non-transitive and transitive 
extended communities for link bandwidth passed by BGP extended communities. We 
suggest that these efforts continue.   In this process, I have offered 
additional things the IDR chairs will review in these documents.  It is time to 
ensure “link bandwidth” uses are harmonized across BGP mechanisms (attributes 
or extended communities) and bgp-ls reporting.

As the reviewing IDR chair, I find the publication this document at this time 
is premature.  However, it is a useful input to the process.

The IESG while reviewing draft-ietf-idr-entropy-label for publication should 
consider how extended communities, the router capability attributes, and BGP-LS 
reporting aligns for link, router, and AS bandwidth.

I believe that the chairs of the WGs related to BGP and BGP-LS in IGPs should 
discuss this topic (e.g. IDR, BESS, Spring, LSVR, Grow, MPLS)

Sue

Full text
draft-ietf-bess-ebgp-dmz-03 IDR Chair review
Reviewer: Susan Hares
Issues with this draft:
1. Protocol Content

Four drafts deal with link bandwidth for a BGP router passed in an extended 
communities attribute or the entropy attribute outside of BGP-LS reporting.
a) draft-ietf-idr-link-bandwidth (a non-transitive extended community attribute)
b) draft-ietf-bess-ebgp-dmz-03 (a transitive extended community)
c) draft-ietf-entropy-label (router capability attribute)



Work is underway by the authors to harmonize the transitive and non-transitive 
use of the community.
Section 6 of draft-ietf-bess-ebgp-dmz-03 indicates a need for a refresh of 
draft-ietf-idr-link-bandwidth.

The IDR chairs suggest this work continues before publishing the use case found 
in this draft.

As part of this work, the authors should consider:
a) whether the description is a link, router, or AS bandwidth.
b) the ramifications of passing this information as
extended community or an attribute, and
c) how this relates to the BGP-LS definitions.

2. Use cases

The draft presents the following use cases:
a) large-scale data centers (RFC7938, section 6.3) unequally weighted ECMP,
b) large-scale data centers (RFC79388) equally weighted ECMP,
c) external community and top-down Load-balanced community, and
d) no-conforming topologies.



The descriptions of these cases provide a helpful summary of these use cases. 
These descriptions help focus the discussions for protocol content.

Additional value can be gained for the current protocol discussions by 
indicating the answers to the questions on protocol content.

Whether this

3. English text



The English text has spelling errors, grammar errors, and portions that need to 
be clarified. At this stage, the content needs to be considered before a final 
check of the text.


Before requesting a review of the English text, the authors should use the 
commonly available tools (such as "Grammarly") to check the text.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02

[Satya Mohanty (satyamoh)]

Hi Alvaro and Robert,

Thanks to both for your review.
I am in agreement that  
https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07 needs to 
be refreshed.
Please see inline 


From: Idr  on behalf of Robert Raszuk 
Date: Thursday, June 22, 2023 at 11:58 AM
To: Alvaro Retana 
Cc: i...@ietf.org , bess@ietf.org , 
idr-cha...@ietf.org 
Subject: Re: [Idr] [bess] Request for IDR WG review of 
draft-ietf-bess-ebgp-dmz-02
Hi,

> I agree that the use case presented should be addressed, but I don't think 
> the document is ready for WGLC,

Indeed.

In fact it is clear by now that 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07 needs to 
be rewritten to accommodate both 4 octet ASNs (instead of proposing use of 
AS_TRANS) as well as define support for transitive community use.
  Yes, we should accommodate the 4-byte ASNs. Regarding the 
transitivity, please see below.

On the last one inspection of the IANA registry reveleas subtype 0x04 as 
"Juniper Transitive Link Bandwidth" and the date 25th April 2023.

[cid:ii_lj7i5vi70]

Interesting especially that I do not recall any discussions in IDR about this 
this year ...

 I also did not notice this, although as per earlier conversations with 
Juniper folks, I was aware that LB is implemented as transitive there.
On the other hand, Cisco, Arista etc. have implemented it as per the above 
draft i.e. optional non-transitive. Also, as per the draft, when the next-hop 
is reset, the received LB should be removed. This imposition, however, does 
allow regenerating a new LB that will be associated with the new advertised 
next-hop and that’s what is done in some of the implementations that I know of. 
Therefore, the transitivity requirement that you mention here really only 
applies to a case where the next-hop is unchanged when advertising the BGP 
update across the EBGP boundary.

Despite this divergence in already deployed implementations, in order that 
implementations work with each other, we will require some specified procedures 
with knobs etc. In fact, we have an offline thread initiated on this.

Cheers,
R.


On Thu, Jun 22, 2023 at 7:20 PM Alvaro Retana 
mailto:aretana.i...@gmail.com>> wrote:
Hi!

I took a look at this document.

I agree that the use case presented should be addressed, but I don't think the 
document is ready for WGLC, or even necessary (see below).  In fact, I'm having 
a hard time understanding how it can progress if it depends on an expired 
draft, the proposed changes are not specific, etc.


The meat of the document (beyond the explanation of the use case) is (from §1):

   The new use-case mandates that the router calculates the aggregated
   link-bandwidth, regenerate the DMZ link bandwidth extended community,
   and advertise it to EBGP peers.


I-D.ietf-idr-link-bandwidth expired in 2018.  I have seen no indication from 
the authors that it will be refreshed.  I know that implementations exist, but 
that is orthogonal to the need to reference this document as Normative.
 I think we should refresh the above. We had requested a refresh in 2018 
when draft-ietf-bess-ebgp-dmz was published. It was refreshed.


The rest of the document is mostly dedicated to describing the use case, but 
the description of the actions is loose (at best); for example, there is no 
specification about how "the router calculates the aggregated link-bandwidth".  
Yes, we can all guess/assume what it means, but that needs to be documented.
 Ack. We can put a text in the document, mentioning this.

Assuming that I-D.ietf-idr-link-bandwidth is revived, the use case from this 
document could be covered there.  In fact, there is already a hint to the 
ability to regenerate the community based on received information (from §3):

   Alternatively CEs of the site, when advertising IP routes to PE1
   and PE2, could add the link bandwith community to these
   advertisements, in which case PE1 and PE2, when originating VPN-IP
   routes, would use the bandwidth value from the IP routes they
   received from the CEs to construct the link bandwidth community
   carried by these VPN-IP routes.


In summary, given that this document depends on I-D.ietf-idr-link-bandwidth, I 
believe that the aggregate behavior can be "merged" into it.
 Yes, although regeneration is hinted, the distinguishing aspect is the 
aggregation in our draft. We can certainly merge both (need to discuss with 
other authors) and list it as a use-case just as you mentioned. But important 
thing now is to make the original draft active.


Alvaro.


Best,
--Satya

On May 25, 2023 at 5:43:55 AM, Matthew Bocci (Nokia) 
(matthew.bo...@nokia.com) wrote:
Hi IDR WG

The BESS chairs would like to request review of draft-ietf-bess-ebgp-dmz-02 
(draft-ietf-bess-ebgp-dmz-02 - Cumulative DMZ Link Bandwidth and 
load-balancing), 
for which we are considering starting a working group last 

Re: [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02

[Satya Mohanty (satyamoh)]

Hello all,

Gentle reminder for any review /comments as solicited by the BESS chairs.
This has already been deployed in networks for some time now and supported by 
many vendors.

Thanks,
--Satya

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Thursday, May 25, 2023 at 3:44 AM
To: i...@ietf.org 
Cc: bess@ietf.org , idr-cha...@ietf.org 
Subject: [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02
Hi IDR WG

The BESS chairs would like to request review of draft-ietf-bess-ebgp-dmz-02 
(draft-ietf-bess-ebgp-dmz-02 - Cumulative DMZ Link Bandwidth and 
load-balancing), 
for which we are considering starting a working group last call.

Please could you review the draft and post any comment to the BESS mailing list 
(bess@ietf.org) by 25th June 2023.

Thanks

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

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-secure-evpn-06

[Satya Mohanty (satyamoh)]

I have read the draft and support its adoption.

Thanks,
--Satya

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Thursday, May 25, 2023 at 3:36 AM
To: bess@ietf.org 
Cc: draft-sajassi-bess-secure-e...@ietf.org 
, bess-cha...@ietf.org 

Subject: [bess] WG Adoption and IPR poll for draft-sajassi-bess-secure-evpn-06
Hello,

This email begins a two-week WG adoption poll for 
draft-sajassi-bess-secure-evpn-06 [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 the authors and contributors.
Currently, there is currently no IPR disclosure 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 June 9th 2023

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/html/draft-sajassi-bess-secure-evpn

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

[bess] Request for WGLC for draft-ietf-bess-ebgp-dmz

[Satya Mohanty (satyamoh)]

Hi BESS community,

Draft https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/ has more than 
one implementation and deployed in the field.

Authors would like to request the chairs for WGLC.
Please let us know if there are any questions related to the draft.

Thanks,
--Satya

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

Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis

[Satya Mohanty (satyamoh)]

Thanks Jorge.

Gyan, indeed all the three algorithms have their use-cases.

As pointed out below in case of inconsistency (the “Alg type”) in the DF 
election extended community for a given ES, it was decided that the DF election 
must default to the modulo-based simply because modulo-based was proposed first 
and all existing deployments already had it, before the other two (Pref-based 
and HRW) came into existence. 
https://www.rfc-editor.org/rfc/rfc8584.html#section-2.2.1

Thanks,
--Satya

From: BESS  on behalf of Jorge Rabadan (Nokia) 

Date: Friday, March 3, 2023 at 11:06 PM
To: Gyan Mishra 
Cc: mdodge , bess@ietf.org 
Subject: Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis
Hi Gyan,

I agree with your two first statements, but I’m afraid I don’t agree with this 
one:
“I would think HRW would be the new default algorithm used for DF election and 
would not be a knob as it fixes the major deficiencies with the modulus 
algorithm.”

The modulo-based DF algorithm remains the default algorithm in case of 
inconsistency in the Ethernet Segment peers. It uses DF Alg 0, while HRW uses 
type 1 and Preference type 2. HRW is not obsoleting the modulo-based or 
anything like that. The three algorithms are widely used in networks, and while 
the default one has limitations, it is simple and works out in many networks.

Thank you!
Jorge


From: Gyan Mishra 
Date: Friday, March 3, 2023 at 11:50 PM
To: Jorge Rabadan (Nokia) 
Cc: Menachem Dodge , bess@ietf.org 
Subject: Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.



Hi Jorge

As defined in RFC 8584 AC-DF and HRW are independent of each other.

RFC 8584 updates RFC 7432, however RFC 7432 bis does not update any aspect of 
RFC 8584 including HRW as you stated.

I would think HRW would be the new default algorithm used for DF election and 
would not be a knob as it fixes the major deficiencies with the modulus 
algorithm.

Thanks

Gyan
On Fri, Feb 10, 2023 at 2:01 PM Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>> wrote:
Hi Menachem,

The way I see it, draft-ietf-bess-rfc7432bis will obsolete RFC7432, but it does 
not update or change RFC8584, so I don’t think draft-ietf-bess-rfc7432bis needs 
to repeat the aspects of RFC8584.

In particular, the AC-DF, as the other capabilities defined in other documents, 
is a capability that can be turned on or off. While it is very useful in many 
cases, it actually needs to be disabled in some others, e.g., 
draft-ietf-bess-evpn-mh-pa-07

So the answer to your second question could be that the AC-DF capability should 
be configurable in the implementation, and used on all cases where issues with 
individual Attachment Circuits may create blackholes. However, it has to be 
disabled in case of port-active multi-homing.

My 2 cents..

Thanks.
Jorge


From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Menachem Dodge mailto:mdo...@drivenets.com>>
Date: Friday, February 10, 2023 at 8:10 AM
To: bess@ietf.org mailto:bess@ietf.org>>
Subject: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis
Some people who received this message don't often get email from 
mdo...@drivenets.com. Learn why this is 
important
Hello All,

In section 8.5 of draft-ietf-bess-rfc7432bis there is a reference to the Finite 
State Machine in section 2.1 of RFC 8584.

However, in section 4 of RFC 8584 the AC Influenced DF Election Capability is 
described and it states that this updates Step 3 of the procedure for service 
carving of RFC 7432.

Shouldn’t this AC-DF update be mentioned in the procedures of section 8.5 of 
draft-ietf-bess-rfc7432bis?

Is AC Influenced DF Election the preferred DF election method ?


According to RFC 8584 “ The procedure discussed in this section is applicable 
to the DF

   election in EVPN services 
[RFC7432] and EVPN VPWS 
[RFC8214]. “



Thank you kindly.

Best Regards,

Menachem Dodge
System Architect
[signature_3305758272]
+972-526175734
mdo...@drivenets.com
follow us on Linkedin
www.drivenets.com
[DriveNets Network Cloud]

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

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

___
BESS mailing list

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

[Satya Mohanty (satyamoh)]

Sorry, I am delayed on this.

Few minutes back I resubmitted this draft as “draft-ietf-bess-ebgp-dmz” to 
replace “draft-mohanty-bess-ebgp-dmz” as instructed by Matthew below.
Now it shows submission is pending approval by group chairs.

Thanks,
Satya


From: Arie Vayner 
Date: Wednesday, February 23, 2022 at 1:54 PM
To: Satya Mohanty (satyamoh) 
Cc: Bocci, Matthew (Nokia - GB) , Ajay Kini 
, Akshay Gattani , bess@ietf.org 
, Lukas Krattiger (lkrattig) , 
draft-mohanty-bess-ebgp-...@ietf.org 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].
Pinging the thread as it's been quiet since Dec '21.

Tnx
Arie

On Thu, Dec 9, 2021 at 1:10 PM Satya Mohanty (satyamoh) 
mailto:satya...@cisco.com>> wrote:
Hi Matthew,

Thanks for your comments.
We will republish this draft as draft-ietf-bess-ebgp-dmz-00 shortly.

Best Regards,
--Satya

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Date: Thursday, December 9, 2021 at 5:36 AM
To: Ajay Kini mailto:ajk...@arista.com>>
Cc: Akshay Gattani mailto:aks...@arista.com>>, 
bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
Lukas Krattiger (lkrattig) mailto:lkrat...@cisco.com>>, 
draft-mohanty-bess-ebgp-...@ietf.org<mailto:draft-mohanty-bess-ebgp-...@ietf.org>
 
mailto:draft-mohanty-bess-ebgp-...@ietf.org>>
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].
Thanks Ajay

There is consensus to adopt this draft as a BESS WG draft.

Authors: Please republish the draft as draft-ietf-bess-ebgp-dmz-00.

Best regards

Matthew

From: Ajay Kini mailto:ajk...@arista.com>>
Date: Thursday, 9 December 2021 at 13:21
To: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Cc: Akshay Gattani mailto:aks...@arista.com>>, Lukas 
Krattiger (lkrattig) mailto:lkrat...@cisco.com>>, 
bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-mohanty-bess-ebgp-...@ietf.org<mailto:draft-mohanty-bess-ebgp-...@ietf.org>
 
mailto:draft-mohanty-bess-ebgp-...@ietf.org>>
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].
Hi Matthew,

I am not aware of any relevant undisclosed IPRs that apply to this draft.

Thanks
Ajay
On Thu, Dec 9, 2021, 4:55 AM Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:
Ashkay,

Thank you for your response.

Strictly, I need a response from each individual author, otherwise I will have 
to ask the WG if they are happy to proceed.

Ajay, please can you confirm whether or not you are aware of any undisclosed 
IPR?

Thanks

Matthew

From: Akshay Gattani mailto:aks...@arista.com>>
Date: Friday, 3 December 2021 at 08:10
To: Ajay Kini mailto:ajk...@arista.com>>
Cc: Lukas Krattiger (lkrattig) mailto:lkrat...@cisco.com>>, 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>, 
bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-mohanty-bess-ebgp-...@ietf.org<mailto:draft-mohanty-bess-ebgp-...@ietf.org>
 
mailto:draft-mohanty-bess-ebgp-...@ietf.org>>
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].
To our knowledge, the authors from Arista are not aware of any relevant 
undisclosed IPRs that apply to this draft document.

Thank you

On Wed, Sep 22, 2021 at 3:04 AM Ajay Kini 
mailto:ajk...@arista.com>> wrote:
I support adoption of this draft as a co-author.

On Tue, Sep 21, 2021 at 2:10 PM Akshay Gattani 
mailto:aks...@arista.com>> wrote:
I fully support adoption of this draft as a co-author.

On Mon, Sep 20, 2021 at 8:27 PM Lukas Krattiger (lkrattig) 
mailto:lkrat...@cisco.com>> wrote:
Good Day,
I fully support the adoption of this draft
Kind Regards
-Lukas

On Sep 7, 2021, at 5:41 AM, Bocci, Matthew (Nokia - GB) 
mailto: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 Sept

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

[Satya Mohanty (satyamoh)]

Hi Matthew,

Thanks for your comments.
We will republish this draft as draft-ietf-bess-ebgp-dmz-00 shortly.

Best Regards,
--Satya

From: BESS  on behalf of Bocci, Matthew (Nokia - GB) 

Date: Thursday, December 9, 2021 at 5:36 AM
To: Ajay Kini 
Cc: Akshay Gattani , bess@ietf.org , Lukas 
Krattiger (lkrattig) , draft-mohanty-bess-ebgp-...@ietf.org 

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

There is consensus to adopt this draft as a BESS WG draft.

Authors: Please republish the draft as draft-ietf-bess-ebgp-dmz-00.

Best regards

Matthew

From: Ajay Kini 
Date: Thursday, 9 December 2021 at 13:21
To: Bocci, Matthew (Nokia - GB) 
Cc: Akshay Gattani , Lukas Krattiger (lkrattig) 
, bess@ietf.org , 
draft-mohanty-bess-ebgp-...@ietf.org 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].
Hi Matthew,

I am not aware of any relevant undisclosed IPRs that apply to this draft.

Thanks
Ajay
On Thu, Dec 9, 2021, 4:55 AM Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:
Ashkay,

Thank you for your response.

Strictly, I need a response from each individual author, otherwise I will have 
to ask the WG if they are happy to proceed.

Ajay, please can you confirm whether or not you are aware of any undisclosed 
IPR?

Thanks

Matthew

From: Akshay Gattani mailto:aks...@arista.com>>
Date: Friday, 3 December 2021 at 08:10
To: Ajay Kini mailto:ajk...@arista.com>>
Cc: Lukas Krattiger (lkrattig) mailto:lkrat...@cisco.com>>, 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
draft-mohanty-bess-ebgp-...@ietf.org
 
mailto:draft-mohanty-bess-ebgp-...@ietf.org>>
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].
To our knowledge, the authors from Arista are not aware of any relevant 
undisclosed IPRs that apply to this draft document.

Thank you

On Wed, Sep 22, 2021 at 3:04 AM Ajay Kini 
mailto:ajk...@arista.com>> wrote:
I support adoption of this draft as a co-author.

On Tue, Sep 21, 2021 at 2:10 PM Akshay Gattani 
mailto:aks...@arista.com>> wrote:
I fully support adoption of this draft as a co-author.

On Mon, Sep 20, 2021 at 8:27 PM Lukas Krattiger (lkrattig) 
mailto:lkrat...@cisco.com>> wrote:
Good Day,
I fully support the adoption of this draft
Kind Regards
-Lukas

On Sep 7, 2021, at 5:41 AM, Bocci, Matthew (Nokia - GB) 
mailto: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] WG adoption poll and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].

[Satya Mohanty (satyamoh)]

Hi Matthew,

I should have mentioned before.
I am not aware of any IPR on this work.

Best Regards,
--Satya

From: BESS  on behalf of "Satya Mohanty (satyamoh)" 

Date: Thursday, September 9, 2021 at 11:04 AM
To: "Bocci, Matthew (Nokia - GB)" , "bess@ietf.org" 

Cc: "draft-mohanty-bess-ebgp-...@ietf.org" 

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

I support WG adoption as co-author.

Best Regards,
--Satya

From: "Bocci, Matthew (Nokia - GB)" 
Date: Tuesday, September 7, 2021 at 5:42 AM
To: "bess@ietf.org" 
Cc: "draft-mohanty-bess-ebgp-...@ietf.org" 

Subject: WG adoption poll and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].
Resent-From: 
Resent-To: , , , 

Resent-Date: Tuesday, September 7, 2021 at 5:42 AM

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

Re: [bess] Last Call: (Updates on EVPN BUM Procedures) to Proposed Standard

[Satya Mohanty (satyamoh)]

Hi Jeffrey,

Thanks for your reply.
It makes perfect sense.

Am I to assume that the same reasoning applies to Inter-as MVPN as well since 
EVPN BUM procedures is based significantly on MVPN procedures?

Best Regards,
--Satya

From: "Jeffrey (Zhaohui) Zhang" 
Date: Tuesday, September 14, 2021 at 12:31 PM
To: "Satya Mohanty (satyamoh)" , "last-c...@ietf.org" 
, IETF-Announce 
Cc: "ext-zzhang_i...@hotmail.com" , 
"martin.vigour...@nokia.com" , 
"bess-cha...@ietf.org" , 
"draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org" 
, "bess@ietf.org" 

Subject: RE: [bess] Last Call: 
 (Updates on EVPN BUM 
Procedures) to Proposed Standard

Hi Satya,

That is part of the optional procedure to provide backwards compatibility. An 
implementation would likely to have configuration controlling whether this 
procedure is used or not.

For the origination of per-region I-PMSI routes, whether it is for the purpose 
of backwards compatibility or just for the aggregation purpose, some 
provisioning is needed – at least to enable per-region aggregation (perhaps at 
per-VPN level). We are adding per-VPN signaling and procedures, so per-VRF 
configuration should be reasonable (at least on the source ASBRs).

In summary, that is indeed a local implementation issue.

Thanks!
Jeffrey

From: Satya Mohanty (satyamoh) 
Sent: Friday, September 10, 2021 2:10 PM
To: last-c...@ietf.org; IETF-Announce 
Cc: ext-zzhang_i...@hotmail.com ; 
martin.vigour...@nokia.com; bess-cha...@ietf.org; 
draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org; bess@ietf.org
Subject: Re: [bess] Last Call: 
 (Updates on EVPN BUM 
Procedures) to Proposed Standard

[External Email. Be cautious of content]


Hi authors,



One question on the draft Page #11, last paragraph;



   "  The ASBRs in an AS originate per-region I-PMSI A-D routes and

  advertise to their external peers to advertise tunnels used to

  carry traffic from the local AS to other ASes.  Depending on the

  types of tunnels being used, the L flag in the PTA may be set, in

  which case the downstream ASBRs and upgraded PEs will send Leaf

  A-D routes to pull traffic from their upstream ASBRs."



How do we originate these per-region I-PMSI?

Is it implied that there are EVI configuration at the ASBR?

Or this is a local decision and is not to be discussed in the standard.



In L23VPN, usually ASBRs do not have VRFs configured. Therefore asking this 
question.



Thanks,

--Satya



On 8/24/21, 7:38 AM, "BESS on behalf of The IESG" mailto:bess-boun...@ietf.org%20on%20behalf%20of%20iesg-secret...@ietf.org>>
 wrote:





The IESG has received a request from the BGP Enabled ServiceS WG (bess) to

consider the following document: - 'Updates on EVPN BUM Procedures'

   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

last-c...@ietf.org<mailto:last-c...@ietf.org> mailing lists by 2021-09-07. 
Exceptionally, comments may

be sent to i...@ietf.org<mailto:i...@ietf.org> instead. In either case, 
please retain the beginning

of the Subject line to allow automated sorting.



Abstract





   This document specifies procedure updates for broadcast, unknown

   unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),

   including selective multicast, and provider tunnel segmentation.

   This document updates RFC 7432.











The file can be obtained via

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/







No IPR declarations have been submitted directly on this I-D.











___

BESS mailing list

BESS@ietf.org<mailto:BESS@ietf.org>

https://www.ietf.org/mailman/listinfo/bess


Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Last Call: (Updates on EVPN BUM Procedures) to Proposed Standard

[Satya Mohanty (satyamoh)]

Hi authors,



One question on the draft Page #11, last paragraph;



   "  The ASBRs in an AS originate per-region I-PMSI A-D routes and

  advertise to their external peers to advertise tunnels used to

  carry traffic from the local AS to other ASes.  Depending on the

  types of tunnels being used, the L flag in the PTA may be set, in

  which case the downstream ASBRs and upgraded PEs will send Leaf

  A-D routes to pull traffic from their upstream ASBRs."



How do we originate these per-region I-PMSI?

Is it implied that there are EVI configuration at the ASBR?

Or this is a local decision and is not to be discussed in the standard.



In L23VPN, usually ASBRs do not have VRFs configured. Therefore asking this 
question.



Thanks,

--Satya



On 8/24/21, 7:38 AM, "BESS on behalf of The IESG"  wrote:





The IESG has received a request from the BGP Enabled ServiceS WG (bess) to

consider the following document: - 'Updates on EVPN BUM Procedures'

   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

last-c...@ietf.org mailing lists by 2021-09-07. 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





   This document specifies procedure updates for broadcast, unknown

   unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),

   including selective multicast, and provider tunnel segmentation.

   This document updates RFC 7432.











The file can be obtained via

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/







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 and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].

[Satya Mohanty (satyamoh)]

I support WG adoption as co-author.

Best Regards,
--Satya

From: "Bocci, Matthew (Nokia - GB)" 
Date: Tuesday, September 7, 2021 at 5:42 AM
To: "bess@ietf.org" 
Cc: "draft-mohanty-bess-ebgp-...@ietf.org" 

Subject: WG adoption poll and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].
Resent-From: 
Resent-To: , , , 

Resent-Date: Tuesday, September 7, 2021 at 5:42 AM

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

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Satya Mohanty (satyamoh)]

Gyan,

Thanks for your interest. Sorry for replying late on this.
Thanks Arie and Jeff for your clarifications.

We have not changed the definition of the Link Bandwidth Ext. Community 
(0x4004) or it definition as non-transitive.
As Arie mentioned previously, we are actually originating it at the AS boundary.

BTW, the cumulative link-bandwidth feature first went in XR in 6.1.1. We can 
incorporate that in the addendum as well get the similar information from other 
vendors.

Thanks,
--Satya

From: Gyan Mishra 
Date: Saturday, July 3, 2021 at 8:34 AM
To: Jeff Tantsura 
Cc: Arie Vayner , Robert Raszuk , "Satya 
Mohanty (satyamoh)" , "UTTARO, JAMES" , 
"bess@ietf.org" 
Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft


Thanks Jeff for the clarification.

Thanks

Gyan
On Fri, Jul 2, 2021 at 6:05 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Gyan,

you are mixing use of BW community as such with cumulative propagation (the 
theme of the draft).
The original community is defined in "Non-Transitive Two-Octet AS-Specific 
Extended Community Sub-Types" IANA section and that has to be changed to allow 
eBGP use cases.
Aggregation is a very useful feature when the prefix with the community 
attached is traversing the fabric and is being regenerated and potentially 
transformed at every hop traversed.

The alternative with add-path and potentially path explosion (not to talk about 
operational complexity of add-path and bugs in the implementations) is a rather 
unattractive solution for DC fabrics.

Cheers,
Jeff

On Fri, Jul 2, 2021 at 12:17 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:
Hi Satya

For EBGP DCs with multi-stage clos I understand this can be used, however with 
Cisco & Juniper & Nokia & Arista  and maybe other vendor implementations seem 
to combine the non transitive link bw extended community and transitive 
cumulative link bw extended community into a single feature that works for UCMP 
intra AS and inter AS.  Please confirm.

These two drafts seem to be combined by implementations into a single UCMP 
feature for both eBGP and iBGP.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03

Cisco:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-link-bandwidth.html

https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-unequal-cost-multipath-ucmp-dmz-link/ta-p/3138853

Juniper:

https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-multipath-unequal-understanding.html

Nokia:

https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/bgp.html


Arista:

https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp#xx1418621

Kind Regards

Gyan

On Wed, May 26, 2021 at 3:21 PM Satya Mohanty (satyamoh) 
mailto:satya...@cisco.com>> wrote:
Hi Jim,

No, they do not.

This draft under discussion is a way to aggregate the link bandwidth in EBGP 
DCs and advertise it upstream.
It works well in multi-stage clos topology fabrics.
Traffic is demultiplexed (multi-path load balanced) when it arrives at a node 
of each stage (unless the sink).

The draft you are mentioning, 
https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is really a 
way to communicate the link-bandwidth across EBGP boundaries.
It is mostly geared from an Inter-AS Option C viewpoint (next-hop unchanged) 
although it also applies to Option B deployments (next-hop-self).
There is no notion of aggregating bandwidth here.

HTH.

Best Regards,
--Satya


From: "UTTARO, JAMES" mailto:ju1...@att.com>>
Date: Wednesday, May 26, 2021 at 5:38 AM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>, Robert 
Raszuk mailto:rob...@raszuk.net>>
Cc: Jeff Tantsura mailto:jefftant.i...@gmail.com>>, 
Arie Vayner mailto:ar...@vayner.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, 
"Satya Mohanty (satyamoh)" mailto:satya...@cisco.com>>
Subject: RE: [bess] Request discussion on Cumulative Link Bandwidth Draft

Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing address 
the same field of use?

Thanks,
  Jim Uttaro

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Gyan Mishra
Sent: Wednesday, May 26, 2021 12:57 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Arie Vayner mailto:ar...@vayner.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; Satya Mohanty (satyamoh) 
mailto:40cisco@dmarc.ietf.org>>
Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

Across the DC space in general most providers use NVO3 and vxlan source port 
entropy L2/L3/L4 hash which provides per packet unif

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Satya Mohanty (satyamoh)]

Hi Jim,

No, they do not.

This draft under discussion is a way to aggregate the link bandwidth in EBGP 
DCs and advertise it upstream.
It works well in multi-stage clos topology fabrics.
Traffic is demultiplexed (multi-path load balanced) when it arrives at a node 
of each stage (unless the sink).

The draft you are mentioning, 
https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is really a 
way to communicate the link-bandwidth across EBGP boundaries.
It is mostly geared from an Inter-AS Option C viewpoint (next-hop unchanged) 
although it also applies to Option B deployments (next-hop-self).
There is no notion of aggregating bandwidth here.

HTH.

Best Regards,
--Satya


From: "UTTARO, JAMES" 
Date: Wednesday, May 26, 2021 at 5:38 AM
To: Gyan Mishra , Robert Raszuk 
Cc: Jeff Tantsura , Arie Vayner , 
"bess@ietf.org" , "Satya Mohanty (satyamoh)" 
Subject: RE: [bess] Request discussion on Cumulative Link Bandwidth Draft

Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing address 
the same field of use?

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Gyan Mishra
Sent: Wednesday, May 26, 2021 12:57 AM
To: Robert Raszuk 
Cc: Jeff Tantsura ; Arie Vayner ; 
bess@ietf.org; Satya Mohanty (satyamoh) 
Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

Across the DC space in general most providers use NVO3 and vxlan source port 
entropy L2/L3/L4 hash which provides per packet uniform 50/50 load balancing at 
the L2 VNI overlay layer, which translates into underlay load balancing of 
flows and thus no polarization.

Across the DC space speaking from an operators perspective as under the floor 
fiber is not at a premium compare to 100G facilities costs the net addition of 
bandwidth can be done fairly quickly so you are ahead of the congestion curve 
and can be proactive versus reactively upgrading bandwidth piecemeal here and 
there ad hoc.

There still maybe cases that still arise as even if you have the fiber 
infrastructure available, it’s not easy to upgrade and flash every link 
simultaneously in the DC in one or multiple maintenance windows, so you could 
still be left with some uneven bandwidth across the DC that could utilize this 
feature.

DC comes into play for PE-CE “wan links”as well  use case for unequal cost load 
balancing use of the cumulative link bandwidth community regenerated.


I think the use case where both the iBGP P core P-P links  or eBGP PE - PE 
inter-as are all wan links where link upgrades tend to not get done in unison 
uniformly, and in those cases both iBGP link bandwidth community can be heavily 
utilized as well as eBGP cumulative regenerated link bandwidth community for 
unequal cost  load balancing.  Across the core as well it is hard to flash all 
links even under floor fiber to the same bandwidth all at once you are left 
with the requirement for unequal coat load balancing.

As operators upgrade their DC as well as core infrastructure to IPv6 forwarding 
plane in the move towards SRv6, they can now take advantage of flow label 
entropy stateless uniform load balancing and elimination of polarization.  
However, the wan link upgrades of core and DC PE-CE still exists and thus may 
be done piecemeal, so then both of the drafts are an extremely helpful tool for 
operators that much need the unequal cost load balancing capability.

I support both drafts.

Have most vendors implemented this to support both 2 byte and 4 byte AS 
extended community.  The drafts state 2 byte AS support.

Thanks

Gyan

On Tue, May 25, 2021 at 7:00 PM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Arie,

Draft  draft-ietf-idr-link-bandwidth talks about advertising towards IBGP. It 
does not talk about advertising over EBGP.

While I do support your use case I think it would be much cleaner to just ask 
for new ext. community type.

Reason being that as you illustrate you may want to accumulate BGP path's bw 
across few EBGP hops in the DC. Today there is no way to do so unless you want 
to completely hijack current lb ext community.

Also I see an analogy here to AIGP RFC although it clearly fits rather poorly 
for those who use BGP as IGP :).

Best, R.

On Wed, May 26, 2021 at 12:22 AM Arie Vayner 
mailto:ar...@vayner.net>> wrote:
Jeff,

Actually, the way this draft is written, and how the implementations I'm aware 
of are implemented, this is not really a transitive community. It is a new 
community that is being generated on the AS boundary.
The community value is not carried over, but is calculated based on an 
cumulative value of other received communities, and then advertised as a new 
value across the AS boundary.

Tnx,
Arie

On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Hi,

I support adoption of the draft as Informational, please note, that request to 
change transitivity characteristics of the community is requested in anothe

[bess] Request discussion on Cumulative Link Bandwidth Draft

[Satya Mohanty (satyamoh)]

Hi all,

On behalf of all the authors, we request a discussion of the draft 
https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03  and 
subsequent WG adoption.
This draft extends the usage of the DMZ link bandwidth to scenarios where the 
cumulative link bandwidth needs to be advertised to a BGP speaker.
Additionally, there is provision to send the link bandwidth extended community 
to EBGP speakers via configurable knobs. Please refer to section 3 and 4 for 
the use cases.

This feature has multiple-vendor implementations and has been deployed by 
several customers in their networks.

Best Regards,
--Satya
___
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

[Satya Mohanty (satyamoh)]

Support.

Thanks,
Satya

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, April 19, 2021 at 11:07 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG and IPR poll adoption poll for 
draft-krattiger-evpn-modes-interop

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

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

[Satya Mohanty (satyamoh)]

Thanks Matthew.
We will do the needful and resubmit.

Best Regards,
--Satya

From: "Bocci, Matthew (Nokia - GB)" 
Date: Thursday, March 11, 2021 at 1:53 AM
To: "bess@ietf.org" 
Cc: "draft-mohanty-bess-weighted-...@ietf.org" 

Subject: Re: WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01
Resent-From: 
Resent-To: , , , 
, "jdr...@juniper.net" 
Resent-Date: Thursday, March 11, 2021 at 1:52 AM

Hi WG

I now have sufficient responses, incl. IPR responses, to close this poll for 
adoption.

There is consensus to adopt the draft as a BESS WG document.

Authors: Please can you resubmit the document as 
draft-ietf-bess-weighted-hrw-00.

Thanks

Matthew

From: Bocci, Matthew (Nokia - GB) 
Date: Wednesday, 9 December 2020 at 09:22
To: bess@ietf.org 
Cc: draft-mohanty-bess-weighted-...@ietf.org 

Subject: 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

Re: [bess] RFC 8584: EVPN DF Election - Originating Router's IP Address of different address family

[Satya Mohanty (satyamoh)]

Hi Jorge,

Inline.

From: BESS  on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" 
Date: Friday, February 5, 2021 at 6:05 AM
To: TULASI RAM REDDY , Muthu Arul Mozhi Perumal 

Cc: "bess@ietf.org" 
Subject: Re: [bess] RFC 8584: EVPN DF Election - Originating Router's IP 
Address of different address family

Hi Tulasi,

For the default DF algorithm, I think at that point it will be up to the 
implementation how to resolve the candidate list PEs with originating IPs of 
different family.
 This is should be standardized as otherwise It will result in different 
decisions in different PEs. I suggest a mention in 7432-bis.
I know of some implementations that do what you are saying, but you can’t 
assume all RFC7432/8584 implementations will do that.

Thanks.
Jorge

Thanks,
Satya

From: BESS  on behalf of TULASI RAM REDDY 

Date: Friday, February 5, 2021 at 2:15 PM
To: Muthu Arul Mozhi Perumal 
Cc: bess@ietf.org 
Subject: Re: [bess] RFC 8584: EVPN DF Election - Originating Router's IP 
Address of different address family
Thanks Muthu.
Shouldn't numeric value here mean simply the 4byte or 16 byte unsigned value 
representation of the IP address field?
Thinking loudly on how to interpret numeric value  and the limitations here. 
Any comments?


each PE builds an ordered list of the IP

addresses of all the PE nodes connected to the Ethernet segment

(including itself), in increasing numeric value

Thanks,
Tulasi.
On Fri, Feb 5, 2021 at 3:15 PM Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>> wrote:
Hi Tulasi,

I think the problem is, there is no standard way to numerically compare IPv4 
with IPv6 addresses to form an ordered list. So, all the PEs multihomed to an 
ES may not always arrive at the same DF (or BFD in the case of single-active 
L-LINE service) with the default DF election algo. This is problematic (and may 
cause traffic loops). Hence, the default DF election algo works only when all 
PEs multihomed to an ES have Originating Router's IP Address of the same AF..

Regards,
Muthu

On Thu, Feb 4, 2021 at 7:58 PM TULASI RAM REDDY 
mailto:tulasiramire...@gmail.com>> wrote:
Hi All,

As mentioned in the Problem Statement of RFC8584 Sec 1.3, Default DF algorithm 
is expected to have
all multihomed PEs to have Originating IP of the same address family.
Do we see any interop issue if the different address families are considered, 
i.e. ordering in
ascending order based on numerical value in Originating IP here? For IPv4 read 
4 octets as unsigned integer
and IPv6 is considered as 16 octet unsigned integer.

1.3.  Problem Statement

Default DF election algorithm assumes

that all the PEs who are multihomed to the same ES (and interested in

the DF election by exchanging EVPN routes) use an Originating

Router's IP address [RFC7432] of the same 
family.

Thanks,
TULASI RAMI REDDY N
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


--
TULASI RAMI REDDY N
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] RFC 8584: EVPN DF Election - Originating Router's IP Address of different address family

[Satya Mohanty (satyamoh)]

Hi Tulasi and Muthu,

Yes, the numeric value here refers to the 4byte or 16byte unsigned value 
representation of the IP address field.
Maybe in the 7432-bis this can be stated explicitly.

We did envision this possibility in RFC 8584 (the HRW hash already takes care 
of the fact that the IP address could be either IPV4 or IPV6).

However, with respect to deployment do you have a case in mind of this “mixed 
v4/v6” that will necessitate such a tie-break?
I mean one of the MH PEs has an ipv4 originator address and the other a v6 
originator address.

Thanks,
--Satya


From: BESS  on behalf of TULASI RAM REDDY 

Date: Friday, February 5, 2021 at 5:17 AM
To: Muthu Arul Mozhi Perumal 
Cc: "bess@ietf.org" 
Subject: Re: [bess] RFC 8584: EVPN DF Election - Originating Router's IP 
Address of different address family

Thanks Muthu.
Shouldn't numeric value here mean simply the 4byte or 16 byte unsigned value 
representation of the IP address field?
Thinking loudly on how to interpret numeric value  and the limitations here. 
Any comments?


each PE builds an ordered list of the IP

addresses of all the PE nodes connected to the Ethernet segment

(including itself), in increasing numeric value

Thanks,
Tulasi.
On Fri, Feb 5, 2021 at 3:15 PM Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>> wrote:
Hi Tulasi,

I think the problem is, there is no standard way to numerically compare IPv4 
with IPv6 addresses to form an ordered list. So, all the PEs multihomed to an 
ES may not always arrive at the same DF (or BFD in the case of single-active 
L-LINE service) with the default DF election algo. This is problematic (and may 
cause traffic loops). Hence, the default DF election algo works only when all 
PEs multihomed to an ES have Originating Router's IP Address of the same AF..

Regards,
Muthu

On Thu, Feb 4, 2021 at 7:58 PM TULASI RAM REDDY 
mailto:tulasiramire...@gmail.com>> wrote:
Hi All,

As mentioned in the Problem Statement of RFC8584 Sec 1.3, Default DF algorithm 
is expected to have
all multihomed PEs to have Originating IP of the same address family.
Do we see any interop issue if the different address families are considered, 
i.e. ordering in
ascending order based on numerical value in Originating IP here? For IPv4 read 
4 octets as unsigned integer
and IPv6 is considered as 16 octet unsigned integer.

1.3.  Problem Statement

Default DF election algorithm assumes

that all the PEs who are multihomed to the same ES (and interested in

the DF election by exchanging EVPN routes) use an Originating

Router's IP address [RFC7432] of the same 
family.

Thanks,
TULASI RAMI REDDY N
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


--
TULASI RAMI REDDY N
___
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

[Satya Mohanty (satyamoh)]

Support.

Thanks,
--Satya

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, January 18, 2021 at 12: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 adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01

[Satya Mohanty (satyamoh)]

Support as co-author and not aware of any undisclosed IPR.

Thanks,
--Satya

From: "Bocci, Matthew (Nokia - GB)" 
Date: Wednesday, December 9, 2020 at 1:23 AM
To: "bess@ietf.org" 
Cc: "draft-mohanty-bess-weighted-...@ietf.org" 

Subject: WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01
Resent-From: 
Resent-To: , , , 
, "jdr...@juniper.net" 
Resent-Date: Wednesday, December 9, 2020 at 1:22 AM

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

Re: [bess] Second try: Router's MAC Extended Community in draft-ietf-bess-evpn-inter-subnet-forwarding

[Satya Mohanty (satyamoh)]

Hi John,

My bad. I thought “shall” is synonymous with “should” rather than “must” until 
you pointed it out.
Considering the above,  is it appropriate to say here that “No more than one 
router mac extended communities should be attached to a route” ?

Thanks,
--Satya

From: "John G. Scudder" 
Date: Saturday, October 10, 2020 at 7:16 PM
To: "Satya Mohanty (satyamoh)" 
Cc: "Ali Sajassi (sajassi)" , 
"draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, BESS 
Subject: Re: [bess] Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding

Hi Satya,

I don’t follow your point about SHALL vs. MUST. The two are defined by RFC 2119 
to be synonyms.

—John


On Oct 10, 2020, at 8:32 PM, Satya Mohanty (satyamoh)  
wrote:
Hi Ali and John,

In the DMZ Link bandwidth draft  
https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-07<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-idr-link-bandwidth-07__;!!NEt6yMaO-gk!Vxr2nCjAMuJKkJ-a-H-vPXJzThAn7BdOtDcw4bvFCnWbkyd5721Jrr5so69MkA$>
  sec. 2, we have the following sentence.
“No more than one link bandwidth extended community SHALL be attached to a 
route.”

Can we add similar wording in here as similar logic applies?
It is still a “SHALL” rather than “must”, so even if the speaker receives 
multiple router-macs, the way you describe below will work.

Thanks,
--Satya

From: BESS  on behalf of "Ali Sajassi (sajassi)" 

Date: Thursday, October 8, 2020 at 12:15 PM
To: "John G. Scudder" 
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, BESS 
Subject: Re: [bess] Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding


Hi John,

Thanks for your feedback. I was also thinking along the line of (2). I’ll take 
care of it in the next rev. soon.

Cheers,
Ali


From: John Scudder 
Date: Thursday, October 8, 2020 at 11:57 AM
To: Cisco Employee 
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, BESS 
Subject: Re: Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Resent-From: 
Resent-To: Cisco Employee , , 
, , 
Resent-Date: Thursday, October 8, 2020 at 11:57 AM

Thanks, Ali.

Yes, I think this should be explicit in the spec. I’d also suggest being 
explicit about what “ignore the rest” means. It could mean one of two things —

1. Don’t pay attention to the extra ones for purposes of computing the local 
forwarding table, but store them and propagate them.
2. Also don’t store or propagate them.

I’m guessing option 2 is better in this case. The problem with propagating them 
is sometimes implementations reorder things, so you could end up with 
inconsistency in the network.

—John




On Oct 8, 2020, at 2:42 PM, Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>> wrote:



Hi John,

Sorry for the delay.

The answer to your 1st question is no and the answer to your 2nd question is 
that the receiver should pick the first one in the list and ignore the rest. If 
it helps, I can add couple of lines to that affect to the corresponding section.

Cheers,
Ali

From: John Scudder mailto:j...@juniper.net>>
Date: Thursday, October 8, 2020 at 11:12 AM
To: 
"draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org<mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>"
 
mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>>
Cc: BESS mailto:bess@ietf.org>>
Subject: Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Cisco Employee mailto:saja...@cisco.com>>, 
mailto:ssa...@cisco.com>>, 
mailto:stho...@cisco.com>>, 
mailto:jdr...@juniper.net>>, 
mailto:jorge.raba...@nokia.com>>
Resent-Date: Thursday, October 8, 2020 at 11:12 AM

Hi Authors,

I haven’t seen a reply to this message from almost a month ago, trying again. 
Even if you are still debating the answer amongst yourselves, it would be 
comforting to me to receive a reply to the effect of “we’re still thinking 
about this and will get back to you by $date”.

Thanks,

—John





Begin forwarded message:

From: "John G. Scudder" mailto:j...@juniper.net>>
Subject: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Date: September 10, 2020 at 9:27:31 AM EDT
To: 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org<mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>
Cc: BESS mailto:bess@ietf.org>>

Hi Authors,

I just went through draft-ietf-bess-evpn-inter-subnet-forwarding to look for 
answers to two questions:

1. Can a router advertise multiple different Router’s MAC values? If yes, what 
is the receiver supposed to do?
2. Assuming the answer to question 1 is “no”, what is the receiver supposed to 
do if it receives multiple Router’s MAC 

Re: [bess] Second try: Router's MAC Extended Community in draft-ietf-bess-evpn-inter-subnet-forwarding

[Satya Mohanty (satyamoh)]

Hi Ali and John,

In the DMZ Link bandwidth draft  
https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-07  sec. 2, we have 
the following sentence.
“No more than one link bandwidth extended community SHALL be attached to a 
route.”

Can we add similar wording in here as similar logic applies?
It is still a “SHALL” rather than “must”, so even if the speaker receives 
multiple router-macs, the way you describe below will work.

Thanks,
--Satya

From: BESS  on behalf of "Ali Sajassi (sajassi)" 

Date: Thursday, October 8, 2020 at 12:15 PM
To: "John G. Scudder" 
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, BESS 
Subject: Re: [bess] Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding


Hi John,

Thanks for your feedback. I was also thinking along the line of (2). I’ll take 
care of it in the next rev. soon.

Cheers,
Ali


From: John Scudder 
Date: Thursday, October 8, 2020 at 11:57 AM
To: Cisco Employee 
Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" 
, BESS 
Subject: Re: Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Resent-From: 
Resent-To: Cisco Employee , , 
, , 
Resent-Date: Thursday, October 8, 2020 at 11:57 AM

Thanks, Ali.

Yes, I think this should be explicit in the spec. I’d also suggest being 
explicit about what “ignore the rest” means. It could mean one of two things —

1. Don’t pay attention to the extra ones for purposes of computing the local 
forwarding table, but store them and propagate them.
2. Also don’t store or propagate them.

I’m guessing option 2 is better in this case. The problem with propagating them 
is sometimes implementations reorder things, so you could end up with 
inconsistency in the network.

—John



On Oct 8, 2020, at 2:42 PM, Ali Sajassi (sajassi) 
mailto:saja...@cisco.com>> wrote:



Hi John,

Sorry for the delay.

The answer to your 1st question is no and the answer to your 2nd question is 
that the receiver should pick the first one in the list and ignore the rest. If 
it helps, I can add couple of lines to that affect to the corresponding section.

Cheers,
Ali

From: John Scudder mailto:j...@juniper.net>>
Date: Thursday, October 8, 2020 at 11:12 AM
To: 
"draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org"
 
mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>>
Cc: BESS mailto:bess@ietf.org>>
Subject: Second try: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Cisco Employee mailto:saja...@cisco.com>>, 
mailto:ssa...@cisco.com>>, 
mailto:stho...@cisco.com>>, 
mailto:jdr...@juniper.net>>, 
mailto:jorge.raba...@nokia.com>>
Resent-Date: Thursday, October 8, 2020 at 11:12 AM

Hi Authors,

I haven’t seen a reply to this message from almost a month ago, trying again. 
Even if you are still debating the answer amongst yourselves, it would be 
comforting to me to receive a reply to the effect of “we’re still thinking 
about this and will get back to you by $date”.

Thanks,

—John




Begin forwarded message:

From: "John G. Scudder" mailto:j...@juniper.net>>
Subject: Router's MAC Extended Community in 
draft-ietf-bess-evpn-inter-subnet-forwarding
Date: September 10, 2020 at 9:27:31 AM EDT
To: 
draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org
Cc: BESS mailto:bess@ietf.org>>

Hi Authors,

I just went through draft-ietf-bess-evpn-inter-subnet-forwarding to look for 
answers to two questions:

1. Can a router advertise multiple different Router’s MAC values? If yes, what 
is the receiver supposed to do?
2. Assuming the answer to question 1 is “no”, what is the receiver supposed to 
do if it receives multiple Router’s MAC Extended Communities (with different 
values) anyway, for example due to a bug or configuration error? This is a very 
real possibility since many BGP implementations allow policy to produce 
arbitrary communities.

Thanks,

—John

___
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-oam-req-frmwk-02

[Satya Mohanty (satyamoh)]

Support.

Thanks,
--Satya

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Monday, June 15, 2020 at 3:56 AM
To: "draft-ietf-bess-evpn-oam-req-fr...@ietf.org" 
, "bess@ietf.org" 
Subject: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-oam-req-frmwk-02

This email starts a two-week working group last call for 
draft-ietf-bess-evpn-oam-req-frmwk-02

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 Monday 29th June 2020.

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.
Thank you,
Matthew & Stephane

___
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

[Satya Mohanty (satyamoh)]

Support.

Thanks,
--Satya

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Friday, January 17, 2020 at 12:56 AM
To: "bess@ietf.org" , 
"draft-ietf-bess-evpn-unequal-lb.auth...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC , IPR and implementation poll for 
draft-ietf-bess-evpn-unequal-lb-03

Hi WG,

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

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

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] RFC 8277

[Satya Mohanty (satyamoh)]

Thanks Robert.
Yes, I made a general observation.

Best,
--Satya

From: Robert Raszuk 
Date: Thursday, December 12, 2019 at 11:34 AM
To: "Satya Mohanty (satyamoh)" 
Cc: Gyan Mishra , michael walden 
, "bess@ietf.org" 
Subject: Re: [bess] RFC 8277

Hi Satya,

I believe the address Michael is using in the route-map to set nh is one of the 
local addresses on the very ASBR.

Thx,
R.

On Thu, Dec 12, 2019 at 8:25 PM Satya Mohanty (satyamoh) 
mailto:satya...@cisco.com>> wrote:
Hi,

If the next-hop is set to some third-party device at the option-B ASBR and a 
new label is advertised, then we have to make sure that at that third-party 
device, the particular prefix is in fact bound to that particular label. 
Therefore, in addition to setting the next-hop at the ASBR there needs to be a 
way to specify the particular label also.

Otherwise just using any dynamic label will not work.

Thanks,
--Satya


From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Gyan Mishra mailto:hayabusa...@gmail.com>>
Date: Thursday, December 12, 2019 at 11:01 AM
To: michael walden mailto:michaelewal...@gmail.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" 
mailto:bess@ietf.org>>, Robert Raszuk 
mailto:rob...@raszuk.net>>
Subject: Re: [bess] RFC 8277



I can try it out in VIRL.

What version of XR or XE are you running?

On Thu, Dec 12, 2019 at 1:52 PM michael walden 
mailto:michaelewal...@gmail.com>> wrote:
Thank you for the responses.  This is specifically not using next hop self to 
change the next hop, but using a route map or RPL to set next hop to a specific 
IP value such as below.  I realize this probably isn't a common configuration.

route-map NH permit 10
 match ip address prefix-list ONE
 set ip next-hop x.x.x.x

route-policy NH
  if destination in (1.1.1.1/32<http://1.1.1.1/32>) then
set next-hop x.x.x.x

On Thu, Dec 12, 2019 at 12:48 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


With option b since the LSP is segmented into 3 segments

Left side Rx to R1 -ibgp
Middle R1 to R2 - ebgp vpnv4
Right side R2 to R3 - ibgp

So for the LSP to be segmented in opt b for it to work properly what is 
required is either next-hop-self on the ibgp peer so the rewrite happens 
forcing the label to change so the lsp is segmented on left side and right side 
from the middle.  The reason also for the segmentation in opt B is we are not 
importing the  SP loops between each other as done with opt c so the 
segmentation of the lsp has to happen for opt b to work.

If you are doing this on Cisco XR it requires next hop static /32  route for 
MPLS forwarding to happen on the ebgp vpnv4 session where with XE automatically 
installs “MPLS forwarding” when ebgp vpnv4 is configured.

If the rewrite is not happening to segment the lsp generate a new label then 
sounds like you are hitting a big.

The inter as opt a b c ab are all IETF standards and the functionality and 
behavior should be the same across all vendors.

Cheers,

Gyan

On Thu, Dec 12, 2019 at 11:55 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
/* replacing IETF mailer with BESS */

Hi Michael,

Clearly you have discovered a bug in first implementation. Second 
implementation "other platform" works correctly.

I assume you are doing next hop self on R2. Advertising labels have only local 
significance to a box which is listed as next hop in the NLRIs.

Btw this behaviour did not really change from original RFC3107 so it is quite 
surprising you would still be running into such issues.

Thx,
R.

On Thu, Dec 12, 2019 at 5:27 PM michael walden 
mailto:michaelewal...@gmail.com>> wrote:

Regarding RFC 8277 Section 3.2.2
3.2.2.  When the Next Hop Field Is Changed

   If the Network Address of Next Hop field is changed before a SAFI-4
   or SAFI-128 route is propagated, the Label field(s) of the propagated
   route MUST contain the label(s) that is (are) bound to the prefix at
   the new next hop.


"the Label field(s) of the propagated route MUST contain the label(s) that is 
(are) bound to the prefix at the new next hop."

This specification should apply when the next hop field of the route is changed 
by any means such as route map, route policies, or next-hop-self and propagated?

I've experienced differing behaviors between platforms as to whether or not a 
the label is changed when the next hop field is changed with a route map or 
route policy.

For example below inter-as option b R2 receives VPNv4 route 
1.1.1.1/32<http://1.1.1.1/32> with label 1 from R1.  R2 changes the next hop 
field with an outbound route policy but doesn't replace the label before 
propagating the route to R3.  R3 receives VPNv4 route 
1.1.1.1/32<http://1.1.1.1/32> and original label 1 breaking the LSP.

R1-eBGP- VPNv4-R2-iBGP VPNv4-R3


However on other platforms inter-as option b R2 receives VPNv4 route 
1.1.1.1/32<http://1.1.1.1/32> 

Re: [bess] RFC 8277

[Satya Mohanty (satyamoh)]

Hi,

If the next-hop is set to some third-party device at the option-B ASBR and a 
new label is advertised, then we have to make sure that at that third-party 
device, the particular prefix is in fact bound to that particular label. 
Therefore, in addition to setting the next-hop at the ASBR there needs to be a 
way to specify the particular label also.

Otherwise just using any dynamic label will not work.

Thanks,
--Satya


From: BESS  on behalf of Gyan Mishra 

Date: Thursday, December 12, 2019 at 11:01 AM
To: michael walden 
Cc: "bess@ietf.org" , Robert Raszuk 
Subject: Re: [bess] RFC 8277



I can try it out in VIRL.

What version of XR or XE are you running?

On Thu, Dec 12, 2019 at 1:52 PM michael walden 
mailto:michaelewal...@gmail.com>> wrote:
Thank you for the responses.  This is specifically not using next hop self to 
change the next hop, but using a route map or RPL to set next hop to a specific 
IP value such as below.  I realize this probably isn't a common configuration.

route-map NH permit 10
 match ip address prefix-list ONE
 set ip next-hop x.x.x.x

route-policy NH
  if destination in (1.1.1.1/32) then
set next-hop x.x.x.x

On Thu, Dec 12, 2019 at 12:48 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


With option b since the LSP is segmented into 3 segments

Left side Rx to R1 -ibgp
Middle R1 to R2 - ebgp vpnv4
Right side R2 to R3 - ibgp

So for the LSP to be segmented in opt b for it to work properly what is 
required is either next-hop-self on the ibgp peer so the rewrite happens 
forcing the label to change so the lsp is segmented on left side and right side 
from the middle.  The reason also for the segmentation in opt B is we are not 
importing the  SP loops between each other as done with opt c so the 
segmentation of the lsp has to happen for opt b to work.

If you are doing this on Cisco XR it requires next hop static /32  route for 
MPLS forwarding to happen on the ebgp vpnv4 session where with XE automatically 
installs “MPLS forwarding” when ebgp vpnv4 is configured.

If the rewrite is not happening to segment the lsp generate a new label then 
sounds like you are hitting a big.

The inter as opt a b c ab are all IETF standards and the functionality and 
behavior should be the same across all vendors.

Cheers,

Gyan

On Thu, Dec 12, 2019 at 11:55 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
/* replacing IETF mailer with BESS */

Hi Michael,

Clearly you have discovered a bug in first implementation. Second 
implementation "other platform" works correctly.

I assume you are doing next hop self on R2. Advertising labels have only local 
significance to a box which is listed as next hop in the NLRIs.

Btw this behaviour did not really change from original RFC3107 so it is quite 
surprising you would still be running into such issues.

Thx,
R.

On Thu, Dec 12, 2019 at 5:27 PM michael walden 
mailto:michaelewal...@gmail.com>> wrote:

Regarding RFC 8277 Section 3.2.2
3.2.2.  When the Next Hop Field Is Changed

   If the Network Address of Next Hop field is changed before a SAFI-4
   or SAFI-128 route is propagated, the Label field(s) of the propagated
   route MUST contain the label(s) that is (are) bound to the prefix at
   the new next hop.


"the Label field(s) of the propagated route MUST contain the label(s) that is 
(are) bound to the prefix at the new next hop."

This specification should apply when the next hop field of the route is changed 
by any means such as route map, route policies, or next-hop-self and propagated?

I've experienced differing behaviors between platforms as to whether or not a 
the label is changed when the next hop field is changed with a route map or 
route policy.

For example below inter-as option b R2 receives VPNv4 route 
1.1.1.1/32 with label 1 from R1.  R2 changes the next hop 
field with an outbound route policy but doesn't replace the label before 
propagating the route to R3.  R3 receives VPNv4 route 
1.1.1.1/32 and original label 1 breaking the LSP.

R1-eBGP- VPNv4-R2-iBGP VPNv4-R3


However on other platforms inter-as option b R2 receives VPNv4 route 
1.1.1.1/32 with label 1 from R1.  R2 changes the next hop 
field with an outbound route policy and does replace the label before 
propagating the route to R3.  R3 receives VPNv4 route 
1.1..1.1/32 and new label 2.

R1-eBGP- VPNv4-R2-iBGP VPNv4-R3






___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
--
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia 
Pike
 FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com

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

[Satya Mohanty (satyamoh)]

Support.

Thanks,
--Satya

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, November 27, 2019 at 4:37 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

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

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

[Satya Mohanty (satyamoh)]

Support.

Thanks,
--Satya

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, October 28, 2019 at 3:10 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG adoption poll for 
draft-sajassi-bess-evpn-mvpn-seamless-interop

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

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

[Satya Mohanty (satyamoh)]

Hi,

Support as co-author. I am not aware of any undisclosed IPR related to this 
draft.

Thanks,
--Satya

From: "slitkows.i...@gmail.com" 
Date: Tuesday, October 22, 2019 at 7:46 AM
To: "bess@ietf.org" , "draft-ietf-bess-evpn-pref...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: WGLC, IPR and implementation poll for draft-ietf-bess-evpn-pref-df
Resent-From: 
Resent-To: , , 
, , "jdr...@juniper.net" 
, , 
Resent-Date: Tuesday, October 22, 2019 at 7:46 AM

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

Re: [bess] Comments on draft-ietf-bess-evpn-pref-df

[Satya Mohanty (satyamoh)]

Hi Stephane,

An alternative way to guarantee precedence per vlan (i.e. the most granular) 
rather than the vlan-range in the vlan-based service models, could be by using 
the DF extcom in the per EVI AD route instead of the procedures in Section 4.2 
relevant to the vlan range.

But this may not be required in a real deployment and specification of 
precedence per a vlan-range is probably sufficient.

So, I agree with Jorge regarding his observation of vES.

Best,
--Satya

From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Sunday, September 29, 2019 at 4:10 AM
To: "slitkows.i...@gmail.com" , 
"draft-ietf-bess-evpn-pref...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: Comments on draft-ietf-bess-evpn-pref-df
Resent-From: 
Resent-To: , , 
, , "jdr...@juniper.net" 
, , 
Resent-Date: Sunday, September 29, 2019 at 4:09 AM

Hi Stephane,

Please see in-line.

If you think we should add some text making my comments below more explicit, 
I’d be happy to do it.
Thank you.
Jorge

From: "slitkows.i...@gmail.com" 
Date: Saturday, September 28, 2019 at 4:57 AM
To: "draft-ietf-bess-evpn-pref...@ietf.org" 
, "bess@ietf.org" 
Subject: Comments on draft-ietf-bess-evpn-pref-df
Resent-From: 
Resent-To: , , 
, , , 
, 
Resent-Date: Saturday, September 28, 2019 at 4:57 AM

Hi Authors,

I had a look on your draft and I have some concerns/questions that I would like 
to discuss.
I like the fact of being able to tune the pref DF election per VLAN range, 
however:

-  Don’t you think that using a local configuration may open to 
inconsistent configurations resulting in issues ?
[JORGE] We discussed quite a few times whether we should signal the vlan ranges 
for which you desire high_pref or low_pref. We ended up coming to the 
conclusion that it is better/simpler (and already supported) to define virtual 
ethernet segments for ranges of vlans and then have the default high_pref that 
is defined in the spec. That is less prone to errors. E.g. on a given port, 
define two ranges: vlan (1-2k) --> vES-1 and [(2k+1)-4k] -->vES-2. On a given 
PE, vES-1 and vES-2 have different pref values.


-  How does the high_or_low works if I have more than 2 links in the ES 
? (multihoming with 4 links with 4 levels of preference ?)
[JORGE] if you want 4 levels of preference so that each of the 4 PEs is DF for 
a range of vlans, the easiest way as discussed above is to define 4 vESes. The 
high_or_low is an easy way of having load balancing if you have only 2 PEs in 
the ES and you really want to define only one ES.

Thanks,

Stephane

___
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

[Satya Mohanty (satyamoh)]

Support.

Thanks,
--Satya

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Monday, June 17, 2019 at 1:56 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-igmp-mld-proxy


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



[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

Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

[Satya Mohanty (satyamoh)]

Hi Muthu,

As you mentioned it is straightforward to calculate the BDF in the default DF 
Algorithm by taking the current DF out of reckoning.
It is my personal view that since this is self-evident it need not be 
explicitly stated.
But I will let others decide.


Thanks,
--Satya

From: Muthu Arul Mozhi Perumal 
Date: Monday, March 25, 2019 at 8:22 AM
To: "Satya Mohanty (satyamoh)" 
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
"bess@ietf.org" 
Subject: Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

Hi Satya,

draft-ietf-bess-evpn-df-election-framework also does not describe how the BDF 
is to be calculated for the default DF election algo. Am I missing something?

I think my question still holds:
Though it is straightforward to calculate the BDF by eliminating the DF from 
the candidate list, would an implementation calculating the BDF that way for 
the default DF election algo interoperate without any problem?

Would it be better to update draft-ietf-bess-evpn-df-election-framework on how 
the BDF is to be calculated in general for any DF election algo (including the 
default DF election algo)?
[Satya] IMHO opinion, much as it appears obvious, we cannot say for certain 
that in every future DF algorithm (that may come into existence), the BDF 
computation will always be as simple as taking the current DF (PE) out of 
reckoning and doing the recomputation.

Regards,
Muthu

Best,
--Satya

On Sat, Mar 23, 2019 at 2:46 AM Satya Mohanty (satyamoh) 
mailto:satya...@cisco.com>> wrote:
Hi Muthu,

Yes, the BDF is as per what you have mentioned.
https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-09 
formally defines it.

Thanks,
--Satya

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>>
Date: Friday, March 22, 2019 at 11:41 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

Thanks, Jorge. Need another clarification. RFC 7432 does not describe how to 
calculate the BDF for the default DF algo. Though it is straightforward to 
calculate the BDF by eliminating the DF from the candidate list, would an 
implementation calculating the BDF that way for the default DF algo 
interoperate without any problem?

Regards,
Muthu

On Fri, Mar 22, 2019 at 11:45 PM Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:
Hi,

Well, everyone has to support the default DF Alg, based on RFC7432. So that one 
for sure. And in addition there are others that have been implemented. For 
instance, Pref DF election has been implemented by multiple vendors.
Thanks,
Jorge


From: Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>>
Sent: Friday, March 22, 2019 10:41
To: Rabadan, Jorge (Nokia - US/Mountain View)
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

Hi Jorge,

I didn't mean using different algorithms for electing the DF and BFD. I am just 
asking which algorithm is most widely implemented/used for electing the DF 
*and* BDF for EVPN VPWS single-active multihoming.

Regards,
Muthu

On Fri, Mar 22, 2019 at 7:47 PM Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:
The implementations I know use the same DF Alg for DF election _and_ backup DF 
Election. And I don’t see why you would use something different?
In other words, if you use e.g., Pref based DF Alg, use it for DF and BDF 
elections. Only that the BDF election excludes the DF from the candidate list.

Thx
Jorge

From:BESS mailto:bess-boun...@ietf.org>> on behalf of 
Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>>
Date: Friday, March 22, 2019 at 4:23 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Subject: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

While RFC 8214 doesn't recommend any DF election algorithm capable of electing 
the BDF in EVPN VPWS single-active multihoming for deciding the backup PE, any 
feedback on what is(are) the widely implemented/supported DF election  
algorithm(s) by vendors?

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

Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

[Satya Mohanty (satyamoh)]

Hi Muthu,

Yes, the BDF is as per what you have mentioned.
https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-09 
formally defines it.

Thanks,
--Satya

From: BESS  on behalf of Muthu Arul Mozhi Perumal 

Date: Friday, March 22, 2019 at 11:41 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: "bess@ietf.org" 
Subject: Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

Thanks, Jorge. Need another clarification. RFC 7432 does not describe how to 
calculate the BDF for the default DF algo. Though it is straightforward to 
calculate the BDF by eliminating the DF from the candidate list, would an 
implementation calculating the BDF that way for the default DF algo 
interoperate without any problem?

Regards,
Muthu

On Fri, Mar 22, 2019 at 11:45 PM Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:
Hi,

Well, everyone has to support the default DF Alg, based on RFC7432. So that one 
for sure. And in addition there are others that have been implemented. For 
instance, Pref DF election has been implemented by multiple vendors.
Thanks,
Jorge


From: Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>>
Sent: Friday, March 22, 2019 10:41
To: Rabadan, Jorge (Nokia - US/Mountain View)
Cc: bess@ietf.org
Subject: Re: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

Hi Jorge,

I didn't mean using different algorithms for electing the DF and BFD. I am just 
asking which algorithm is most widely implemented/used for electing the DF 
*and* BDF for EVPN VPWS single-active multihoming.

Regards,
Muthu

On Fri, Mar 22, 2019 at 7:47 PM Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:
The implementations I know use the same DF Alg for DF election _and_ backup DF 
Election. And I don’t see why you would use something different?
In other words, if you use e.g., Pref based DF Alg, use it for DF and BDF 
elections. Only that the BDF election excludes the DF from the candidate list.

Thx
Jorge

From:BESS mailto:bess-boun...@ietf.org>> on behalf of 
Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>>
Date: Friday, March 22, 2019 at 4:23 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Subject: [bess] BDF Election in EVPN VPWS Single-Active Multihoming

While RFC 8214 doesn't recommend any DF election algorithm capable of electing 
the BDF in EVPN VPWS single-active multihoming for deciding the backup PE, any 
feedback on what is(are) the widely implemented/supported DF election  
algorithm(s) by vendors?

Regards,
Muthu
___
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

[Satya Mohanty (satyamoh)]

Support the draft.

Thanks,
--Satya

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Tuesday, March 5, 2019 at 12:43 AM
To: "bess@ietf.org" , 
"draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

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] Adam Roach's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

[Satya Mohanty (satyamoh)]

Adam,



Thanks to you and Benjamin for this review and feedback on the hashing. Please 
see inline [Satya].

I will add my response to other queries in the forthcoming Jorge's reply to  
Benjamin (as there are other comments to be addressed).



Best,

--Satya



On 1/9/19, 10:31 PM, "Adam Roach"  wrote:



Adam Roach has entered the following ballot position for

draft-ietf-bess-evpn-df-election-framework-07: No Objection



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/







--

COMMENT:

--



I have one minor comment that the authors may wish to consider.



§1.2.1:



>  It is well-known that for good

>  hash distribution using the modulus operation, the modulus N should

>  be a prime-number not too close to a power of 2 [CLRS2009].



I suppose this refers to the explanation in [CLRS2009] §11.3.1. The

[Satya] Yes, it is from [CLRS2009] §11.3.1

description there is pretty hand-wavy and not completely accurate except 
under

certain (admittedly common) conditions -- in which this case is not 
included.

You may wish to consider instead citing "The Art of Computer Programming 
(Vol.

3)" by Knuth, as it captures a lot more of the nuance behind why this rule 
of

thumb is frequently true, and covers the general case. There is probably a 
set

of considerations to take into account for Ethernet Tags with an even

distribution, but only because you have a relatively small set of potential

inputs -- not for any of the reasons cited in [CLRS2009]. Quoting Knuth:



  In general, we want to avoid values of M that divide r^k+a or r^k−a, 
where k

  and a are small numbers and r is the radix of the alphabetic character set

  (usually r=64, 256 or 100), since a remainder modulo such a value of M 
tends

  to be largely a simple superposition of key digits. Such considerations

  suggest that we choose M to be a prime number such that r^k!=a(modulo)M or

  r^k!=−a(modulo)M for small k & a.



I see that Benjamin has made a related comment. I share his objection to

the way point #2 is phrased, and think it needs to be reworded to properly

capture the subtleties implied by the preceding passage.



[Satya] Yes, noted. I will change point #2.  Here is a suggested description of 
Point #2



Th Ethernet tag that identifies the BD can be as large as 2^24; however, it is 
not guaranteed that the tenant BD on the ES will conform to a uniform 
distribution. In fact, it up to the customer what BDs they will configure on 
the ES. Quoting Knuth [Art of Computer Programming Pg. 516]



  " In general, we want to avoid values of M that divide r^k+a or r^k−a, where k

  and a are small numbers and r is the radix of the alphabetic character set

  (usually r=64, 256 or 100), since a remainder modulo such a value of M 
tends

  to be largely a simple superposition of key digits. Such considerations

  suggest that we choose M to be a prime number such that r^k!=a(modulo)M or

  r^k!=−a(modulo)M for small k & a."



In our case, N is the number of PEs in RFC 7432 which corresponds to M above.

Since N, N-1 or N+1 need not satisfy the primality properties of the M above; 
as per RFC 7432 modulo based DF assignment, whenever a PE goes down or a new PE 
boots up (hosting the same Ethernet Segment), the modulo scheme need not 
necessarily map BDs to PEs uniformly.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Referencing material behind a paywall

[Satya Mohanty (satyamoh)]

Thank you Stephen, Carsten and Heather for your input.
Jorge will be publishing the revised version soon.

Best Regards,
--Satya

On 12/10/18, 2:14 PM, "Stephen Farrell"  wrote:



On 10/12/2018 20:41, Heather Flanagan wrote:
> Ekr offered an interesting proposal that would have this kind of
> reference be treated in a fashion similar to IPR declarations.

Not a bad idea. I'd also make it like the downref registry [1]
though, since once we've got a normative reference in one RFC
to e.g. some IEEE 802 thing, then it shouldn't need new process
to have a 2nd RFC do the same.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/downref/


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

Re: [bess] Rtgdir last call review of draft-ietf-bess-evpn-df-election-framework-06

[Satya Mohanty (satyamoh)]

Hi Jorge and Adrian. 

Inline [Satya].

Thanks,
--Satya

On 12/14/18, 2:40 AM, "Rabadan, Jorge (Nokia - US/Mountain View)" 
 wrote:

Hi Adrian,

Thank you very much for your thorough review.
I incorporated most of your comments, please see the details in-line with 
[JORGE].

There is one outstanding comment that Satya and I will discuss.

Thank you.
Jorge

-Original Message-
    From: "Satya Mohanty (satyamoh)" 
Date: Friday, December 7, 2018 at 9:11 PM
To: Adrian Farrel , "rtg-...@ietf.org" 

Cc: "draft-ietf-bess-evpn-df-election-framework@ietf.org" 
, "i...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: Rtgdir last call review of 
draft-ietf-bess-evpn-df-election-framework-06
Resent-From: 
Resent-To: , , 
, , , 
, , 
, , 
, , , 
Stephane Litkowski 
Resent-Date: Friday, December 7, 2018 at 9:11 PM

Hi Adrian,

Thank you very much for your detailed review and comments.
We will take care of all the nits that you have pointed out and include 
the reference to the IEEE/ACM TON paper (the link you have pointed out is 
indeed correct).

However, I had one query. Most of the time research journal/conference 
papers will be behind a paywall and there may not be a free cached copy 
available online.
How do we get across this problem?

Best,
--Satya

On 12/7/18, 7:20 AM, "Adrian Farrel"  wrote:

Reviewer: Adrian Farrel
Review result: Has Nits

Hello,
I have been selected as the Routing Directorate reviewer for this 
draft. The
Routing Directorate seeks to review all routing or routing-related 
drafts as
they pass through IETF last call and IESG review, and sometimes on 
special
request. The purpose of the review is to provide assistance to the 
Routing ADs.
For more information about the Routing Directorate, please see
?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although 
these comments
are primarily for the use of the Routing ADs, it would be helpful 
if you could
consider them along with any other IETF Last Call comments that you 
receive,
and strive to resolve them through discussion or by updating the 
draft.

Document: draft-ietf-bess-evpn-df-election-framework-06.txt
Reviewer: Adrian Farrel
Review Date: 2018-12-07
IETF LC End Date: 2018-12-18
Intended Status: Standards Track

Summary:

This document is basically ready for publication, but has nits that 
should be
considered prior to publication.

Comments:

This document addresses issues in the default election algorithm 
used for
Designated Forwarder Election in EVPN (RFC 7432 and RFC 8124) by 
defining a new
election algorithm and a capability to influence the election 
result for a
VLAN, depending on the state of the associated Attachment Circuit.

This is an exceptionally clear and well written document. The 
authors and the
working group are to be congratulated.

During my review I observed a number of small issues and editorial 
nits. I
don't believe any of these is cause for discussion in the working 
group, but it
would be sensible to resolve them before publication.

Thanks and Happy Christmas,
Adrian
--
It's Christmas.
Buy someone you love a book of fairy tales.
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

===

Major Issues:
 No major issues found

===

Minor Issues:

HRW1999 is provided as a normative reference, and from the text I 
can
see why. But no URL (stable or otherwise) is given for the 
reference.
Using my favorite search engine, I looked for and found a copy of
the referenced document on the IEEE site behind a paywall. I don't
think that will do at all. However, there is a version at

https://www.microsoft.com/en-us/research/wp-content/uploads/2017/02/HRW98.pdf
That appears to be dated 1998, but otherwise could be the same 
paper.

[JORGE] ok, we added the link and move it to informative references. Thanks!

---

When I read in Section 3...

   In a

Re: [bess] Rtgdir last call review of draft-ietf-bess-evpn-df-election-framework-06

[Satya Mohanty (satyamoh)]

Hi Adrian,

Thank you very much for your detailed review and comments.
We will take care of all the nits that you have pointed out and include the 
reference to the IEEE/ACM TON paper (the link you have pointed out is indeed 
correct).

However, I had one query. Most of the time research journal/conference papers 
will be behind a paywall and there may not be a free cached copy available 
online.
How do we get across this problem?

Best,
--Satya

On 12/7/18, 7:20 AM, "Adrian Farrel"  wrote:

Reviewer: Adrian Farrel
Review result: Has Nits

Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing 
ADs.
For more information about the Routing Directorate, please see
?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these 
comments
are primarily for the use of the Routing ADs, it would be helpful if you 
could
consider them along with any other IETF Last Call comments that you receive,
and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-bess-evpn-df-election-framework-06.txt
Reviewer: Adrian Farrel
Review Date: 2018-12-07
IETF LC End Date: 2018-12-18
Intended Status: Standards Track

Summary:

This document is basically ready for publication, but has nits that should 
be
considered prior to publication.

Comments:

This document addresses issues in the default election algorithm used for
Designated Forwarder Election in EVPN (RFC 7432 and RFC 8124) by defining a 
new
election algorithm and a capability to influence the election result for a
VLAN, depending on the state of the associated Attachment Circuit.

This is an exceptionally clear and well written document. The authors and 
the
working group are to be congratulated.

During my review I observed a number of small issues and editorial nits. I
don't believe any of these is cause for discussion in the working group, 
but it
would be sensible to resolve them before publication.

Thanks and Happy Christmas,
Adrian
--
It's Christmas.
Buy someone you love a book of fairy tales.
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

===

Major Issues:
 No major issues found

===

Minor Issues:

HRW1999 is provided as a normative reference, and from the text I can
see why. But no URL (stable or otherwise) is given for the reference.
Using my favorite search engine, I looked for and found a copy of
the referenced document on the IEEE site behind a paywall. I don't
think that will do at all. However, there is a version at

https://www.microsoft.com/en-us/research/wp-content/uploads/2017/02/HRW98.pdf
That appears to be dated 1998, but otherwise could be the same paper.

---

When I read in Section 3...

   In addition, since the specification in EVPN
   [RFC7432] does leave several questions open as to the precise final
   state machine behavior of the DF election, section 3.1 describes
   precisely the intended behavior.

... I wondered whether this document is updating 7432 in that respect.

Other features later in the document (such as section 5) confirm this.

---

Notwithstanding the mention of backward compatiblity in section 6, I
think it would be a good idea to include a very short section 3.2.1.

3.2.1.  Backward Compatibility

   Legacy implementations (i.e., those that predate this specification)
   will not advertise the DF Election Extended Community.  That means
   that all other participating PEs will not receive DF preferences and
   will revert to the defailt algorithm without AC-Influenced DF
   Election.

   Similarly, a legacy implementation receiving a DF Election Extended
   Community will ignore it and will continue to use the default
   algorithm.

---

On first reading, I missed an important subtlty in 3.2. The paragraph...

 - Otherwise if even a single advertisement for the type-4 route is
   not received with the locally configured DF Alg and capability,
   the default DF Election algorithm (modulus) algorithm MUST be
   used as in [RFC7432].

...is really important because it handles what to do if different
participating PEs disagree about which algorithm to use.  Your text is
perfectly fine and adequate, but the "locally configured" sort of hid
it from me first time around.

Maybe add a sentence to the 

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

[Satya Mohanty (satyamoh)]

Hi Anoop,

Thank you very much for your editorial comments and review.
We will take care of it.

Best,
--Satya


On 12/7/18, 1:01 AM, "BESS on behalf of Anoop Ghanwani"  wrote:

I have reviewed the doc and I have mostly editorial comments.

Thanks,
Anoop

==

Throughout

VLAN Bundle, VLAN bundle, VLAN-Bundle, VLAN-bundle -- make consistent
VLAN Aware Bundle, VLAN-aware bundle, VLAN-Aware Bundle -- make consistent
bridge table, Bridge Table -- make consistent (also add definition to
terminology section)
DF election, DF Election -- make consistent
Default DF Election, default DF Election -- make consistent
non-DF -> NDF

Section 1

double Q-in-Q tags -> Q-in-Q tags

double is redundant

Section 2.1

Fig 1 is a bit confusing.  If the idea of the rectangle is to show a
core, then why have connections between PE1 and PE2, PE3, but not
between PE1 and PE4?

Change
>>>
Layer-2 devices are particularly susceptible to forwarding loops
because of the broadcast nature of the Ethernet traffic.
>>>
to
The effect of forwarding loops in a Layer-2 network is particularly
severe because of the broadcast nature of Ethernet traffic and the
lack of a TTL.

Section 2.2.1

a v4 or v6 peering -> an IPv4 or IPv6 peering

>>>
>From a forwarding perspective, this is
a churn, as it results in re-programming the PE ports as either
blocking or non-blocking at potentially all PEs when the DF changes.
>>>

Why would the reprogramming change at all PEs?  It should change for
at most 2 PEs for each (ES,EVI) being reprogrammed.  Maybe authors
were trying to convey something else?


Section 2.3

>>>
DF Election procedure Generally
>>>
Missing a period.


Section 3

specification in EVPN -> EVPN specification


Section 3.1

DF WAIT, DF_WAIT -- make consistent
DF Wait timer -- where is this defined?
Ethernet Segment Route -> Ethernet Segment route
stop DF timer ->  stop DF wait timer (?)
start DF timer -> start DF wait timer (?)

Section 4

rather than the state of the server states -> rather than the state of
the server (?)

Section 4.2

Si is the IP address of server i -> Si is the IP address of PE i
operator chooses so -> operator so chooses
Note 0 <= i,j <= Number of PEs -- should this be "< Number of PEs"?
Weight(V, Es, Sk) -> Weight(v, Es, Sk)
Pseudo-random -> pseudo-random
efficient deterministic -> efficient and deterministic
V4 -> IPv4
V6 -> IPv6

___
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

[Satya Mohanty (satyamoh)]

Support.

Thanks,
--Satya

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Tuesday, September 4, 2018 at 12:29 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption poll for draft-malhotra-bess-evpn-unequal-lb-04

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

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

[Satya Mohanty (satyamoh)]

Support.

Thanks,
--Satya

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Wednesday, August 8, 2018 at 6:38 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption poll and IPR poll for 
draft-sajassi-bess-evpn-per-mcast-flow-df-election

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

Re: [bess] WG Adoption and IPR Poll for draft-sajassi-bess-evpn-virtual-eth-segment-03

[Satya Mohanty (satyamoh)]

Support adoption.

Thanks,
--Satya

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Friday, June 1, 2018 at 5:48 AM
To: "bess@ietf.org" 
Cc: "draft-sajassi-bess-evpn-virtual-eth-segm...@ietf.org" 

Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-sajassi-bess-evpn-virtual-eth-segment-03

We’ve only had a couple of responses from people who are not co-authors of the 
draft. It would be good to see some wider interest, so please review the draft 
and indicate to the list if you support adoption or not, especially if you are 
not a co-author. I will extend the poll for adoption for another week, 
accordingly.

Thanks to those who have already commented.

Regards

Matthew and Stephane

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Thursday, 17 May 2018 at 11:24
To: "bess@ietf.org" 
Cc: "draft-sajassi-bess-evpn-virtual-eth-segm...@ietf.org" 

Subject: [bess] WG Adoption and IPR Poll for 
draft-sajassi-bess-evpn-virtual-eth-segment-03

This email begins a two-week poll for adoption of 
draft-sajassi-bess-evpn-virtual-eth-segment-03.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.

This poll for adoption closes on Thursday 31st May 2018.

Regards,
Matthew and Stéphane

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

Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework

[Satya Mohanty (satyamoh)]

Hi Stephane,

Many thanks for your detailed review.
We will take care of the comments and do the due diligence.

Regarding one comment that you had


[Stephane]

Section 4.1

Any clue on why HRW has been picked compared to CHASH algorithms ?


I am assuming you mean CHASH to be "Consistent Hashing”?


Thanks,

—Satya


From: "stephane.litkow...@orange.com" 
>
Date: Tuesday, April 24, 2018 at 2:03 AM
To: "bess@ietf.org" 
>, 
"draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org"
 
>
Subject: Shepherd's review of draft-ietf-bess-df-election-framework
Resent-From: >
Resent-To: >, satyamoh 
>, 
>, 
>, 
>, 
>
Resent-Date: Tuesday, April 24, 2018 at 2:04 AM

Hi,

Here is my review of the document:


General comments:
-

-  The document requires sometimes to be more generic as it describes a 
flexible framework for DF election rather than focusing on default election or 
HRW. See detailed comments.

-  The new FSM description is not enough clear in the text and AC-DF 
description provides updates to this FSM which are not aligned with the initial 
FSM description (events, states…).

-  It is not really clear if the document updates RFC7432 in some 
aspects (see detailed comments).

ID-Nits:
--


Miscellaneous warnings:

  



  == The document seems to lack the recommended RFC 2119 boilerplate, even if

 it appears to use RFC 2119 keywords -- however, there's a paragraph with

 a matching beginning. Boilerplate error?



 (The document does seem to have the reference to RFC 2119 which the

 ID-Checklist requires).

  -- The document date (April 12, 2018) is 12 days in the past.  Is this

 intentional?





  Checking references for intended status: Proposed Standard

  



 (See RFCs 3967 and 4897 for information about using normative references

 to lower-maturity documents in RFCs)



  == Missing Reference: 'RFC 7432' is mentioned on line 248, but not defined



  == Unused Reference: 'RFC7153' is defined on line 1034, but no explicit

 reference was found in the text



  == Unused Reference: 'RFC4271' is defined on line 1046, but no explicit

 reference was found in the text



  -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999'


Detailed comments:
--

Section 2.1.

Using a linking word like “However” before “The described default DF election 
algorithm has some undesirable properties” would be suitable IMO to emphasis 
the contrast with the initial expectations of this algorithm mentioned in the 
previous paragraph.

“This document describes those issues…”
Maybe using “some of those issues” or “some known issues” is more accurate, I 
do not think that the document points all the issues.


“These mechanisms do involve changes to the default
   DF Election algorithm, however they do not require any protocol
   changes to the EVPN Route exchange and have minimal changes to their
   content per se.”
Don’t you consider that adding a community is a protocol change ?


I think this introduction should emphasis that there is a need for a flexible 
DF election as a single algorithm may not fit everyone’s requirement.


Section 2.2


“In this particular case, in fact one of the PEs does not

  get elected all as the DF, so it does…”

[SLI] I do not understand completely this sentence (maybe an English issue on 
my side). Do you mean “get elected at all” ?





“So PE1, PE2 and PE3 are also the DFs for

  v1, v2 and v3 respectively.”

[SLI] Maybe the word “also” can be removed.



“This need not be

   the case as there can be a v6 peering and supporting the EVPN

   address-family.”

[SLI] “This need not be the case as the EVPN address-family can be carried over 
a v6 peering”





What does the two last paragraph bring in term of information ? It sounds 
redundant with the third point.





Section 2.2.2

“there is no procedure defined in EVPN 
[RFC7432] to trigger

   the DF re- election based on the ACS change on the DF.”

s/re- election/re-election/



“This document 

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

[Satya Mohanty (satyamoh)]

Support.

Thanks,
—Satya

From: BESS > on behalf of 
"Bocci, Matthew (Nokia - GB)" 
>
Date: Wednesday, March 28, 2018 at 5:50 AM
To: 
"draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org"
 
>,
 "bess@ietf.org" >
Cc: "bess-cha...@ietf.org" 
>
Subject: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

This email begins a two-week working group last call for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.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 11th April.

Regards,
Matthew and Stéphane
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

[Satya Mohanty (satyamoh)]

Hi Stephane,

I am not aware of any IPR that hasn’t already been disclosed.
 Cisco has implemented the HRW DF election that is described in this draft.

Thanks,
—Satya

From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Monday, March 26, 2018 at 7:21 AM
To: "bess@ietf.org" >
Subject: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-df-election-framework-00 [1]



This poll runs until *the 9th of April*.



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.



Currently no IPR has been disclosed 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 implementation.



Thank you



Matthew, Stéphane

bess chairs



[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/



_

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] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[Satya Mohanty (satyamoh)]

Hi John,

We will take your feedback into account.

Thanks,
—Satya

From: "jdr...@juniper.net" 
>
Date: Monday, March 26, 2018 at 6:00 AM
To: satyamoh >, Sandy Breeze 
>, "Rabadan, Jorge 
(Nokia - US/Mountain View)" 
>, Eric Rosen 
>, 
"bess@ietf.org" >
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Satya,

Comment inline.

Yours Irrespectively,

John


[John] Wouldn’t it be better to have this draft define a bit in the Multicast 
Flags extended community 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-01)
 indicating that that the originating PE is neither DF nor backup DF for this 
broadcast domain on any ES to which it is attached?  This allows us to always 
advertise the IMET route and makes the situation explicit.  I think the 
consensus is that this situation is rare so the number of IMET route updates 
shouldn’t be excessive and we could also say that this bit is only set by EVPN 
DC GWs.
[Sandy] We discussed the use of extended community to signal NDF, this is 
indeed a viable alternative approach and one we’re not against.  We didn’t 
choose it over not sending IMET because we don’t have a good reason why not 
sending IMET at an NDF is actually a bad idea, for our use case.  That said, if 
the consensus of this list is to use an extended community then a flag in EVPN 
extended community sub-types registry is a possible fit
[Satya] Just to make clear, the Multicast Flags extended community is only sent 
with the IMET when IGMP proxy is supported. If the BD does not support 
IGMP/MLD, then this won’t work as Jorge pointed out earlier (BUM with IR only). 
Perhaps, if there  were available flag fields in the PMSI Tunnel attr, one 
could have used it. Also, creation of a new extended community for the purpose 
of this optimization looks to me to be adding extra complexity to the CP. So we 
did not prefer doing that. Setting the label to 0 would have worked, but the 
value 0 now has the semantics that Sandy points out below.

[JD]  I don’t think this is correct.  The IGMP Proxy draft defines the 
Multicast Flags extended community, which means that your draft would need to 
have a normative reference to that draft.  However, your draft would be free to 
define a new bit in the extended community and indicate that support for the 
that bit is not contingent upon support for the IGMP Proxy draft.


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

Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[Satya Mohanty (satyamoh)]

Some additional comments inline [Satya]

From: BESS > on behalf of 
Sandy Breeze >
Date: Saturday, March 24, 2018 at 11:39 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
>, Eric C Rosen 
>, 
"bess@ietf.org" >
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

John, Eric, Jorge,

[Sandy] Comments inline


On 24/03/2018, 10:57, "Rabadan, Jorge (Nokia - US/Mountain View)" 
> wrote:

Eric, as discussed and you point out, one can easily interpret that IMET is not 
mandatory in some cases where multi-destination traffic is not needed. In any 
case, whether this document is Informational or Standards Track is probably not 
that important.

If this had to be done, out of the options you list, I think omitting the PTA 
would not be backwards compatible since the use of PTA is a MUST in RFC7432, so 
RRs wouldn’t like it. Maybe label zero could cause issues too. So maybe a flag 
is the least disruptive one if the document has to modify something.
[Sandy] I agree, and detailed reasoning on those points in line below

I still think it may be better to proceed with the IMET withdraw procedure and 
clarify that it is only valid for:
a) BUM traffic in IR cases
b) BDs with no igmp/mld/pim proxy
c) BDs with no OISM or IRBs
d) BDs with I-ES associated to overlay tunnels and no other ACs
[Sandy] We’re happy to call out those restrictions under a definition of what 
we mean in connecting EVPN domains at DCI for L2 only scenarios
[Satya] Yes, This is applicable for the restricted cases as stated above.


And any other restrictions/caveats we may need to add.

My 2 cents.
Jorge

On 23/03/2018, 17:00, "Eric C Rosen" 
> wrote:

[Jorge] my interpretation of RFC7432 is that IMET routes are mandatory to 
enable the handling of multi-destination traffic in a BD. But in a non-DF PE 
for a given ES and with no other ACs in the BD, assuming Ingress Replication, 
there is no such multi-destination traffic (Tx or Rx). So one could interpret 
that RFC7432 is ok with withdrawing the IMET route in that case.

If we consider the case of all-active multi-homing, then there may well be Tx 
multi-destination traffic in the scenario under discussion, as multicast 
traffic from a given ES could arrive at any PE attached to the ES, whether or 
not that PE is the DF.

[Sandy] In the specific scenario with all-active multi-homing, EVPN GW / DCI 
routers connect an EVPN VXLAN fabric and an EVPN MPLS core.  Therefore, for all 
NDF PE’s (read EVPN GW’s) there will be no IMET sent to neither RR’s in the 
EVPN MPLS core, nor to ToR in the EVPN VXLAN fabric – so neither side of the 
EVPN GW would attract BUM.



The relevant section from RFC 7432 is:

11.  Handling of Multi-destination Traffic

   Procedures are required for a given PE to send broadcast or multicast
   traffic received from a CE encapsulated in a given Ethernet tag
   (VLAN) in an EVPN instance to all the other PEs that span that
   Ethernet tag (VLAN) in that EVPN instance.  In certain scenarios, as
   described in Section 12 ("Processing of Unknown Unicast Packets"), a
   given PE may also need to flood unknown unicast traffic to other PEs.

   The PEs in a particular EVPN instance may use ingress replication,
   P2MP LSPs, or MP2MP LSPs to send unknown unicast, broadcast, or
   multicast traffic to other PEs.

   Each PE MUST advertise an "Inclusive Multicast Ethernet Tag route" to
   enable the above.  The following subsection provides the procedures
   to construct the Inclusive Multicast Ethernet Tag route.  Subsequent
   subsections describe its usage in further detail.

Interestingly, this says that the IMET route is mandatory to enable "the 
above", where "the above" is "send broadcast or multicast traffic received from 
a CE".  Note it says "send", not "receive".

[Sandy] This is a very good point Eric.  Its my understanding the reasons for 
‘sending’ IMET is because you want to signal eligibility to receive BUM 
traffic.  ‘send’ vs ‘receive’ wording aside, I agree with the RFC7432 in that 
as per my first comment above, those PE’s would not attract BUM from the EVPN 
VXLAN fabric side, because they also wouldn’t be sending the IMET to ToR, if 
they’re NDF…



If P2MP tunnels are used for the BUM traffic, the IMET route is certainly 
required to support all-active multi-homing.
[Sandy] I concur

If IR is used, or if single-active multi-homing is used, one could argue that 
RFC 7432 didn't really need to require the IMET route.  However, it does.
[Sandy] I do not concur, as per my previous point, and noting that 7432 wording 
asserts that sending IMET enables a PE 

Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[Satya Mohanty (satyamoh)]

Hi John,

That is right. I get your point.

I replied in the preceding mail the reasons for having this option.
If we all decide this is not particularly useful, we don’t have to take that 
into account.

Thanks,
—Satya


From: "jdr...@juniper.net<mailto:jdr...@juniper.net>" 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>
Date: Thursday, March 22, 2018 at 2:17 AM
To: satyamoh <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>, 
Sandy Breeze <sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Satya,

If we do this, it requires that we define two different DF election types, one 
that uses ESI and one that doesn't.  Given that we have other DF election types 
that will give us the same behavior I don't agree w/ this.

John

Sent from my iPhone

On Mar 21, 2018, at 10:16 PM, Satya Mohanty (satyamoh) 
<satya...@cisco.com<mailto:satya...@cisco.com>> wrote:

We will take the feedback and revise the next version with the EVPN GW case as 
the primary use case.
Also, we will make it informational.

I need to make a mention again of what I spoke at the mic because I think it 
may not have been clear to everyone.
In the DF election framework draft, the weight is now a function of  the 
tuple(vlan, Esid, PE’s IP).
If we set the Esid to 0, then as long as each ES has the exact same set if 
vlans, the carving of vlans by the algorithm is the same.

Thanks,
—Satya

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>
Date: Wednesday, March 21, 2018 at 6:27 PM
To: Sandy Breeze <sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Sandy,

The key point in here is that the proposal is intended for EVPN GWs (and not 
PEs). By talking about PEs and NVEs at BESS yesterday, lot of people got 
confused. Although for EVPN GWs, this proposal makes better sense, for EVPN 
PEs, it doesn’t much because:

  1.  Vast majority (if not all) of TORs/PEs multi-homing are dual-homing which 
gives us zero benefit
  2.  Even for multi-homing with >2 PEs in the redundancy group, the chances of 
a PE not becoming a DF across all ES's in a BD is extremely low. We need to 
keep in mind that number of ES's are much larger than number of PEs !! And HRW 
algorithm in our df-framework draft takes into account the ES-id in its hash 
algorithm which means for the same BD, different PEs can become DF for 
different ES's !!
3) As soon as there is a stub node (e.g., a single-home CE) connected to any 
PE, then all bets are off and that PE needs to send IMET route and receive 
mcast traffic
4) As soon as there is a link/ES failure, then we will end-up with (3) above 
for dual-homing scenario and the PE with active link needs to send IMET route 
and receive mcast traffic
5) For mcast flow (*,G) or (S,G), the solution described in igmp-proxy draft  
is the most optimal

So, I would suggest to do the following:

  1.  In the problem statement of the draft, capture the below use case clearly.
  2.  Change the name of the draft to “bum optimization for EVPN gateways”
  3.  Capture briefly why the proposal is not intended for EVPN PEs/NVEs 
because of the above reasons.

Cheers,
Ali

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
Sandy Breeze <sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>
Date: Wednesday, March 21, 2018 at 8:58 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem 
description

After some discussion, we acknowledge the problem description needs further 
clarification for this not to become too specific a use case.  Consider the 
following example of our existing live deployments;




The main points to articulate here are;

  *   PE[1..4] are at the boundary of an EVPN/MPLS domain (core side) and an 
EVPN/VXLAN domain (datacentre fabric side)
  *   They are responsible for L2VNI VTEP from ToR and MPLS L2VPN in core.
  *   From their point of view, 1 BD = 1 L2VNI (=1 ES).
  *   For any given DF type (modulo/HRW/etc) they distribute DF’s per-ES 
between them.
  *   Therefore, all nDF PE’s attract BUM for ES’s they’re not allowed to 
forward on and hence the waste of bandwidth in the EVPN core and cycles.

In our case, the solution

Re: [bess] New bess WG Co-Chair

[Satya Mohanty (satyamoh)]

Second that.
Thanks Martin for all the work that you undertook while being chair.

Best Regards,
—Satya

From: BESS > on behalf of 
"Ali Sajassi (sajassi)" >
Date: Tuesday, February 13, 2018 at 9:27 AM
To: Alvaro Retana >, 
"bess@ietf.org" >
Subject: Re: [bess] New bess WG Co-Chair


Martin, thank you for all your work and efforts for this WG and reviewing/ 
shepherding many drafts.

Matthew, welcome to BESS.

Cheers,
Ali

From: BESS > on behalf of 
Alvaro Retana >
Date: Tuesday, February 13, 2018 at 8:11 AM
To: "bess@ietf.org" >
Subject: [bess] New bess WG Co-Chair

Dear bess WG:

As you know, Martin has been selected as a Routing AD starting next month at 
IETF 101 in London.  As a result, he will be stepping down as bess co-chair.  
Martin: thank you for all the work and time you have dedicated to the WG — we 
all look forward to working with you in your new role.  Congratulations!

In consultation with Stephane and the other ADs, we have asked Matthew Bocci to 
take on the role of bess Co-Chair.  Matthew is an experienced Chair (he is also 
the Co-Chair of nvo3, and has served in other WGs) and has been participating 
in the IETF for over a decade.

I am adding Matthew as a third Chair to facilitate the transition.  The 
expectation is that he will fully take over for Martin at IETF 101.  Welcome 
Matthew!

Matthew can be reached at 
matthew.bo...@nokia.com.

Thanks!

Alvaro.

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

Re: [bess] WG Last Call (including implem status) for draft-ietf-bess-evpn-ac-df

[Satya Mohanty (satyamoh)]

Yes, this will be consistent with the existing framework.

Thanks,
—Satya

From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Wednesday, January 31, 2018 at 12:55 AM
To: "jdr...@juniper.net" 
>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" >, 
"Van De Velde, Gunter (Nokia - BE/Antwerp)" 
>, 
"bess@ietf.org" >, 
"draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
 
>
Subject: Re: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df

Hi John,

Speaking as doc shepherd for the ac-df draft, I agree that this make sense and 
this will provide more backward compatibility with the behavior defined in 
RFC7432.

Brgds,

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Tuesday, January 30, 2018 17:17
To: Rabadan, Jorge (Nokia - US/Mountain View); Van De Velde, Gunter (Nokia - 
BE/Antwerp); LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Subject: RE: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df

Hi,

The HRW DF election draft defines a new extended community, the DF Election 
Extended Community 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-03#section-7), 
which contains a DF election type registry.  Why don’t we define a value for 
AC-based DF election and have the PEs supporting it advertise the extended 
community w/ that value and either  include a normative reference to the HRW 
draft or move the extended community and the text describing its usage to the 
AC-based election draft?

Yours Irrespectively,

John

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Tuesday, January 30, 2018 10:28 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
>; 
stephane.litkow...@orange.com; 
bess@ietf.org; 
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Subject: Re: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df

Hi Gunter,

Thanks for the feedback.
About this:
I was wondering why this document, even though being backward compatible with 
RFC7432, is Informational track, and not standard track.

I just sent an email providing the initial reasoning discussed among the 
authors. If we still think Standards Track is more appropriate, I think it is 
ok to change it.

Thank you.
Jorge



From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
>
Date: Tuesday, January 30, 2018 at 10:46 AM
To: "stephane.litkow...@orange.com" 
>, 
"bess@ietf.org" >, 
"draft-ietf-bess-evpn-ac-df.auth...@ietf.org"
 
>
Subject: RE: [bess] WG Last Call (including implem status) for 
draft-ietf-bess-evpn-ac-df
Resent-From: >
Resent-To: >, 
>, 
>, 
>, 
>, 
>
Resent-Date: Tuesday, January 30, 2018 at 10:46 AM

I support progress and publish as RFC.

The document is well written and resolves with a reasonable approach logical 
failures or human errors, that would otherwise result in significant service 
problems.
I was wondering why this document, eventhough being backward compatible with 
RFC7432, is Informational track, and not standard track.

G/

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, January 29, 2018 09:27
To: bess@ietf.org; 
draft-ietf-bess-evpn-ac-df.auth...@ietf.org
Subject: [bess] WG Last Call (including implem status) for 

Re: [bess] Call for adoption: draft-drake-bess-datacenter-gateway

[Satya Mohanty (satyamoh)]

Support for adoption.

Thanks,
—Satya




On 9/25/17, 3:11 AM, "BESS on behalf of Martin Vigoureux" 
 wrote:

>I meant the 9th of October, sorry.
>
>Le 25/09/2017 à 11:42, Martin Vigoureux a écrit :
>> Hello working group,
>>
>> This email starts a two-week call for adoption on
>> draft-drake-bess-datacenter-gateway-05 [1] as a BESS Working Group
>> Document.
>>
>> Please state on the list if you support the adoption or not (in both
>> cases, please also state the reasons).
>>
>> This poll runs until *the 2nd of 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.
>>
>> Currently no IPR has been disclosed 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.
>>
>> Thank you
>>
>> Martin & Thomas
>> bess chairs
>>
>> [1] https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/
>>
>> ___
>> 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 for draft-ietf-bess-fat-pw-bgp

[Satya Mohanty (satyamoh)]

Support.

Thanks,
—Satya




On 6/12/17, 9:27 AM, "BESS on behalf of Martin Vigoureux" 
 wrote:

>Hello Working Group,
>
>This email starts a Working Group Last Call on 
>draft-ietf-bess-fat-pw-bgp-02 [1] which is considered mature and ready 
>for a final working group review.
>
>¤ Please read this document if you haven't read the most recent
>version yet, and send your comments to the list, no later than
>*26th of June*.
>Note that this is *not only* a call for comments on the document; it is 
>also a call for support (or not) to publish this document as a Proposed 
>Standard RFC.
>
>¤ *Coincidentally*, we are also polling for knowledge of any IPR that 
>applies to draft-ietf-bess-fat-pw-bgp, 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 a document Author or Contributor of
>draft-ietf-bess-fat-pw-bgp-02 please respond to this email and indicate 
>whether or not you are aware of any relevant IPR.
>
>Note that, as of today, no IPR has been disclosed against this document 
>or its earlier versions.
>
>¤ We are also polling for knowledge of implementations of part or all of 
>what this document specifies. This information is expected as per [2]. 
>Please inform the mailing list, or the chairs, or only one of the chairs.
>
>
>Thank you,
>M
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-fat-pw-bgp/
>[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] Call for adoption: draft-rabadan-bess-evpn-pref-df

[Satya Mohanty (satyamoh)]

Support as co-author.
I am not aware of any IPR related to the draft.

Thanks,
—Satya




On 6/6/17, 6:44 AM, "thomas.mo...@orange.com"  wrote:

>Hello working group,
>
>This email starts a two-week call for adoption on
>draft-rabadan-bess-evpn-pref-df-02 [1] as a Working Group Document.
>
>Please state on the list if you support the adoption or not (in both 
>cases, please also state the reasons).
>
>This poll runs until *the 20th 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 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.
>
>If you are not listed as an Author or Contributor, then please 
>explicitly respond only if you are aware of any IPR that has not yet 
>been disclosed in conformance with IETF rules.
>
>Thank you,
>
>Martin & Thomas
>bess chairs
>
>[1] https://datatracker.ietf.org/doc/draft-rabadan-bess-evpn-pref-df/
>
>_
>
>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] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03

[Satya Mohanty (satyamoh)]

Support.



Thanks,
—Satya

>
>On 2/13/17, 11:07 PM, "BESS on behalf of Martin Vigoureux" 
> wrote:
>
>Hello Working Group,
>
>This email starts a Working Group Last Call on 
>draft-ietf-bess-evpn-inter-subnet-forwarding-03 [1] which is considered 
>mature and ready for a final working group review.
>Note that this call is longer than usual because we are pushing two 
>correlated documents together.
>
>Please read this document if you haven't read the most recent
>version yet, and send your comments to the list, no later than
>*5th of March*.
>Note that this is *not only* a call for comments on the document; it is 
>also a call for support (or not) to publish this document as a Proposed 
>Standard RFC.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that 
>applies to draft-ietf-bess-evpn-inter-subnet-forwarding, 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 a document author or contributor of
>draft-ietf-bess-evpn-inter-subnet-forwarding-03 please respond to this 
>email and indicate whether or not you are aware of any relevant IPR.
>
>Note that, as of today, no IPR has been disclosed against this document 
>or its earlier versions.
>
>We are also polling for knowledge of implementations of part or all of 
>what this document specifies. This information is expected as per [2]. 
>Please inform the mailing list, or the chairs, or only one of the chairs.
>
>Thank you,
>M
>
>[1] 
>
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/
>[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 (including implem status & shepherd) for draft-ietf-bess-evpn-overlay

[Satya Mohanty (satyamoh)]

Support.

Thanks,
—Satya




>
>> -Original Message-
>> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
>> thomas.mo...@orange.com
>> Sent: Monday, June 13, 2016 5:26 AM
>> To: BESS 
>> Cc: draft-ietf-bess-evpn-over...@tools.ietf.org
>> Subject: [bess] WG Last Call (including implem status & shepherd) for 
>> draft-ietf-bess-evpn-overlay
>> 
>> Hello Working Group,
>> 
>> (Please read carefully, this e-mail contains new elements compared to WG
>> LCs we were doing in a still recent past.)
>> 
>> This email starts a Working Group Last Call on
>> draft-ietf-bess-evpn-overlay [1].
>> 
>> * Please read the document if you haven't read the most recent
>> version yet, and send your comments to the list, no later than
>> *27th of June*.
>> 
>> Note that this is *not only* a call for comments on the document, but
>> also a call for support (or not) publishing this document as a Proposed
>> Standard RFC.
>> 
>> * We are also polling for knowledge of any undisclosed IPR that applies
>> to draft-ietf-bess-evpn-overlay-04, to ensure that IPR has been
>> disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669
>> and 5378 for more details) prior to moving forward.
>> If you are listed as a document Author or Contributor of
>> this document please respond to this email and indicate whether or not
>> you are aware of any relevant undisclosed IPR. The document won't
>> progress without answers from all the Authors and Contributors.
>> 
>> * We are also polling for knowledge of implementations of part or all of
>> what this document specifies. This information is expected as per [2].
>> Please inform the mailing list, the chairs, or only one of the chairs.
>> 
>> * Finally, if you want to volunteer to be Document Shepherd for this
>> document, please let us know.
>> 
>> Thank you,
>> 
>> Thomas/Martin
>> 
>> 
>> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay
>> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>> 
>> 
>> _
>> 
>> 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 on draft-ietf-bess-evpn-etree

[Satya Mohanty (satyamoh)]

Support publication of this draft.
It is a good document for the Etree framework to EVPN.

Thanks,
―Satya

On 1/24/16, 9:40 PM, "BESS on behalf of Ali Sajassi (sajassi)"
 wrote:

>
>Support publication of this document as a co-author and I am not aware of
>any IPR that hasn¹t been disclosed.
>
>Cheers,
>Ali
>
>On 1/19/16, 12:51 AM, "BESS on behalf of thomas.mo...@orange.com"
> wrote:
>
>>Hello Working Group,
>>
>>This email starts a Working Group Last Call on
>>draft-ietf-bess-evpn-etree [1] which is considered mature and ready for
>>a final working group review.
>>
>>Please read the document if you haven't read the most recent version yet
>>(-03), and send your comments to the list, no later than *February the
>>2nd* (2016-02-02).
>>
>>This is not only a call for comments on the document, but also a call of
>>support for its publication.
>>
>>*Coincidentally*, we are also polling for knowledge of any IPR that
>>applies to draft-ietf-bess-evpn-etree, 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 a document author or contributor of
>>draft-ietf-bess-evpn-etree please respond to this email and indicate
>>whether or not you are aware of any relevant IPR.
>>
>>Thank you,
>>
>>Thomas/Martin
>>
>>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree
>>
>>___
>>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] Poll for adoption: draft-mohanty-bess-evpn-df-election-02

[Satya Mohanty (satyamoh)]

I¹m not aware of any IPR related to the draft.

Thanks,
‹Satya

On 1/11/16, 1:07 AM, "BESS on behalf of Martin Vigoureux"

wrote:

>Hello working group,
>
>This email starts a two-week poll on adopting
>draft-mohanty-bess-evpn-df-election-02 [1] as a working group item.
>
>Please state on the list if you support adoption or not (in the both
>cases, please also state the reasons).
>
>This poll runs until *the 25th of January*.
>
>Currently no IPR has been disclosed against this document.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that
>applies to this draft, 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 a document author or contributor please
>respond to this email and indicate whether or not you are aware of any
>relevant IPR.
>
>The draft will not be adopted until a response has been received from
>each author and contributor.
>
>If you are not listed as an author or contributor, then please
>explicitly respond only if you are aware of any IPR that has not yet
>been disclosed in conformance with IETF rules.
>
>Thank you,
>
>Martin & Thomas
>bess chairs
>
>[1] https://datatracker.ietf.org/doc/draft-mohanty-bess-evpn-df-election/
>
>___
>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] REG: draft-mohanty-bess-evpn-df-election-02

[Satya Mohanty (satyamoh)]

Hi Kishore/Sudhin,

From: Kishore Tiruveedhula >
Date: Tuesday, November 24, 2015 12:42 PM
To: smohanty mohanty >, "Patrice 
Brissette (pbrisset)" >, sudeep g 
ggg >, 
"bess@ietf.org" >
Subject: Re: [bess] REG: draft-mohanty-bess-evpn-df-election-02

 Please see below inline...[Kishore].

1. When a new PE comes in the MH segment.
[Satya] Yes, New PE needs to wait for 3 sec. According to RFC 7438, the 
receiving PEs also need to wait for 3 secs. But, ideally, a PE that is going 
from DF to non-DF or non-DF to non-DF should become the non-DF rightaway. Only 
the PE that is going DF really needs to wait for 3 secs. This is not explicitly 
spelled out in the draft but we are thinking along these lines.

[Kishore]  Yes. The new PE need to wait for 3 seconds, but if new PE receives 
the type 4 route from the redundant PE before 3 seconds, the new PE can just 
move to DF immediately (if it becomes DF) just after receiving the type 4 
without waiting for the 3 seconds timer expiry because the other redundant PE 
might have moved to Non-DF as there is no 3 seconds timer on the other PE which 
is moving from DF to Non-DF.
It is good idea to explicitly spell out this in this draft.
[Satya] Right. We will spell this out in the next version.


[Satya] Now, delay of BGP updates is not dependent on the above behavior. That 
depends on the network topology and queueing/processing at intermediate nodes.
With HRW,  a PE coming up will result in minimal disruption of the established 
DF for various vlans (bundles) as opposed to RFC 7438 mod-based.

[Kishore] If the BGP update processing takes more time on one PE and receives 
less time from RR on the other PE, then it may be possible of both PE may 
become DF or Non-DF, so the timer value should be chosen large enough in this 
case.
[Satya] The problem is there is no "cure-all" timer value that will guarantee 
this behavior.
There was a ack based draft sometime back, but it would have introduced 
considerable overhead that caused complications.

Thanks,
Kishore

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

Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

[Satya Mohanty (satyamoh)]

Also, as in the private communication, I don’t really see any mac flip-flop 
issue as we are considering the same ESI.
It is NOT equivalent to the mac-mobility.

Thanks,
--Satya

From: jdr...@juniper.netmailto:jdr...@juniper.net 
jdr...@juniper.netmailto:jdr...@juniper.net
Date: Tuesday, April 7, 2015 6:53 AM
To: Haoweiguo haowei...@huawei.commailto:haowei...@huawei.com, Patrice 
Brissette (pbrisset) pbris...@cisco.commailto:pbris...@cisco.com
Cc: Ali Sajassi (sajassi) saja...@cisco.commailto:saja...@cisco.com, 
bess@ietf.orgmailto:bess@ietf.org bess@ietf.orgmailto:bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Weiguo,

Snipped, comments inline.

Yours Irrespectively,

John

From: Haoweiguo [mailto:haowei...@huawei.com]
Sent: Monday, April 06, 2015 10:03 PM
To: John E Drake; Patrice Brissette (pbrisset)
Cc: Ali Sajassi (sajassi); bess@ietf.orgmailto:bess@ietf.org
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm


Hi John,

Your summary is good. Pls see my further reply inline with [weiguo].

Thanks,

weiguo


From: John E Drake [jdr...@juniper.netmailto:jdr...@juniper.net]
Sent: Friday, April 03, 2015 21:38
To: Haoweiguo; Patrice Brissette (pbrisset)
Cc: Ali Sajassi (sajassi); bess@ietf.orgmailto:bess@ietf.org
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm
Weiguo,

I have been marginally paying attention to this email thread and I thought I 
should update the points we have established.  In addition to the points listed 
in my email, below, I think we have established that;

1)  Your proposal is even more broken than I I previously indicated because you 
have no way to identify to which EVI your DF election handshake applies
[weiguo]: Firstly we had better reach consensus on the problem(Loop and MAC 
flip-flop in transient peirod for MHN) that we are trying to resolve, then we 
can search for the suitable solution. The current proposed solution is to use 
A-D route for handshaking, the A-D route can identify EVI.

[JD]  I don’t think there is a problem to be solved, so the first order of 
business is for you to write a draft clearly articulating the problems you 
perceive and their ramifications.  Please keep in mind that single-active, and 
more specifically single-active MHN, is not where I think we should focus our 
resources.  DCI, for example, uses all-active.

Further, as I had previously pointed out, we can’t use an EVPN route that goes 
to all PEs so the Per EVI Ethernet AD route can’t be used.

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

[bess] Request for WG adoption of draft-mohanty-bess-evpn-df-election

[Satya Mohanty (satyamoh)]

Hi,

Given the interest and technical discussions on the topic of the EVPN DF
Election, and the favorable response of the community to the benefits of
the HRW scheme, I would like to request the WG to adopt
draft-mohanty-bess-evpn-df-election.

Thanks to Jakob Heitz for presentation of slides at the IETF.

Best regards,
--Satya

On 3/27/15 8:52 PM, Rabadan, Jorge (Jorge)
jorge.raba...@alcatel-lucent.com wrote:

Hi Thomas,

You are right.

Kishore, Weiguo and I were discussing face-to-face the scenario drawn by
Weiguo below. And my conclusion is that there is no loop and there is
nothing new that it was not discussed in this thread. EVPN single-active
and split-horizon procedures take care of loops. If there are transient
DF-DF periods, you can get some duplicate packets, but not infinite loops.
And an implementation should allow a configurable timer that can be
adjusted to the scale of the network so that the dual DF transient risk
can be minimized or eliminated.

About why all-active is not supported in the scenario below, I agree with
your reasoning. RFC7432 only accepts LAG for all-active, since, otherwise,
duplicate packets could be forwarded in normal state.
draft-ietf-bess-dci-evpn-overlay-00 proposes an all-active MH network
solution, but that is because EVPN runs in the access network too.

Thanks.
Jorge

-Original Message-
From: thomas.mo...@orange.com thomas.mo...@orange.com
Organization: Orange
Date: Friday, March 27, 2015 at 4:08 PM
To: Jorge Rabadan jorge.raba...@alcatel-lucent.com, Haoweiguo
haowei...@huawei.com, Satya Mohanty (satyamoh) satya...@cisco.com,
bess@ietf.org bess@ietf.org
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Jorge,

Jorge:
 If you have any other scenario, let’s talk offline. We are boring
people
 ;-)

I think its nice to keep the discussion on the list, which is here for a
reason (that is, not just for polls for adoption and WG last calls...).

I'm sure these clarifications can be useful for some of the
participants, and the others can very much skip the thread.

And there is, I think, perhaps one more thing worth spelling out.

RFC7432 explains that for multi-homing in active-active mode, LAG is
required.
My understanding of the reason why, in this case, it is not supported to
connect the bridged
network via multiple CEs is that there is no technique to build a LAG
between two CEs and two PEs.

Best,

-Thomas



Rabadan, Jorge :
 As I said:
 Even if CE3 forwards to CE4-PE4, PE4 is NDF and will discard the
frame.
 Remember MH network ES' as per your diagram below, only support
 single-active MH.”

 So there is NO LOOP.




 Thanks.
 Jorge

 -Original Message-
 From: Haoweiguo haowei...@huawei.com
 Date: Friday, March 27, 2015 at 9:00 AM
 To: Jorge Rabadan jorge.raba...@alcatel-lucent.com, Satya Mohanty
 (satyamoh) satya...@cisco.com, thomas.mo...@orange.com
 thomas.mo...@orange.com, bess@ietf.org bess@ietf.org
 Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
 algorithm

 Hi Jorge,
 The picture in email is just for a simplified explanation. Source MAC
can
 be the layer 3 device connecting to CE3, CE3 will not drop the frame
so
 easily. This is an absolutely loop.

 Thanks,
 weiguo

 
 From: Rabadan, Jorge (Jorge) [jorge.raba...@alcatel-lucent.com]
 Sent: Friday, March 27, 2015 23:39
 To: Haoweiguo; Satya Mohanty (satyamoh); thomas.mo...@orange.com;
 bess@ietf.org
 Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
 algorithm

 Hi Weiguo,

 I disagree with your explanation below.

 This is the flow assuming PE1-PE2 *might* be both DF and PE3 is DF:

 CE3---PE3--PE2---CE2CE1PE1PE3--CE3――DROP

 If the MAC SA of the frame is CE3’s MAC, CE3 will discard.
 Even if CE3 forwards to CE4-PE4, PE4 is NDF and will discard the
frame.
 Remember MH network ES' as per your diagram below, only support
 single-active MH.


 Thanks.
 Jorge

 -Original Message-
 From: Haoweiguo haowei...@huawei.com
 Date: Friday, March 27, 2015 at 8:11 AM
 To: Jorge Rabadan jorge.raba...@alcatel-lucent.com, Satya Mohanty
 (satyamoh) satya...@cisco.com, thomas.mo...@orange.com
 thomas.mo...@orange.com, bess@ietf.org bess@ietf.org
 Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos
 algorithm

 Hi Jorge,
 Let give you another indefinitely forwarding loop case, the picture
is as
 follows:

 CE3CE4
   ||
 PE3   PE4



 PE1   PE2
 | |
 CE1CE2

 If PE1 and PE2 are dual DF PE in transiet time, assuing PE3 and PE4
are
 in stable state ,PE3 is DF PE, PE4 is non-DF PE, the BUM traffic from
CE3
 to CE1, the forwarding loop path is as follows;
 
CE3---PE3--PE2---CE2CE1PE1PE3--CE3--CE4---PE4
-
--
 -
 forever..
 Do you think the harm is enough?
 Thanks,
 weiguo
 
 From: Rabadan

Re: [bess] New Version Notification for draft-mohanty-bess-evpn-df-election-00.txt

[Satya Mohanty (satyamoh)]

FYI, below is the updated draft, with the corrected name from L2VPN to BESS.
[was previously draft-mohanty-l2vpn-evpn-df-election-00]

Also, the actual hash function is clarified here.

Thanks,
--Satya

On 3/9/15 3:38 PM, internet-dra...@ietf.orgmailto:internet-dra...@ietf.org 
internet-dra...@ietf.orgmailto:internet-dra...@ietf.org wrote:


A new version of I-D, draft-mohanty-bess-evpn-df-election-00.txt
has been successfully submitted by Satya Ranjan Mohanty and posted to the
IETF repository.

Name: draft-mohanty-bess-evpn-df-election
Revision: 00
Title: A new Designated Forwarder Election for the EVPN
Document date: 2015-03-07
Group: Individual Submission
Pages: 11
URL:
http://www.ietf.org/internet-drafts/draft-mohanty-bess-evpn-df-election-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-mohanty-bess-evpn-df-election/
Htmlized:   
http://tools.ietf.org/html/draft-mohanty-bess-evpn-df-election-00


Abstract:
   This document describes an improved EVPN Designated Forwarder
   Election (DF) algorithm which can be used to enhance operational
   experience in terms of convergence speed and robustness over a WAN
   deploying EVPN




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

Re: [bess] EVPN Draft Comments

[Satya Mohanty (satyamoh)]

On 2/2/15 5:42 AM, Russ White ru...@riw.usmailto:ru...@riw.us wrote:

Y'all:

I know this is in auth-48 (or maybe past), but I've been through these docs
a number of times, and still come up with questions that I think need to be
addressed/answered at some point. In general, eVPN seems to be on the
receiving end of I can imagine a lot of different use cases, some of which
are self-contradictory, but let's just throw it all in the bucket anyway,

:::;


==
8.5

In step 3 of DF election, the list of IP addresses is ordered in increasing
numeric value. What if you have a mix of v4 and v6 addresses?

[Satya] One possible solution may be to do a lexicographic comparison of keys 
(the iP address strings in this case considered as sequence of bytes).
For unequal-length keys like in the case of v4 and v6, assume that a unique 
'padding' alphabet is present after the v4 address that always has priority  
over other alphabets (byte values).
This will make the comparison non-ambiguous, and still the same algorithm 
suffices.



==

:-)

Russ

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

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

Re: [bess] EVPN Draft Comments

[Satya Mohanty (satyamoh)]

On 2/2/15 4:16 PM, Russ White ru...@riw.usmailto:ru...@riw.us wrote:


In step 3 of DF election, the list of IP addresses is ordered in
increasing
numeric value. What if you have a mix of v4 and v6 addresses?
[Satya] One possible solution may be to do a lexicographic comparison of
keys (the iP address strings in this case considered as sequence of
bytes).
For unequal-length keys like in the case of v4 and v6, assume that a
unique
'padding' alphabet is present after the v4 address that always has
priority
over other alphabets (byte values).
This will make the comparison non-ambiguous, and still the same algorithm
suffices.

Would you want a different DF for v4 and v6 devices? Maybe no -- because
this is layer 2 forwarding, but maybe yes. If the answer is no, then this
should be documented, I think, even if it's in a different doc.

[Satya] I believe a different DF for v4 and v6 is unnecessary (this is layer 2 
forwarding as you pointed out, and I wrote the above keeping that in mind). The 
above method should work and can be documented (to remove unambiguity).
FYI, it may help to know there are other DF election procedures that are being 
worked on that are provably more robust, and do not have the problem discussed 
here.


:-)

Russ


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