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. > >> 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! Mirja > > Les > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
