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

2018-05-24 Thread stephane.litkowski 
Ok thanks a lot for all the edits. The text is really good now.

Let me know when the next revision is ready, I will then push the button to 
send it to IESG.

Brgds,


From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Thursday, May 24, 2018 14:15
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-df-election-framework

Thank you Stephane. We’ll fix it for the next version.

Jorge

From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Thursday, May 24, 2018 at 2:03 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, 
"bess@ietf.org" <bess@ietf.org>, 
"draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org" 
<draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org>
Subject: RE: Shepherd's review of draft-ietf-bess-df-election-framework

One small comment:

“this document
   elects a DF per <ES, BD>. This means that unlike [RFC 
7432<https://tools.ietf.org/html/rfc7432>],”

s/RFC 7432/RFC7432/

This creates a Nits


From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, May 23, 2018 21:36
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-df-election-framework

Stephane,

We have addressed all your comments in rev 02 (just posted). Please see below 
with [S](Satya & Jorge).

Thank you for your thorough review!
Satya & Jorge


From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Tuesday, April 24, 2018 at 11:04 AM
To: "bess@ietf.org" <bess@ietf.org>, 
"draft-ietf-bess-evpn-df-election-framework.auth...@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: <alias-boun...@ietf.org>
Resent-To: <jorge.raba...@nokia.com>, <satya...@cisco.com>, 
<saja...@cisco.com>, <jdr...@juniper.com>, <kiran.naga...@nokia.com>, 
<senthil.sathap...@nokia.com>
Resent-Date: Tuesday, April 24, 2018 at 11: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?
[S]The document includes the new text in RFC8174.





 (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
[S]fixed





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

 reference was found in the text
[S]fixed





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

 reference was found in the text
[S]fixed





  -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999'
[S]it's not an I.D




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.
[S]ok, done.


“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.
[S]ok, done.



“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 ad

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

2018-05-24 Thread Rabadan, Jorge (Nokia - US/Mountain View) 
Thank you Stephane. We’ll fix it for the next version.

Jorge

From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Thursday, May 24, 2018 at 2:03 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, 
"bess@ietf.org" <bess@ietf.org>, 
"draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org" 
<draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org>
Subject: RE: Shepherd's review of draft-ietf-bess-df-election-framework

One small comment:

“this document
   elects a DF per <ES, BD>. This means that unlike [RFC 
7432<https://tools.ietf.org/html/rfc7432>],”

s/RFC 7432/RFC7432/

This creates a Nits


From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, May 23, 2018 21:36
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-df-election-framework

Stephane,

We have addressed all your comments in rev 02 (just posted). Please see below 
with [S](Satya & Jorge).

Thank you for your thorough review!
Satya & Jorge


From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Tuesday, April 24, 2018 at 11:04 AM
To: "bess@ietf.org" <bess@ietf.org>, 
"draft-ietf-bess-evpn-df-election-framework.auth...@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: <alias-boun...@ietf.org>
Resent-To: <jorge.raba...@nokia.com>, <satya...@cisco.com>, 
<saja...@cisco.com>, <jdr...@juniper.com>, <kiran.naga...@nokia.com>, 
<senthil.sathap...@nokia.com>
Resent-Date: Tuesday, April 24, 2018 at 11: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?
[S]The document includes the new text in RFC8174.





 (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
[S]fixed





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

 reference was found in the text
[S]fixed





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

 reference was found in the text
[S]fixed





  -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999'
[S]it's not an I.D




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.
[S]ok, done.


“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.
[S]ok, done.



“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 ?
[S]ok, changed to:
These mechanisms do involve
   changes to the default DF Election algorithm, but they do not require
   any changes to the EVPN Route exchange and have minimal changes to
   their content per se.


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.
[S]added:
   In addition, there is a need to extend the DF

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

2018-05-24 Thread stephane.litkowski 
One small comment:

“this document
   elects a DF per <ES, BD>. This means that unlike [RFC 
7432<https://tools.ietf.org/html/rfc7432>],”

s/RFC 7432/RFC7432/

This creates a Nits


From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, May 23, 2018 21:36
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org; 
draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-df-election-framework

Stephane,

We have addressed all your comments in rev 02 (just posted). Please see below 
with [S](Satya & Jorge).

Thank you for your thorough review!
Satya & Jorge


From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Tuesday, April 24, 2018 at 11:04 AM
To: "bess@ietf.org" <bess@ietf.org>, 
"draft-ietf-bess-evpn-df-election-framework.auth...@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: <alias-boun...@ietf.org>
Resent-To: <jorge.raba...@nokia.com>, <satya...@cisco.com>, 
<saja...@cisco.com>, <jdr...@juniper.com>, <kiran.naga...@nokia.com>, 
<senthil.sathap...@nokia.com>
Resent-Date: Tuesday, April 24, 2018 at 11: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?
[S]The document includes the new text in RFC8174.





 (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
[S]fixed





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

 reference was found in the text
[S]fixed





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

 reference was found in the text
[S]fixed





  -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999'
[S]it's not an I.D




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.
[S]ok, done.


“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.
[S]ok, done.



“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 ?
[S]ok, changed to:
These mechanisms do involve
   changes to the default DF Election algorithm, but they do not require
   any changes to the EVPN Route exchange and have minimal changes to
   their content per se.


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.
[S]added:
   In addition, there is a need to extend the DF Election procedures so
   that new algorithms and capabilities are possible. A single algorithm
   (the default DF Election algorithm) may not meet the requirements in
   all the use-cases.


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” ?
[S]fixed now







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

  v1, v2 and v3 respectively.”

[SLI]

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

2018-05-23 Thread Rabadan, Jorge (Nokia - US/Mountain View) 
Stephane,

We have addressed all your comments in rev 02 (just posted). Please see below 
with [S](Satya & Jorge).
Thank you for your thorough review!
Satya & Jorge


From: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>
Date: Tuesday, April 24, 2018 at 11:04 AM
To: "bess@ietf.org" <bess@ietf.org>, 
"draft-ietf-bess-evpn-df-election-framework.auth...@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: <alias-boun...@ietf.org>
Resent-To: <jorge.raba...@nokia.com>, <satya...@cisco.com>, 
<saja...@cisco.com>, <jdr...@juniper.com>, <kiran.naga...@nokia.com>, 
<senthil.sathap...@nokia.com>
Resent-Date: Tuesday, April 24, 2018 at 11: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?
[S]The document includes the new text in RFC8174.





 (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
[S]fixed





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

 reference was found in the text
[S]fixed





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

 reference was found in the text
[S]fixed





  -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999'
[S]it's not an I.D




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.
[S]ok, done.


“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.
[S]ok, done.



“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 ?
[S]ok, changed to:
These mechanisms do involve
   changes to the default DF Election algorithm, but they do not require
   any changes to the EVPN Route exchange and have minimal changes to
   their content per se.


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.
[S]added:
   In addition, there is a need to extend the DF Election procedures so
   that new algorithms and capabilities are possible. A single algorithm
   (the default DF Election algorithm) may not meet the requirements in
   all the use-cases.


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” ?
[S]fixed now







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

  v1, v2 and v3 respectively.”

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



“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”

[S] We decided to change to this:

“One point to note is that the default DF election algorithm assumes that all 
the PEs who are multi-homed to the same Ethernet Segment (and interested in the 
DF Election by exchanging EVPN routes) use an Originati

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

2018-04-30 Thread Eric C Rosen 

On 4/30/2018 12:40 PM, Ali Sajassi (sajassi) wrote:

The DF type is an 8-bit type, so there can be a single valid value.


Sorry, for some reason I thought it was a set of flags.  My mistake ;-(

___
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

2018-04-30 Thread Rabadan, Jorge (Nokia - US/Mountain View) 
Eric,

Thank you for the comments.
Please see in-line.


-Original Message-
From: Eric C Rosen <ero...@juniper.net>
Date: Monday, April 30, 2018 at 7:46 AM
To: "Satya Mohanty (satyamoh)" <satya...@cisco.com>, 
"stephane.litkow...@orange.com" <stephane.litkow...@orange.com>, 
"bess@ietf.org" <bess@ietf.org>, 
"draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org" 
<draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org>
Subject: Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework
Resent-From: <alias-boun...@ietf.org>
Resent-To: <jorge.raba...@nokia.com>, <satya...@cisco.com>, 
<saja...@cisco.com>, <jdr...@juniper.com>, <kiran.naga...@nokia.com>, 
<senthil.sathap...@nokia.com>
Resent-Date: Monday, April 30, 2018 at 7:46 AM

Let me add a couple of minor comments:

- The draft should state the action to be taken when receiving a route 
that has more than one DF Election Extended Community.  I think the two 
possible options are "treat the route as if it did not have any DF 
Election Extended Community", and "treat-as-withdraw" (defined in RFC 
7606).

[JORGE] we are fixing that in the next rev. Satya can comment too, but we 
should treat this in the same way we are treating inconsistencies among the PEs 
in the ES, i.e. fall back to default DF Election. So that matches your "treat 
the route as if it did not have any DF Election Extended Community".


- The draft should state the action to be taken when receiving a route 
whose DF Election Extended Community has more than one DF Type bit set.  
I think the procedures in the draft assume that at most one DF Type bit 
is set, and may not work properly if multiple DF Type bits are set.

[JORGE] I assume you mean "more than one bit in the Bitmap set". The DF Type is 
a single 0-255 value. This draft sets up the registry and defines only one bit 
in the Bitmap. For that one we say it can be set or not. As far as this draft 
is concerned, the other bits have no meaning. New specs with different types of 
capabilities should clearly state if the new defined bit can be set along with 
existing capabilities and/or types. Stephane also made a comment similar to 
this and suggested something like this, that we are adding:

   o For any new capability defined in the future, the
 applicability/compatibility of this new capability to the existing
 DF types must be assessed on a per case by case basis.

   o Likewise, for any new DF type defined in future, its
 applicability/compatibility to the existing capabilities must be
 assessed on a per case by case basis.



___
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

2018-04-30 Thread Ali Sajassi (sajassi) 
Hi Eric,

On 4/30/18, 7:46 AM, "Eric C Rosen"  wrote:

Let me add a couple of minor comments:

- The draft should state the action to be taken when receiving a route 
that has more than one DF Election Extended Community.  I think the two 
possible options are "treat the route as if it did not have any DF 
Election Extended Community", and "treat-as-withdraw" (defined in RFC 
7606).

I think treating the route as if it didn't have any DF Election EC, would be 
preferable IMO because its action is consistent with other scenarios where 
there is ambiguity and no single DF type can be selected. 

- The draft should state the action to be taken when receiving a route 
whose DF Election Extended Community has more than one DF Type bit set.  
I think the procedures in the draft assume that at most one DF Type bit 
is set, and may not work properly if multiple DF Type bits are set.

The DF type is an 8-bit type, so there can be a single valid value. If you are 
talking about capability bits, then there a PE can have as many of them set as 
they can support.

Cheers,
Ali





___
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

2018-04-30 Thread Eric C Rosen 

Let me add a couple of minor comments:

- The draft should state the action to be taken when receiving a route 
that has more than one DF Election Extended Community.  I think the two 
possible options are "treat the route as if it did not have any DF 
Election Extended Community", and "treat-as-withdraw" (defined in RFC 
7606).


- The draft should state the action to be taken when receiving a route 
whose DF Election Extended Community has more than one DF Type bit set.  
I think the procedures in the draft assume that at most one DF Type bit 
is set, and may not work properly if multiple DF Type bits are set.




___
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

2018-04-27 Thread 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<mailto:stephane.litkow...@orange.com>" 
<stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>>
Date: Tuesday, April 24, 2018 at 2:03 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" 
<bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org<mailto:draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org>"
 
<draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org<mailto:draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org>>
Subject: Shepherd's review of draft-ietf-bess-df-election-framework
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, satyamoh 
<satya...@cisco.com<mailto:satya...@cisco.com>>, 
<saja...@cisco.com<mailto:saja...@cisco.com>>, 
<jdr...@juniper.com<mailto:jdr...@juniper.com>>, 
<kiran.naga...@nokia.com<mailto:kiran.naga...@nokia.com>>, 
<senthil.sathap...@nokia.com<mailto:senthil.sathap...@nokia.com>>
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

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

2018-04-24 Thread stephane.litkowski 
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 modifies the default DF Election procedure so that the

   ACS may be taken into account as a variable in the DF election, and

   therefore EVPN can provide protection against logical failures."



That's not completely true that the document modifies the default DF election.

I think it was true when the AC-DF was a single document but in the framework 
of this document the sense is a bit different as the AC-DF may influence any DF 
election type not only the default one.



I would propose to remove this paragraph as section 2.3 clarifies what the 
document is proposing.

Or modify for example as below:

"This document proposes an optional modification of the DF Election procedure 
so that the

   ACS may be taken into account as a variable in the DF election, and

   therefore EVPN can provide protection against logical failures."





Section 2.3:

I think section 2.3 requires some enhancements to better explain the DF 
election framework and not only focusing on the HRW and the AC-DF.





OLD

"In order to address those issues, this document

   describes a new DF Election algorithm and a new capability that can

   influence the DF Election result:"



NEW PROPOSAL:

"In order to address those issues, this document

   introduces a new DF Election framework. This DF election framework allows 
the PEs to agree on a DF election type to use as well as the