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

From: [email-masked]
Date: Thu, 10 May 2018 17:48:53 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

        Title           : Signaling MSD (Maximum SID Depth) using IS-IS
        Authors         : Jeff Tantsura
                          Uma Chunduri
                          Sam Aldrin
                          Les Ginsberg
	Filename        : draft-ietf-isis-segment-routing-msd-11.txt
	Pages           : 9
	Date            : 2018-05-10

Abstract:
   This document defines a way for an IS-IS Router to advertise multiple
   types of supported Maximum SID Depths (MSDs) at node and/or link
   granularity.  Such advertisements allow entities (e.g., centralized
   controllers) to determine whether a particular SID stack can be
   supported in a given network.  This document only defines one type of
   MSD maximum label imposition, but defines an encoding that can
   support other MSD types.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-11
https://datatracker.ietf.org/doc/html/draft-ietf-isis-segment-routing-msd-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-segment-routing-msd-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 11 May 2018 00:51:40 +0000

This is a minor editorial revision to make the draft consistent w draft-ietf-ospf-segment-routing-msd-12.

   Les

> -----Original Message-----
> From: Lsr <[email-masked]> On Behalf Of [email-masked]
> Sent: Thursday, May 10, 2018 5:49 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Christian Hopps <[email-masked]>
Date: Tue, 15 May 2018 04:54:18 -0400

Hi Les,

I was going over the 2 SR-MSD documents (IS-IS and OSPF) just wondering how viable it would be and if we should combine them.

In any case doing the diff highlighted a couple issues in the IS-IS version.

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. :)

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.

Maybe Issue: We've got 2 drafts creating the same sub-[-sub]-tlv MSD type registry. I fully agree that we should only have one registry, but it's interesting that we'll have 2 publications that create and reference it. Also, where does this registry go in IANA? There are distinct IS-IS, OSPFv2 and OSPFv3 pages that contain the IANA registries for each protocol. Should we create a new shared LSR or IGP page? Anyway this might be a reason to combine the 2 documents.

While somewhat inelegant we could probably avoid any need to re-Last Call if the combination was basically a cut and paste operation.

Thanks,
Chris.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 15 May 2018 11:33:25 +0200

Hi Chris,

On 15/05/18 10:54 , Christian Hopps wrote:
>
> Hi Les,
>
> I was going over the 2 SR-MSD documents (IS-IS and OSPF) just wondering
> how viable it would be and if we should combine them.
>
> 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. :)
>
> 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.
>
> Maybe Issue: We've got 2 drafts creating the same sub-[-sub]-tlv MSD
> type registry. I fully agree that we should only have one registry, but
> it's interesting that we'll have 2 publications that create and
> reference it. Also, where does this registry go in IANA? There are
> distinct IS-IS, OSPFv2 and OSPFv3 pages that contain the IANA registries
> for each protocol. Should we create a new shared LSR or IGP page? Anyway
> this might be a reason to combine the 2 documents.

there is one already:
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml

I agree that we need registry to be created in only one of the documents 
and have other reference it, unless we merge these two drafts.

thanks,
Peter

>
> While somewhat inelegant we could probably avoid any need to re-Last
> Call if the combination was basically a cut and paste operation.
>
> Thanks,
> Chris.
>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-isis-segment-routing-msd-
>>>
>>> 11
>>>
> .

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 15 May 2018 13:43:23 +0200

Hi Chris,

I don't see much value in merging, most of the content describes encodings which are different, per protocol,
Wrt registry - please let us know which draft you'd want to request the new registry.

Thanks! 

Cheers,
Jeff
On 5/15/18, 11:33, "Lsr on behalf of Peter Psenak" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Chris,

    there is one already:

    thanks,
    Peter

---

From: Christian Hopps <[email-masked]>
Date: Tue, 15 May 2018 09:13:39 -0400

Please notice I raised 2 other issues outside of merging. If there will be a rev to the IS-IS document to deal with those then you could pull the registry definition from it and simply refer to the one defined by the OSPF document. We need to make sure that the OSPF document causes the registry to go to the IGP IANA page and not to OSPF though.

I'm fine with skipping the merging; however, them both being mostly encoding drafts doesn't preclude merging either. In fact all the rest of the text is /almost/ copy and paste, and repeating things in standards with slight differences is usually a bad idea. In this case though we're almost done so let's just finish the work and flex algorithm can be our first merged document instead.

Thanks,
Chris.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 15 May 2018 14:38:53 +0000

Chris -

> From: Christian Hopps <[email-masked]>

> Sent: Tuesday, May 15, 2018 1:54 AM

> To: Les Ginsberg (ginsberg) <[email-masked]>

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

[Les:] (I knew somebody would ask this question. :-) )

The two documents were fairly mature before the official merging of the two IGP WGs and certainly before we actively started pursuing combined documents in cases where it makes sense.

Whatever benefit might accrue from combining the documents (and you can see from the responses on the list that there are different opinions about this) it is overwhelmed by the delay that is likely to be introduced by taking two documents that have already passed last call and revising them into one document.

We have mature documents, we have implementations, we need to proceed to publication without introducing unnecessary delays.

> 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?

> 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.

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.

> Maybe Issue: We've got 2 drafts creating the same sub-[-sub]-tlv MSD type

> registry. I fully agree that we should only have one registry, but it's

> interesting that we'll have 2 publications that create and reference it. Also,

> where does this registry go in IANA? There are distinct IS-IS, OSPFv2 and

> OSPFv3 pages that contain the IANA registries for each protocol. Should we

> create a new shared LSR or IGP page? Anyway this might be a reason to

> combine the 2 documents.

[Les:] Peter has already responded as to "where the registry goes" - which is clearly stated in the drafts:

"This document requests creation of an IANA managed registry under a

   new category of "Interior Gateway Protocol (IGP) Parameters" IANA

   registries..."

I agree only one document should define the registry and the other should reference it. That was the agreement between the authors - but it seems we did execute well. We will discuss and decide which draft to change.

    Les

> While somewhat inelegant we could probably avoid any need to re-Last Call if

> the combination was basically a cut and paste operation.

> Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> writes:

> > This is a minor editorial revision to make the draft consistent w draft-ietf-

> ospf-segment-routing-msd-12.

> >> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of

> >> [email-masked]<mailto:[email-masked]>

> >> To: [email-masked]<mailto:[email-masked]>

> >> Cc: [email-masked]<mailto:[email-masked]>

> >> A New Internet-Draft is available from the on-line Internet-Drafts

> directories.

> >> https://datatracker.ietf.org/doc/html/draft-ietf-isis-segment-routing

> >> -msd-

> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-segment-routing-msd

> >> -11

> >> Please note that it may take a couple of minutes from the time of

> >> submission until the htmlized version and diff are available at

> tools.ietf.org.

> >> [email-masked]<mailto:[email-masked]>

> > [email-masked]<mailto:[email-masked]>

---

From: Christian Hopps <[email-masked]>
Date: Tue, 15 May 2018 11:07:56 -0400

> 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*
    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

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.

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? That's would be surprising enough that I think it would need to be made explicit.

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".

Note: this comment refers to both the Node and Link sub-TLVs.

> There is therefore no need for further specification.

Well that might cover the Node TLV, but not the Link TLV, right?

> 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.

Thanks,
Chris.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 15 May 2018 20:07:04 +0000

Chris -

> From: Lsr <[email-masked]> On Behalf Of Christian Hopps
> Sent: Tuesday, May 15, 2018 8:08 AM
> Cc: [email-masked]; Christian Hopps <[email-masked]>
> >> 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,
[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.

>     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.

> 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. :-)

> >> 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 .
> >
[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

---

From: Christian Hopps <[email-masked]>
Date: Tue, 15 May 2018 18:09:14 -0400

> [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.

> The phrase " MSD Type 1 (IANA Section)" should be removed.

OK good then.

> 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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 16 May 2018 15:45:30 +0000

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

> Sent: Tuesday, May 15, 2018 3:09 PM
> Cc: Christian Hopps <[email-masked]>; [email-masked]
> >> 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. :)
> 
>     "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.
> 
> >> >> 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.
> >> >
> >> 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.
> >
> 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