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>>; > email@example.com <mailto:firstname.lastname@example.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: email@example.com <mailto:firstname.lastname@example.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