Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]>
> Sent: Tuesday, May 15, 2018 3:09 PM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: Christian Hopps <[e-mail]>; [e-mail]
> Subject: Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt
> 
> 
> Les Ginsberg (ginsberg) <[e-mail]> 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