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

[Neeraj Malhotra]

Hi,

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

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

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

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

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


Thanks,

Neeraj


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

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

Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

[Jeffrey (Zhaohui) Zhang]

Hi Jingrong,

Allocating a special label from the 0~15 block is super difficult. I don't 
think our use case is strong enough for that.

Thanks.
Jeffrey

From: Xiejingrong 
Sent: Sunday, December 16, 2018 11:02 PM
To: Jeffrey (Zhaohui) Zhang ; 
stephane.litkow...@orange..com; bess@ietf.org
Subject: RE: Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Thanks for clarifying that there is nothing special on data-plane comparing to 
the Upstream-assigned label following a P2MP label as mentioned in RFC6513. It 
help me much.

About the case (maybe the worst case) when it is difficult to allocate a 
'domain-wide unique' DCB-context-label,
do you think it helpful for an allocation of 'reserved' label (value from 0 to 
15) to represent a 'Context-label' to make the interoperability mandatory ?

Jingrong


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

Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

[stephane.litkowski]

Hi,

This poll is closed now.
It seems that some discussions are required on the document, however it has 
been confirmed that nothing blocks the early allocation request.
I'm requesting the approval from our AD now.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, December 11, 2018 16:10
To: bess@ietf.org
Subject: [bess] Poll for early allocation request for 
draft-ietf-bess-mvpn-evpn-aggregation-label

Hi WG,

We have received an early allocation request for the 
draft-ietf-bess-mvpn-evpn-aggregation-label.

Please raise your concerns if you object to this request and if you think that 
the document is not mature enough.
Feel also free to support this request.

We will wait until next Monday (12/17) to gather feedbacks.

Thanks,

Stephane



_



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.

_

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] BESS Wiki draft

[stephane.litkowski]

Hi WG,

I have started to build a Wiki page for the BESS WG which gives a detailed 
status of the working group work.
https://trac.ietf.org/trac/bess/wiki/WikiStart

It is still a draft and I would be pleased to welcome your feedback on it on 
the shape as well as the content.

The WG document status section is almost empty now, but will be enriched with 
the expected regular reports (next occurrence being mid-January) from the 
editors.


Brgds,

Stephane



_

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] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-virtual-eth-segment

[richard . schell=40verizon . com]

Hello,
I am not aware of any relevant undisclosed IPR for this item.


Regards
Rick Schell
214-202-3464

___
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-virtual-eth-segment

[stephane.litkowski]

Hi,

The WGLC poll is now ended.
We have one comment from Mankamana that requires a reply from the authors.

We are also missing an IPR reply from Richard Schnell from Verizon.

We can't proceed before clearing these two points.

Brgds,

Stephane



From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, December 03, 2018 11:43
To: bess@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-virtual-eth-segment


Hello Working Group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-virtual-eth-segment [1]



This poll runs until *the 17th of December*.



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-virtual-eth-segment/



[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.

_

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.

--- Begin Message ---
Support.





But I would be happy to see some changes if WG / Author agree to it.



Nits:

1.  Please move abstract to the top. It would be easy for readers.
2.  It might be good to add a line to describe I-SID in terminology section






3.2.
 Scalability




   (R2a) A PE MUST handle thousands or tens of thousands of Single-homed
   vES's on a single physical port (e.g., single ENNI)


Comment: These section provides number “thousands or ten thousands”. As a 
standard document, I think we can avoid using some hard code numbers.

Would it be more appropriate to say “A PE MUST handle multiple Single-homed 
vES’s

on a single physical port (e.g., single ENNI)



   (R2b) A PE MUST handle hundreds of Single-Active vES's on a single
   physical port (e.g., single ENNI)
Comment: Same as above

   (R2c) A PE MAY handle tens or hundreds of All-Active Multi-Homed
   vES's on a single physical port (e.g., single ENNI)
Comment: Same as above






Thanks

Mankamana





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

Date: Monday, December 3, 2018 at 2:43 AM
To: "bess@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-virtual-eth-segment



Hello Working Group,



This 

[bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-bum-procedure-updates

[stephane.litkowski]

Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-bum-procedure-updates [1]. The poll period is longer than 
usual due to the coming vacation period.



This poll runs until *the 7th of January*.



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-bum-procedure-updates/



[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