[bess] RtgDir review: draft-ietf-bess-nsh-bgp-control-plane-13

[Ravi Singh]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-bess-nsh-bgp-control-plane-13.txt
Reviewer: Ravi Singh
Review Date: 01-26-2020
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be resolved 
before publication.


Comments: 
0.  Having finished reading through the entire doc, the whole picture comes 
together clearly. 
However, given the size of this document…..as one is reading this document it 
takes a high level of effort to stay with the picture.
I feel the readability could be somewhat improved.  See #1 under “minor issues” 
for a suggestion.

Major Issues:
No major issues found.

Minor issues:

1.
Section2: During an initial reading, the terminology comes across as overly 
repetitive and a bit pedantic….which takes away from the readability a bit when 
one is reading the sections in the order listed. Content of RFC7665/8300 are 
also contributors to this.
Eg: "In fact, each SI is mapped to one or more SFs that are implemented by one 
or more Service Function Instances (SFIs) that support those specified SFs. "  
: almost sounds like legalese when someone who has not grasped the complete 
picture of the draft.
 
Wrote up the above as I was reading that section for the first time.
However, after finishing the review…started to appreciate this.
 
In having read the sections in order, I think the readability would have been 
greatly enhanced if I had read section 8 first, else once just gets lost in all 
the details.
It would be worthwhile suggesting in the text that once the reader has read 
through section 2, it would help to read section 8 before reviewing the 
intervening sections.
 
2. Section 3.2.1: page 16:
"[RFC7606]
   revises BGP error handling specifically for the for UPDATE message,"
 
->
"[RFC7606]
   revises BGP error handling specifically for the UPDATE message,”

3. 
Page 17:
  a. Was the intention for treating error 4 any different from errors, 
[1,2,6,7]? If not, why the need to call out 4 separately?
  b. "Unknown SFIR-RD found in a Hop TLV." :
The format of the Hop TLV in section 3.2.1.2 contains no reference to an RD. 
So, was the intention instead to refer to the SFIR-RD list of one of the SFT 
TLVs inside the Hop TLV?

4.
Section 3.2.1.2: "At least one sub-TLV MUST be present. "
Where are these sub-TLVs defined?
In this regard,
  a. Section 3.2.1.3 says "The SFT TLV MAY be included in the list of sub-TLVs 
of the Hop TLV.":
  b. Section 3.2.1.4 says "The MPLS Swapping/Stacking TLV (Type value 4) is a 
zero length sub-TLV that is OPTIONAL in the Hop TLV "

In the absence of specific mention of details of sub-TLVs in section 3.2.1.2, 
is a reader to assume that SFT TLVs & the MPLS swap/stack TVLs are the only 
possible subTLVs under a hop-TLV (as intended in this revision of the ID)?
This aspect becomes clear later, when one gets to reading the description of 
the subsequently mentioned TLVs. Might be worth alluding to this in 3.2.1.2.

5.
"In the normal case the SPI remains unchanged and the SI will have been 
decremented to indicate the next SF along the path.": will SI really be 
decremented instead of just setting it to the appropriate value? As per this 
draft, set to an appropriate lower value…

6.
What exactly does the following mean? "Also, as described in [RFC8300], an SFF 
receiving an SI that is unknown in the context of the SPI can reduce the value 
to the next meaningful SI value in the SFP indicated by the SPI. If no such 
value exists or if the SFF does not support this function, the SFF drops the 
packet and should log the event: such logs are also subject to rate limits."

7. 
Figure 1: showing the SFIs hosted on SFF2 and SFF3 in the same conceptual block 
(just because they share the same type) is a bit confusing when the diagram is 
showing a logical view of the physical layout of the elements of the solution.

8.
Section 3.1:the following is an ambiguous sentence & I suggest rewording to 
clarify:
"Note that it is assumed that each SFF has one or more globally unique SFC 
Context Labels and that the context label space and the SPI address space are 
disjoint." 
This sounds like that the "context label space" and the "SPI address space" are 
disjoint w.r.t. each other. What appears to be intended 

Re: [bess] WGLC , IPR and implementation poll for draft-ietf-bess-evpn-unequal-lb-03

[Neeraj Malhotra]

Hi,

Support as co-author. Not aware of any IPR.

Thanks,
Neeraj


On Fri, Jan 17, 2020 at 12:56 AM  wrote:

> Hi WG,
>
>
>
> This email starts a two weeks Working Group Last Call on 
> draft-ietf-bess-evpn-unequal-lb-03
> [2]
>
>
>
> Please review the draft and send any comments to the BESS list. Also,
> please indicate if you support publishing the draft as a standards track
> RFC.
>
>
>
> This poll runs until Fri 31th January 2019.
>
>
>
> 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.
>
> We are also polling for any existing implementation as per [1]. Please
> indicate if you are aware of any implementations.
>
>  Thank you,
>
> Stephane
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
> [2] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess