Mirja - Inline.
> -----Original Message----- > From: Mirja Kuehlewind <[email protected]> > Sent: Tuesday, May 14, 2019 9:35 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: The IESG <[email protected]>; draft-ietf-isis-segment-routing- > [email protected]; Christian Hopps <[email protected]>; Uma Chunduri > <[email protected]>; [email protected]; [email protected]; > [email protected] > Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-isis-segment- > routing-extensions-24: (with COMMENT) > > Hi Les, > > Please see inline. > > > On 14. May 2019, at 18:12, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > > > Mirja - > > > > Thanx for the review. > > Responses inline. > > > >> -----Original Message----- > >> From: Mirja Kühlewind via Datatracker <[email protected]> > >> Sent: Tuesday, May 14, 2019 4:58 AM > >> To: The IESG <[email protected]> > >> Cc: [email protected]; Christian Hopps > >> <[email protected]>; Uma Chunduri <[email protected]>; > >> [email protected]; [email protected]; [email protected]; > >> [email protected] > >> Subject: Mirja Kühlewind's No Objection on draft-ietf-isis-segment- > routing- > >> extensions-24: (with COMMENT) > >> > >> Mirja Kühlewind has entered the following ballot position for > >> draft-ietf-isis-segment-routing-extensions-24: No Objection > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing- > extensions/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> A few comments/questions: > >> > >> 1) For both the Prefix Segment Identifier and the Adjacency Segment > >> Identifier > >> sub-TLV it is not fully clear to me what the value field is used for when > >> the > >> V-Flag is set. Can you further elaborate this in the draft or provide a > >> respective pointer? > >> > > [Les:] https://tools.ietf.org/html/draft-ietf-isis-segment-routing- > extensions-24#section-2.1.1.1 defines this. > > I was assuming that it is defined somewhere. Maybe putting a ref in the doc > that points at this draft could be good. [Les:] There are multiple references to this section in the document. Please search for them. > > > >> 2) The F-Flag in Adjacency Segment Identifier sub-TLV and SID/Label > Binding > >> TLV > >> is only one bit. I'm not expecting a new version of IP any time soon, > >> however, > >> maybe completely different address families could be useful as well. Not > >> sure > >> if only 1 bit is future-proof...? > >> > > [Les:] This is a very forward looking comment. :-) > > > > Seriously, if a new version of IP is invented there will be a LOT of > > protocol > work required to support it. It is also not a given that MPLS would be > supported for such a new IP version - so it isn't at all a given that these > extensions (however modified) would apply. > > I’m actually not sure because many protocols that need to cover IPv4 and > IPv6 have already a longer field (or alternative would need a new extension > for any new protocol anyway)… > > > Also, changing the encoding now would be problematic for existing > deployments (of which there are many) and I think we would have a hard > time defining what an extensible encoding would be. > > I was assuming this answer already, so… > > > > I like to think we can deal with this when the time comes. > > Sound OK? > > … I guess it’s fine. > > > > >> 3) Would it make sense to also discuss any risk of leaking information > >> (e.g. > >> about the network topology) in the security consideration section? > >> > > > > [Les:] Prefix leaking is an established practice in IS-IS dating back to RFC > 1195, extended by RFC 5302, and not modified by this document. > > Note that the Security section already discusses the advertisement of > information used to program the MPLS forwarding plane - which covers the > additional sub-TLV information which would accompany leaked prefixes. > > Adding a few sentences and pointers to the RFC you just listed could still be > good! [Les:] I'll give it some thought. Security review has yet to happen - so I am sure there will some additional comments. :-) Les > > Mirja > > > > > > Les > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
