Chris - V12 of the IS-IS Draft has just been posted. I believe this addresses your concerns.
In addition, Jeff and I have discussed and a new version of OSPF draft will be posted shortly which: 1)Removes the confusing text in Sections 2 and 3. 2)References the registry which is defined in the IS-IS document. WG chairs please do what is necessary when progressing the documents so that the registry creation and reference to it do not become blocking items. I hope this addresses all issues you have raised - but if not be sure to let us know. :-) Les > -----Original Message----- > From: Christian Hopps <[email protected]> > Sent: Tuesday, May 15, 2018 3:09 PM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Christian Hopps <[email protected]>; [email protected] > Subject: Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt > > > Les Ginsberg (ginsberg) <[email protected]> writes: > > > Chris - > > > >> Or is it in fact the case that you are saying that no matter what the > >> MSD-Type is the MSD value will always be as defined currently in sections > 2 and 3? > > > [Les:] Correct > > >> That's would be surprising enough that I think it would need to be > >> made explicit. > > > [Les:] It is made explicit. Your expectation that this section is in any way > specific to a particular MSD type is quite surprising. > > Given the text in the OSPF document specifies the type, is the most recently > updated of the 2 documents, and I've mentioned is the reason I'm bringing > this discrepancy up, it is surprising that you find my surprise surprising. :) > > Would you be amenable to change the text (and similarly the link section) to > read, > > "The Node MSD value is a number in the range of 0-255. *Regardless of > MSD type*, 0 represents lack of the ability to support SID stack of any depth; > any other value represents that of the node. This value MUST represent the > lowest value supported by any link configured for use by the advertising IS-IS > instance." > > Honestly, I don't know why you want to define such specific semantics (no > subset of links ever?) for this and all future MSD types, but your more the > expert on this technology and perhaps no other meaning for the values could > ever make any sense. > > >> FWIW, I noticed this by doing a diff so here's the OSPF text: > >> > >> "MSD Type 1 (IANA Section), MSD and the Value field contains the MSD > >> of the originating router. Node MSD is a number in the range of > >> 0-255. 0 represents lack of the ability to impose MSD stack of any > >> depth; any other value represents that of the node. This value > >> SHOULD represent the minimum value supported by a node." > >> > >> That text looks a bit off too ("MSD and the Value field"?), but at > >> least its saying the MSD type is "1". > > > > [Les:] And it should not. OSPF draft section 5 define BMI-MSD - which is > assigned codepoint 1. > > The phrase " MSD Type 1 (IANA Section)" should be removed. > > OK good then. > > >> Note: this comment refers to both the Node and Link sub-TLVs. > >> > > [Les:] On this we agree. :-) > > > >> >> Issue: The OSPF version adds text about what to do in the presence > >> >> of multiple instances of the same TLV. This highlighted the fact > >> >> that the IS-IS draft doesn't do this, but also doesn't talk about > >> >> there only being > >> 1 allowed. > >> > > >> > [Les:] MSD inherits the procedures defined in > >> https://tools.ietf.org/html/rfc7981#section-3 . > >> > > >> > There is therefore no need for further specification. > >> > >> Well that might cover the Node TLV, but not the Link TLV, right? > >> > > [Les:] OK - we can add text to cover this point as regards Link sub-TLV. > > > >> > The meaning of "one allowed" is not the same in IS-IS. Clearly > >> > multiple MSD > >> sub-TLVs are allowed since there are 255 possible MSD types and they > >> would not all fit into a single sub-TLV. > >> > >> The main point I'm making here is that the OSPF document goes out of > >> it's way to be explicit about multiple values not being allowed, the > >> IS-IS document leaves this unspecified. > > > > [Les:] If you have a problem with this, please take it up in the context of > RFC 7981. > > No one has objected to that definition and it has been in place since 2006. > > I did say that Node TLV was OK above so I'm not sure what further problem > you think I might have with RFC 7981, in any case I don't. :) > > Thanks, > Chris. > > > Les _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
