Chris -
> -----Original Message-----
> From: Lsr <[email protected]> On Behalf Of Christian Hopps
> Sent: Tuesday, May 15, 2018 8:08 AM
> To: Les Ginsberg (ginsberg) <[email protected]>
> Cc: [email protected]; Christian Hopps <[email protected]>
> Subject: Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt
>
>
> Les Ginsberg (ginsberg) <[email protected]> writes:
>
> > Chris -
> >
> >> Issue: Under both the Node and Link sub-tlv's the MSD type (1?) is
> >> not actually mentioned, only the "MSD value", if one was pedantic it
> >> would mean that regardless of the type the value was always the same,
> >> certainly not what is intended. :)
> >
> > [Les:] In both sections the draft says (emphasis added):
> >
> > "Value: field consists of one or more pairs of a 1 octet MSD-Type
> > (IANA Registry) and 1 octet Value.
> >
> > Why do you see this as unclear?
>
> Let me come at this a different way:
>
> Type -- specified: 23
> Value -- specified: pairs of MSD type and MSD values.
> MSD-Type -- *unspecified*
[Les:] The draft says (repeating myself):
"Value: field consists of one or more pairs of a 1 octet MSD-Type
(IANA Registry) and 1 octet Value."
This clearly specifies that the "MSD-Type" is one of the values in the IANA
registry.
> MSD-Value -- specified "the MSD value is a number ..."
>
> One might could infer after looking at the *current* registry that the only
> valid value could be:
>
> Type: 1 -- Base MPLS Imposition MSD
[Les:] And you would be correct. Until such time as other values are added to
the registry the meaning of anything other than "1" is undefined.
But this section (and the companion Link MSD section) is not about defining
specific MSD types - it is about describing the generic encoding.
>
> However, the text also doesn't even use "Base MPLS Imposition MSD" to
> describe the MSD value here (it talks about this in later sections), so I'd
> say
> it's under-specified at this point.
[Les:] It would be inappropriate to discuss a specific MSD type in this generic
description of the encoding.
Section 5 defines the one type this document specifies (BMI-MSD).
>
> 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.
> 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.
>
> 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.
Les
>
> Thanks,
> Chris.
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
