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

[Christian Hopps <[e-mail]>]

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