Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

[Ali Sajassi (sajassi)]

Hi Alvaro,

Thank you  for your thorough review and comments. I have addressed all of them. 
Please refer inline for details on each. I just posted a new rev (rev10) that 
covers all the comment resolutions addressed here.

https://www.ietf.org/id/draft-ietf-bess-evpn-etree-10.txt


From: "Alvaro Retana (aretana)" >
Date: Tuesday, April 4, 2017 at 2:37 PM
To: 
"draft-ietf-bess-evpn-et...@ietf.org"
 
>
Cc: "bess-cha...@ietf.org" 
>, 
"bess@ietf.org" >, 
Thomas Morin >
Subject: AD Review of draft-ietf-bess-evpn-etree-09
Resent-From: >
Resent-To: Cisco Employee >, 
>, 
>, 
>, 
>, 
>
Resent-Date: Tuesday, April 4, 2017 at 2:37 PM

Dear authors:

I just finished reading this document.  In general, the document could benefit 
from an editorial pass to improve readability; I put in some suggestions below, 
but I’m sure I didn’t mention all.  I don’t think that my comments (even the 
Major ones) will be hard to resolve – most are around providing clarity and 
consistency.  I’ll wait for a revised draft before starting the IETF Last Call.

Thanks!

Alvaro.



Major:

M1. Both the Introduction and the Abstract mention that “this document 
discusses how the functional requirements for E-Tree service can be easily 
met…”  It seems to me that RFC7387 is used as the building block for this 
document.  Why is it not a Normative reference?

Because RFC7387 is informational RFC (and the framework RFC) and the idnits 
complains of a downref: Normative reference to an informational RFC

M2. There is no reference to E-Tree.  Please add a Normative one.

Added a reference for E-TREE definition in MEF.

M3. In Section 2.2 (Scenario 2: Leaf OR Root site(s) per AC): “…then a single 
RT per EVI MAY be used…”  I think that “MAY” is out of place because it seems 
to be expressing just a fact.  Also, please keep the normative language where 
the operation is defined (in this case in 3.1).

Changed “MAY” to “can”.

M4. Section 3.1 (Known Unicast Traffic) talks about how in the “multi-homing 
scenario of section 2.2…the PE MAY advertise leaf indication along with the 
Ethernet A-D per EVI route”.  Given that the text later says that “in case of 
discrepancy, the multi-homing for that pair of PEs is assumed to be in default 
"root" mode”, I find the “MAY” not sufficient.  If we want to prevent as many 
discrepancies as possible, shouldn’t that be a “SHOULD” (or even a “MUST”)?   
Given the local configuration, why would the PE not want to include the leaf 
indication…ever…?

It is cleaned up.

M5. In Section 5.1 (E-TREE Extended Community) there is redundant information 
(first and last paragraphs).  Among that redundant information there is no 
consistency: “the Leaf Label field is set to a valid MPLS label” and “the Leaf 
Label MUST be set to a valid MPLS label” – please be consistent and specify 
things just once.

Removed the replicated/redundant text

M5.1. BTW, that is a “valid MPLS label”?  How would a receiver recognize it?  
Please add a reference to avoid confusion.

Added a brief description of “valid MPLS label” and provided the reference


M6. Definition of the E-TREE Extended Community

M6.1. Only one Flag is defined.  What about the others?  Please set up a 
registry.

If needed in the future, we will setup a registry.

M6.2. [Minor] Please put a Figure number and heading for the community format.

Done.

M6.3. It looks like the Reserved fields are set to 0.  What should happen if 
the receiver gets something else?

Added a sentence that “the receiver should ignore the reserved bits”

M6.4. “…the Leaf-Indication flag MUST be set to one and Leaf Label is set to 
zero. The received PE should ignore Leaf Label and only processes 
Leaf-Indication flag.”  What if the Leaf Label is not set to zero?  The second 
sentence says to ignore it, but the first one that it “MUST be…set to zero”.  
Which one is it?  Maybe both…  Be specific!

For MPLS label, changed it to “the transmitter SHOULD set it to zero and the 
receiver SHOULD ignore it”.

M6.5. “…the Leaf Label MUST be set to a valid MPLS label and the 
Leaf-Indication flag should be set to zero. The received PE should ignore the 
Leaf-Indication flag.”  Similar question for the Leaf-Indication bit.

For Leaf-Inication flag, change it to "the transmitter SHOULD set it to zero 
and the receiver SHOULD 

[bess] WG adoption for draft-boutros-bess-evpn-vpws-service-edge-gateway-03

[Sami Boutros]

Hi Martin and Thomas,

We would like to ask for WG adoption for this draft, as there are vendor 
planned implementations for it.

Thanks,

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

[bess] 3107bis LC discussion on MPLS list

[Eric C Rosen]

This discussion (see the attached messages) really should have been 
cc'ed to BESS and IDR.


--- Begin Message ---
Hello


I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc3107bis/


The routing directorate will, on request from the working group chair, perform 
an “early” review of a draft before it is submitted for publication to the 
IESG.  The early review can be performed at any time during the draft’s 
lifetime as a working group document.  The purpose of the early review depends 
on the stage that the document has reached.  As this document is in working 
group last call, my focus for the review was to determine whether the document 
is ready to be published.  Please consider my comments along with the other 
working group last call comments.



For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Best regards

Jon



Document: draft-ietf-mpls-rfc3107-01

Reviewer: Jonathan Hardwick

Review Date: 27 April 2017

Intended Status: Standards Track



Summary
Thank you for writing this document.  It provides much-needed clarity to the 
original RFC 3107.
This document is very well written.  I think that it is ready to be published, 
but there are a few points below that I would like to discuss for clarification.
I also spotted a few nits that should be fixed at some point before publication.

Comments and Questions

1) In section 2.1 it says:
“   If the Multiple Labels Capability for a given AFI/SAFI had been
   exchanged on the failed session, but is not exchanged on the
   restarted session, then any prefixes advertised in that AFI/SAFI with
   multiple labels MUST be explicitly withdrawn.”

If I have understood this correctly, it requires a speaker to withdraw NLRI 
that it sent on the previous session but that it has not sent on the restarted 
session (because the negotiated session capabilities changed).
(a) Why does it need to do that – isn’t the NLRI implicitly withdrawn when the 
EOR marker is sent?
(b) This seems to contradict section 2.4 which says “Note that label/prefix 
bindings that were not advertised on the given session cannot be withdrawn by 
this method.”


2) In section 2.1 it says:
“A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a given 
prefix than its peer is capable of receiving” – why isn’t that MUST NOT?


3) In section 2.4 it says:
“To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI attribute.”
Should that be “it MUST send”?


4) In section 5: although some implementations treat SAFI 1 and SAFI 4 routes 
as comparable, I believe that they should always be treated as independent, in 
the following sense:
Suppose a speaker S1 sends a SAFI 1 route and then a SAFI 4 route to the same 
prefix P.  The SAFI 4 route MUST NOT be treated by the receiving speaker as an 
implicit withdraw of the SAFI 1 route.  If S1 subsequently sends an explicit 
withdraw of the SAFI 4 route, this MUST NOT implicitly withdraw the SAFI 1 
route, and vice versa.
Am I correct?  I have seen implementations that violate this so I think it is 
worth spelling out somewhere in this section.


5) In section 7 it says:
“ If a BGP implementation, not conformant with the current document,
encodes multiple labels in the NLRI but has not sent and received the
"Multiple Labels" Capability, a BGP implementation that does conform
with the current document will likely reset the BGP session.”

Wouldn’t that prevent incremental deployment of this RFC into a network that is 
initially composed of such implementations?  Because it seems to require that 
both ends of each BGP session must be upgraded simultaneously, or else the BGP 
sessions will all reset.


Nits

Section 2: Missing close-parenthesis on “([RFC4760]” – this occurs twice in 
this section
Section 2.1: s/ an prefixes advertised/ any prefixes advertised/
Section 2.1: Figure 1 appears quite a long way distant from the text that 
references it.  I suggest moving it to immediately after the paragraph it is 
referenced from.
Section 2.1: s/MUST BE/MUST be/
Section 3.1: s/different path identifiers../different path identifiers./  (i.e. 
remove stray extra period)
Section 3.2.1: “using the procedure of Figure 4” should be “using the procedure 
of Section 2.4”.
Ditto in section 3.2.2.
Section 4: s/S a layer 2 encapsulation/a layer 2 encapsulation/ (i.e. delete 
stray ‘S’)

--- End Message ---
--- Begin Message ---

Thanks for your review!


On 4/27/2017 9:03 AM, Jonathan Hardwick wrote:


I also spotted a few nits that should be fixed at some point before 
publication.




I have fixed the nits.


Comments and Questions

1) In section 2.1 it says:

“   If the Multiple Labels Capability for a given AFI/SAFI had been

   exchanged on the failed session, but is not exchanged on the

   restarted session, then any prefixes advertised in that AFI/SAFI with

   multiple labels MUST be 

Re: [bess] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure

[Martin Vigoureux]

WG,

there is a clear renewed support for this document, so we'll continue as 
normal.

Thank you.

M

Le 13/04/2017 à 20:04, Martin Vigoureux a écrit :

WG

Given the IPR disclosed [1] against
draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for
comment specifically to let people express a revised opinion on how
draft-ietf-bess-nsh-bgp-control-plane should be pursued in BESS.

This call for comment is open until the 5th of May

Thanks
M

[1] https://datatracker.ietf.org/ipr/2980/


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