Uma,

Wrt number of authors, if I recall correctly (I don’t have pointers to the 
discussion anymore), given the lengths and involvement of the authors currently 
on the front page, as an exception - both ospf and isis sr drafts would keep 
the initial number of authors.

Thanks,
Jeff

> On Jun 11, 2018, at 22:05, Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote:
> 
> Uma –
>  
> One item I forgot…there are no meaningful nits.
> Idnits reports:
>  
> -- Looks like a reference, but probably isn't: '100' on line 1009
>      'SRGB = [100, 199]...'
>  
>   -- Looks like a reference, but probably isn't: '199' on line 1009
>      'SRGB = [100, 199]...'
>  
>   -- Looks like a reference, but probably isn't: '1000' on line 1010
>      '[1000, 1099]...'
>  
>   -- Looks like a reference, but probably isn't: '1099' on line 1010
>      '[1000, 1099]...'
>  
>   -- Looks like a reference, but probably isn't: '500' on line 1011
>      '[500, 599]...'
>  
>   -- Looks like a reference, but probably isn't: '599' on line 1011
>      '[500, 599]...'
>  
>   -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589'
>  
> The fact that idnits looks at everything enclosed in [] as a reference does 
> not mean the text requires revision.
> Idnits also does not allow that a non-RFC document can be a normative 
> reference – but clearly ISO 10589 is a normative reference.

[jeff] indeed, we have used variety of non-RFC documents as normative 
references in the past, this should be acceptable in this case.
>  
> Thanx.
>  
>    Les
>  
>  
> From: Les Ginsberg (ginsberg) 
> Sent: Monday, June 11, 2018 10:00 PM
> To: Uma Chunduri <umac.i...@gmail.com <mailto:umac.i...@gmail.com>>; 
> lsr@ietf.org <mailto:lsr@ietf.org>
> Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org 
> <mailto:draft-ietf-isis-segment-routing-extensi...@ietf.org>; 
> lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>; lsr-...@ietf.org 
> <mailto:lsr-...@ietf.org>
> Subject: RE: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review 
> comments
>  
> Uma –
>  
> Thanx for the prompt review.
>  
> I have attached proposed diffs to address some of your comments.
>  
> Additional responses inline.
>  
>  
> From: Uma Chunduri <umac.i...@gmail.com <mailto:umac.i...@gmail.com>> 
> Sent: Monday, June 11, 2018 6:27 PM
> To: lsr@ietf.org <mailto:lsr@ietf.org>
> Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org 
> <mailto:draft-ietf-isis-segment-routing-extensi...@ietf.org>; 
> lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>; lsr-...@ietf.org 
> <mailto:lsr-...@ietf.org>
> Subject: draft-ietf-isis-segment-routing-extensions-16 - Shepherd review 
> comments
>  
> Dear Authors,
>  
> I have done shepherd  review of  
> draft-ietf-isis-segment-routing-extensions-16 document as requested by LSR 
> chairs. First, I would like to thank all the the authors and contributors on 
> this document.
> I have few minor comments below  and would be great if authors take a look at 
> these.
>  
>  
> =====
>  
> A. I see few ID nits (comments and warnings). Please fix  those.
> B. For the record: (as this would come up soon) : Currently there are 8  
> front page authors and please indicate why this document should be given 
> exception w.r.t 5 co-authors norm, that is being followed in general.
>  
> [Les:] This will be addressed after discussion among the authors – thanx for 
> the reminder. J
>  
> 1. Abstract & Section 1
>  
> a.
>    "These segments are   advertised by the link-state routing protocols 
> (IS-IS and OSPF)."
>  
>    I see more than LSR protocols e.g. 
> https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-07 
> <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-07>
>    Also not sure if this statement is necessary. Please either correct or 
> remove this.
>  
> [Les:] The abstract and introduction state “within IGP topologies”.  In that 
> context I believe limiting the protocols mentioned to IGPs is appropriate.
>  
> b.
>    "Two    types of segments are defined, Prefix segments and Adjacency   
> segments."
>  
>    This document defines more than these two if you include Section 2.4 
> (SID/Label Binding TLV). Section 2 is much better
>    where all types in this document are described as well as   
> [I-D.ietf-spring-segment-routing] is referred for other types.
>    In that sense the above statement looks incomplete/repetitive.
>  
> [Les:] I have revised the text in this section – see attached diffs.
>  
>  2. Section 2.1
>  
> a. "The 'Prefix SID' MUST   be unique within a given IGP domain (when the 
> L-flag is not set)."
>  
>    I see this is conflicting with what's been defined in 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-14 
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-14>,
> section 3.3 -
>    "Within an anycast group, all routers in an SR domain MUST advertise  the 
> same prefix with the same SID value."
>  
>    If you see otherwise please explain why?
>  
> [Les:] This is a misunderstanding on your part.
> An anycast prefix may be advertised by multiple nodes, but the Prefix SID 
> associated with the prefix is the same regardless of which node advertises 
> it. So there is no contradiction/conflict here.
>  
>  
> b. "A 4 octet index defining.."
> What happens  to the computed label value if the index is of 4 octets value? 
> I am asking this as index can have 4 octets but the eventual label (SRGB 
> offset + index) would be only 20 bits. 
> Can you point (if any)  references to 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls 
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls> 
> appropriate sections -  is this is addressed there?
>  
> [Les:] See 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14#section-2.4
>  
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14#section-2.4>
>  (emphasis added):
>  
> “ 0 =< I < size. If the index "I" does not satisfy the previous
>       inequality, then the label cannot be calculated.”
>  
> c. "A Prefix-SID sub-TLV is associated to a prefix advertised by a node    
> and MAY be present in any of the following TLVs:"
>  
>      Nit: Perhaps the list should include Section 2.5 too.
> [Les:] Added a reference to 2.5 as well. See attached diffs. Thanx.
>  
> 3. Section 2.2.1
>    
> a. "F-Flag: Address-Family flag..."
>  
>      Not sure why this has to do with encapsulation? What happens if native 
> IPv4/IPv6 data packet is using this SID with out any encapsulation? Could you 
> please clarify.
>  
> [Les:] When the packet is forwarded over the specified outgoing interface it 
> will either have an IPv4 encapsulation or an IPv6 encapsulation i.e., the 
> payload is encapsulated in the afi specific L3 protocol. 
> This does not mean that a new AFI specific header is imposed.
>   
> 4. Section 2.2.2
>  
> a. Nit: V and L flags: Content is duplicated and perhaps it can instead refer 
> to section 2.2.1
>  
>  
> [Les:] The text says:
> “ where F, B, V, L, S and P flags are defined in Section 2.2.1.”
>  
> ???
>  
>  
> 5. Section 3.2 and Section 2.1
>  
>     Could you please clarify what is preferred if multiple prefix-sids with 
> different algorithm values are advertised for the same SID value? 
>  
> [Les:] There is no “preference” here. In order to have algorithm specific 
> forwarding entries we MUST have different SIDs for each algorithm. A router 
> will use the SID which matches the algorithm associated with the forwarding 
> entry.
>  
>      Les
>  
> --
> Uma C.

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to