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
