Subject: Re: [bess] PLEASE LOOK: minor change to draft-ietf-bess-evpn-df-election-framework-05 => two weeks poll to get feedback

From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 4 Dec 2018 18:44:30 +0000

WG,

I have asked the authors to submit a new revision with the new text.
I know this is before the end of this additional review period but I 
wanted to have a (thin) chance to get this on the last IESG telechat of 
2018.
The draft is moving to IETF LC so you still have the opportunity to 
express your opinions on the recent change.

-m

Le 2018-11-21 à 10:08, [email-masked] a écrit :
> Hi Ali,
> 
> Thanks a lot for your email.
> 
> Speaking as chair, could you please highlight to the working group the 
> rationale of the change and associated use case ? Just to give the context…
> 
> To WG Folks,
> 
> Please review this change with care. There are two points that I would 
> like to highlight:
> 
> -We need to ensure that there is no current implementation using the 
> value 255. Please raise your voice if you are aware of one.
> 
> -The encoding of the mcast DF election algorithm could now be 
> decorrelated from the base DF alg (applicable to Broadcast and Unknown 
> traffic). The proposed encoding uses 3 bits for the mcast DF alg. We 
> have to ensure that:
> 
> o3 bits is enough
> 
> oThere will “never” (at least not mid term) be a requirement for 
> variable parameters for mcast DF election (like in DF pref draft).
> 
> I will let some time to think about this change and raise your support 
> or concerns.
> 
> The poll starts now and will end on Dec 5^th .
> 
> This DF election framework will be an important component of EVPN and we 
> need to ensure that we are providing the required level of flexibility 
> to address the different use cases.
> 
> Thanks !
> 
> *From:*Ali Sajassi (sajassi) [mailto:[email-masked]]
> *Sent:* Wednesday, November 21, 2018 00:25
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* minor change to draft-ietf-bess-evpn-df-election-framework-05
> 
> Folks,
> 
> The authors of  the above draft are purposing a minor change to the 
> draft and since the draft is currently under review by IESG, the chair 
> has asked to send an email to the WG to solicit inputs and ensuring that 
> there is no objection. The proposed change is as follow:
> 
> Currently, the above draft defines an eight-bit “DF Alg” field as shown 
> in the following figure. The proposed change is to reduce the eight-bit 
> field to a five-bit field.
> 
> *** OLD Text
> 
>                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 
> 9 0 1
> 
>               
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>               | Type=0x06     | Sub-Type(0x06)|   DF Alg      |    
> Bitmap     |
> 
>               
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>               |     Bitmap    |            
> Reserved                           |
> 
>               
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     o DF Alg (1 octet) - Encodes the DF Election algorithm values
> 
>       (between 0 and 255) that the advertising PE desires to use for the
> 
>       ES. This document requests IANA to set up a registry called "DF Alg
> 
>       Registry" and solicits the following values:
> 
>       - Type 0: Default DF Election algorithm, or modulus-based algorithm
> 
>         as in [RFC7432 <https://tools.ietf.org/html/rfc7432>].
> 
>       - Type 1: HRW algorithm (explained in this document).
> 
>       - Types 2-254: Unassigned.
> 
>       - Type 255: Reserved for Experimental Use.
> 
> ***NEW Text
> 
>                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 
> 9 0 1
> 
>               
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>               | Type=0x06     | Sub-Type(0x06)| RSV |  DF Alg  |    
> Bitmap    |
> 
>               
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>               |     Bitmap    |            
> Reserved                           |
> 
>               
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     o DF Alg *(5 bits)* - Encodes the DF Election algorithm values
> 
> *(between 0 and 31)* that the advertising PE desires to use for the
> 
>       ES. This document requests IANA to set up a registry called "DF Alg
> 
>       Registry" and solicits the following values:
> 
>       - Type 0: Default DF Election algorithm, or modulus-based algorithm
> 
>         as in [RFC7432 <https://tools.ietf.org/html/rfc7432>].
> 
>       - Type 1: HRW algorithm (explained in this document).
> 
> *     - Types 2-30: Unassigned.*
> 
> **
> 
> *     - Type 31: Reserved for Experimental Use.*
> 
> **
> 
> **
> 
> The remaining 3-bits of that octet (bits 16, 17, and 18 in the above 
> figure) will be used by per-mcast-flow-df-election and will be expanded 
> and described there and will be discussed in the next IETF as usual at 
> the BESS WG session.
> 
> Regards,
> 
> Ali & other co-authors
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>