date:20180524

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 . This means that unlike [RFC 
7432],”

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&J](Satya & Jorge).

Thank you for your thorough review!
Satya & Jorge


From: "stephane.litkow...@orange.com" 
Date: Tuesday, April 24, 2018 at 11:04 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: , , 
, , , 

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&J]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&J]fixed





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

 reference was found in the text
[S&J]fixed





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

 reference was found in the text
[S&J]fixed





  -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999'
[S&J]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&J]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&J]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&J]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&J]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&J]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&J]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&J] We decided to change to this:

“One point to note is that the default DF election algorithm assumes that all 
the PE

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" 
Date: Thursday, May 24, 2018 at 2:03 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
"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

One small comment:

“this document
   elects a DF per . This means that unlike [RFC 
7432],”

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&J](Satya & Jorge).

Thank you for your thorough review!
Satya & Jorge

From: "stephane.litkow...@orange.com" 
Date: Tuesday, April 24, 2018 at 11:04 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: , , 
, , , 

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&J]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&J]fixed

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

 reference was found in the text
[S&J]fixed

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

 reference was found in the text
[S&J]fixed

  -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999'
[S&J]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&J]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&J]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&J]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&J]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&J]fixed now

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

  v1, v2 and v3 respectively.”

[SLI] Maybe the word “also” can b

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" 
Date: Thursday, May 24, 2018 at 2:03 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
"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

One small comment:

“this document
   elects a DF per . This means that unlike [RFC 
7432],”

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&J](Satya & Jorge).

Thank you for your thorough review!
Satya & Jorge


From: "stephane.litkow...@orange.com" 
Date: Tuesday, April 24, 2018 at 11:04 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: , , 
, , , 

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&J]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&J]fixed





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

 reference was found in the text
[S&J]fixed





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

 reference was found in the text
[S&J]fixed





  -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999'
[S&J]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&J]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&J]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&J]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&J]added:
   In addition, there is a need to extend the DF Election procedures so
   that new algorithms and capabilities are possible. A single algorithm
   (th

[bess] Protocol Action: 'IP Prefix Advertisement in EVPN' to Proposed Standard (draft-ietf-bess-evpn-prefix-advertisement-11.txt)

2018-05-24 Thread The IESG

The IESG has approved the following document:
- 'IP Prefix Advertisement in EVPN'
  (draft-ietf-bess-evpn-prefix-advertisement-11.txt) as Proposed Standard

This document is the product of the BGP Enabled ServiceS Working Group.

The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah
Brungard.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/





Technical Summary

   This document defines a new EVPN route type for the 
   advertisement of IP Prefixes and explains some use-case 
   examples where this new route-type is used.

Working Group Summary

   The process through the WG was normal; nothing specific 
   to highlight.

Document Quality

   There are at least 3 commercial implementations of this 
   specification.

Personnel

   Document Shepherd: Zhaohui (Jeffrey)Zhang (zzh...@juniper.net)
   Responsible Area Director: Alvaro Retana (aretana.i...@gmail.com)

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

[bess] I-D Action: draft-ietf-bess-evpn-df-election-framework-03.txt

2018-05-24 Thread internet-drafts


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Framework for EVPN Designated Forwarder Election 
Extensibility
Authors : Jorge Rabadan
  Satya Mohanty
  Ali Sajassi
  John Drake
  Kiran Nagaraj
  Senthil Sathappan
Filename: draft-ietf-bess-evpn-df-election-framework-03.txt
Pages   : 26
Date: 2018-05-24

Abstract:
   The Designated Forwarder (DF) in EVPN networks is the PE responsible
   for sending broadcast, unknown unicast and multicast (BUM) traffic to
   a multi-homed CE, 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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-03
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-df-election-framework-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-df-election-framework-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[bess] Publication has been requested for draft-ietf-bess-evpn-df-election-framework-03

2018-05-24 Thread Stephane Litkowski

Stephane Litkowski has requested publication of 
draft-ietf-bess-evpn-df-election-framework-03 as Proposed Standard on behalf of 
the BESS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/

___
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

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

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

[bess] Protocol Action: 'IP Prefix Advertisement in EVPN' to Proposed Standard (draft-ietf-bess-evpn-prefix-advertisement-11.txt)

[bess] I-D Action: draft-ietf-bess-evpn-df-election-framework-03.txt

[bess] Publication has been requested for draft-ietf-bess-evpn-df-election-framework-03

6 matches

Site Navigation

Mail list logo

Footer information