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. > 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. 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 like to think we can deal with this when the time comes. Sound OK? > 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. Les _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
