Subject: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07

From: Christian Hopps <[email-masked]>
Date: Wed, 20 Dec 2017 03:33:15 -0500

The authors have asked for and we are starting a WG Last Call on

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

which will last an extended 4 weeks to allow for year-end PTO patterns.

An IPR statement exists:

  https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-isis-segment-routing-msd

Authors please reply to the list indicating whether you are aware of any
*new* IPR.

Thanks,
Chris.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 20 Dec 2017 09:50:33 +0000

Hello,

I support this document and would like to ask the authors and WG to consider if we can expand the scope of this draft to not just "imposition" of the SID stack but also other similar limits related to other actions (e.g. reading, processing, etc.). With Segment Routing, we are coming across various actions that nodes need to do with the SID stack for different purposes and IMHO it would be useful to extend the MSD ability to cover those as they arise.

Thanks,
Ketan

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: 20 December 2017 14:03
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07

An IPR statement exists:

Thanks,
Chris.

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: <[email-masked]>
Date: Wed, 20 Dec 2017 10:10:50 +0000

Hi authors,

Please find below WGLC comments on this document.

Major:
-----
"the provisioned MSD
   of the router originating the Router Capability TLV.  Node MSD is the
   lowest MSD supported by the node of any interface and can be
   provisioned in IS-IS instance."
   
I don't see the MSD as a provisioned value, but as a hardware capability. (Note that as a network operator, I'd be happy to be able to provision this capability without changing the hardware/software, but that has not been my experience so far.)
Let's not put the burden on the network operator to configure this, while the node should know the value better. (as a priori, in the absence this extension, the node would report an error if instructed to push more labels than it is capable of). Especially for WAN routers, when Line Card may be changed (e.g. upgraded), so this would requires the network operator to keep track of all Line card change and update the MSD capability accordingly.(in which case, it may be just simpler to configure it directly on the controler, rather than requiring IS-IS, OSPF, BGP-LS protocol extensions, plus new features on all (involded) nodes)
-----
"the provisioned MSD of the interface associated with the link."

Please explicit whether the controller/reader need to use the MSD of the incoming link or of the outgoing link.
If you believe this may be hardware dependent, this need to be signaled.

==============
Minor:
"MSD of type 1 (IANA Registry), called Base MSD, is used to signal the total number of SIDs a node is capable of imposing,"
I think that this is limited to MPLS-SID. It would be good to state this somewhere. e.g. :s/SIDs/MPLS SIDs
----
"MSD: Maximum SID Depth"
IMHO, I'm not a big fan of the term "depth".
I find that it can be mislead with RLD (Readable Label Depth Capability). I don't feel that pushing N SID requires looking/going deep into the packet. Looking at the surface of the incoming label looks enough.
Obviously, the comment is late.

Related comment: I don't find the definition to be explicit enough. e.g. You now need to define what "SID depth" is or provide or reference.
-----
1.1.1.  Terminology

Given that the term are very very briefly explained, may be adding a reference to the RFC defining/explaining them.
---
"In order, for BGP-LS to signal MSD for
   the all nodes and links in the network MSD is relevant, MSD
   capabilites SHOULD be distributed to every IS-IS router in the
   network."

I don't think that the "SHOULD" is related to interoperability. Hence a "should" is probably enough. 

-----
   "Value field consists of a 1 octet sub-type (IANA Registry) and 1 octet value."
   
I don't see the value (sic) to hard code the legnth of the "sub-value":
- this restrict the use of future MSD Sub-type Codepoints
- if we hard code it, there is no use of the "length" field. (and "Length is variable " becomes not true)
-----
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type       |   Length      |      Sub-Type and Value       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"Value field consists of a 1 octet sub-type (IANA Registry) and 1
   octet value."
   
Text and figure do not match: the value field is either 'Sub-Type and value" as per the text, or just "value without the Sub-type" as per the figure.  

*2 (link and node MSD)
---
§ MSD Advertisement

"   Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD
   of the router originating the corresponding TLV's 22, 23, 141, 222,
   and 223.  Link MSD is a number in the range of 0-254. 0 represents
   lack of the ability to impose MSD stack of any depth; any other value
   represents that of the particular link MSD value."
   
It's not clear whether the text related to the MSD value is specific to the Sub-type 1 or to the whole Link MSD Advertisment. (i.e. would restrict the usage of future sub-Types). May be using two sections would help: one defining the Link MSD, one defining Sub-type 1. In which case the last paragraph of the introduction may be move to this new sub-type 1 section.

*2 (link and node MSD)
-----
" Other Sub-types other than defined above are reserved for future extensions.  This sub-TLV is optional."
It's not clear whether you mean this sub-TLV 1, or any sub-TLV n, or the presence of a sub-TLV. 
----
"the ability to impose MSD stack of any depth"
Were are not imposing an "MSD stack", but SID stack. Actually the SR architecture tends to use the term "list of segments" (or "ordered list of segments")

----
"   This document describes a mechanism to signal Segment Routing MSD
   supported at node and/or link granularity through IS-IS LSPs and does
   not introduce any new security issues."
   
Improved fingerprinting capability would be one. Which may help target the right vulnerability of the advertising router.

==============
Nits:
"supported by a node at node and/or link granularity"
May be NEW: supported by a node or link

"In order, for BGP-LS to signal MSD for
   the all nodes and links in the network MSD is relevant, MSD
   capabilites SHOULD be distributed to every IS-IS router in the
   network."
In my understandind:
:s/the all nodes/all the nodes
:s/distributed to every IS-IS router/advertised by every IS-IS router
---

   "A new sub-TLV within the body of IS-IS Router Capability TLV
   [RFC7981], Node MSD sub-TLV is defined to carry the provisioned MSD
   of the router originating the Router Capability TLV. ""

May be the following would be easier to read

   A new sub-TLV "Node MSD sub-TLV" is defined within the body of IS-IS Router Capability TLV
   [RFC7981],  to carry the provisioned MSD
   of the router originating the Router Capability TLV.
-----

   "Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD
   of the router originating the corresponding TLV's 22, 23, 141, 222,
   and 223.  Link MSD is a number in the range of 0-254."   
   
Please use two paragraphs. One for "Sub-type" field, one for "MSD value" field.
-----
"0 represents lack of the ability to impose MSD stack of any depth "
May be NEW: "0 represents lack of the ability to impose any SID"
----
"Maximum MSD"
NEW: MSD
("M" already stands for Maximum)
Multiple times in the doc, with "Maximum" or "maximum"
----
The document has 2 "Terminology" sections. You should probably merge them.

Thanks
Regards,
--Bruno

 > Sent: Wednesday, December 20, 2017 9:33 AM
 > To: [email-masked]

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 20 Dec 2017 13:23:17 +0000

I support publication of this draft. Note that we have completed the WG
last call for the OSPFv2 Segment Routing Extensions.

Thanks,
Acee

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 20 Dec 2017 11:37:34 -0800

Hi Bruno,

Many thanks for your valuable comments and see in line

Cheers,
Jeff

-----Original Message-----
From: <[email-masked]>
Date: Wednesday, December 20, 2017 at 02:10
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Christian Hopps <[email-masked]>
Subject: RE: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Wed, 20 Dec 2017 02:10:57 -0800 (PST)

    Hi authors,

    Major:
    -----
    "the provisioned MSD

[jeff] In ideal situation, the MSD capabilities should come from the HW SDK, while in a vertically integrated device, it might be vendor provisioned, however in a disaggregated case (HW and SW are from different vendors), ability to query HW for its MSD capabilities becomes crucial.
I have brought this point and discussed with BCM, Barefoot and few other HW vendors:
everyone agreed that would be a useful functionality, and would require quite simple API to add. Now it is up to their customers to demand an implementation, CP is standardized here, and, as usual, HW vendors have preference for a formal specification, that is stable.
For the time being, while there are no implementations we need to provide means to configure the value
Please also note, MSD configuration is covered by SR YANG model, in case the MSD value is communicated from HW(ro), it would go into operational data store

    -----

[jeff] always from outgoing link prospective, so the internals (ingress/egress/spitted MSD imposition) of a device are not of importance
    
    ==============
    Minor:
    "MSD of type 1 (IANA Registry), called Base MSD, is used to signal the total number of SIDs a node is capable of imposing,"
    I think that this is limited to MPLS-SID. It would be good to state this somewhere. e.g. :s/SIDs/MPLS SIDs
[jeff] No, it doesn’t have to, IPv6 data plane could be covered as well, however topic for future and would be done thru a separate draft.
    ----
    "MSD: Maximum SID Depth"
    IMHO, I'm not a big fan of the term "depth".
    I find that it can be mislead with RLD (Readable Label Depth Capability). I don't feel that pushing N SID requires looking/going deep into the packet. Looking at the surface of the incoming label looks enough.
    Obviously, the comment is late.
[jeff] Let’s agree to disagree on this one, the draft explicitly mentions RLD and spells out the difference. 
    
    Related comment: I don't find the definition to be explicit enough. e.g. You now need to define what "SID depth" is or provide or reference.
[jeff] Point taken, will include in the terminology section – would definition such as “ SID depth is a number of SID’s a node or a link on a node is capable of imposing” work? Any text you would like to propose?
    -----
    1.1.1.  Terminology

    I don't think that the "SHOULD" is related to interoperability. Hence a "should" is probably enough. 
[jeff] agreed, will change
    
    -----

       

[jeff]point taken, will update
    
    *2 (link and node MSD)
    ---
    § MSD Advertisement

    
[jeff]point taken, will update

    *2 (link and node MSD)
    -----

[jeff]point taken, will update
    ----
    "the ability to impose MSD stack of any depth"
    Were are not imposing an "MSD stack", but SID stack. Actually the SR architecture tends to use the term "list of segments" (or "ordered list of segments")

[jeff] agreed, will correct
    
    ----

[jeff] I don’t see how exposing MSD would increase the risk, please elaborate     
    ==============
    Nits:
    "supported by a node at node and/or link granularity"
    May be NEW: supported by a node or link
[jeff] declined, both could be signaled at the same time

[jeff] agreed, will correct
    ---

    

[jeff] agreed will correct
    -----

[jeff] agreed will correct
    -----
[jeff] agreed will correct
[jeff] agreed will correct
    
    Thanks
    Regards,
    --Bruno

---

From: <[email-masked]>
Date: Wed, 20 Dec 2017 20:09:32 +0000

Hi Jeff,

Thanks for the quick answers.
Looks good to me (pending the updated draft)
Please see inline [Bruno]

 > From: Jeff Tantsura [mailto:[email-masked]]
> 
 > Hi Bruno,
 > 
 >     I don't see the MSD as a provisioned value, but as a hardware capability. (Note that as a
 > network operator, I'd be happy to be able to provision this capability without changing the
 > hardware/software, but that has not been my experience so far.)
 >     Let's not put the burden on the network operator to configure this, while the node should know
 > the value better. (as a priori, in the absence this extension, the node would report an error if
 > instructed to push more labels than it is capable of). Especially for WAN routers, when Line Card
 > may be changed (e.g. upgraded), so this would requires the network operator to keep track of all
 > Line card change and update the MSD capability accordingly.(in which case, it may be just
 > simpler to configure it directly on the controler, rather than requiring IS-IS, OSPF, BGP-LS
 > protocol extensions, plus new features on all (involded) nodes)
 > 
 > [jeff] In ideal situation, the MSD capabilities should come from the HW SDK, while in a vertically
 > integrated device, it might be vendor provisioned, however in a disaggregated case (HW and SW
 > are from different vendors), ability to query HW for its MSD capabilities becomes crucial.
 > everyone agreed that would be a useful functionality, and would require quite simple API to add.
 > Now it is up to their customers to demand an implementation, CP is standardized here, and, as
 > usual, HW vendors have preference for a formal specification, that is stable.
 > Please also note, MSD configuration is covered by SR YANG model, in case the MSD value is
 > communicated from HW(ro), it would go into operational data store

[Bruno] Thanks for the clarification.
Regarding hardware API, I think we agree that for integrated equipment the control plane should know the MSD from day one. And for de-aggregated equipment, this is the medium term goal.
All I'm asking is not to write in stone (RFC) that configuration is the (only) way to get the MSD value. I think it should come from the hardware as default behavior, and could be overridden by configuration. So already the MSD part of the SR Yang module is excellent, thanks.

 > [jeff] always from outgoing link prospective, so the internals (ingress/egress/spitted MSD
 > imposition) of a device are not of importance

[Bruno] Excellent. Could this be specified in the draft?

[Bruno] A priori the SRv6 MSD would be advertised in a different MSD type (e.g. type 2), while the MSD type 1 is specifically for MPLS-SR, no?

 >     I find that it can be mislead with RLD (Readable Label Depth Capability). I don't feel that
 > pushing N SID requires looking/going deep into the packet. Looking at the surface of the
 > incoming label looks enough.
 
[Bruno] sure, no problem. I understand that this is a bit late to change the name. But possibly someone could have come up with the same MSD acronym, with a different word for D.

> 
 >     Related comment: I don't find the definition to be explicit enough. e.g. You now need to define
 > what "SID depth" is or provide or reference.
 > [jeff] Point taken, will include in the terminology section – would definition such as “ SID depth is
 > a number of SID’s a node or a link on a node is capable of imposing” work? Any text you would
 > like to propose?

[Bruno] looks good. Thanks.

 > [jeff] agreed, will change
 
[Bruno] ok, thanks.

 >     Text and figure do not match: the value field is either 'Sub-Type and value" as per the text, or
 > just "value without the Sub-type" as per the figure.
 > 

[Bruno] ok, thanks.

 >     It's not clear whether the text related to the MSD value is specific to the Sub-type 1 or to the
 > whole Link MSD Advertisment. (i.e. would restrict the usage of future sub-Types). May be using
 > two sections would help: one defining the Link MSD, one defining Sub-type 1. In which case the
 > last paragraph of the introduction may be move to this new sub-type 1 section.
 > 

[Bruno] ok, thanks.
 
 > [jeff]point taken, will update

[Bruno] ok, thanks.

 >     Were are not imposing an "MSD stack", but SID stack. Actually the SR architecture tends to
 > use the term "list of segments" (or "ordered list of segments")
 > 
 
[Bruno] ok, thanks.
 
 > [jeff] I don’t see how exposing MSD would increase the risk, please elaborate

[Bruno] As of today, different vendors have different MSD. Hence, by reading the MSD value, an attacker can guess the vendor of each node. One vendor (hopefully) increase its MSD over time, it may also provide some info regarding the software version running on the node.
Note that this is not new and already expressed in https://tools.ietf.org/html/rfc7981#section-5 ... which BTW also spell out my comment: "Specifications based on this mechanism need to describe the security  considerations around the disclosure and modification of their information."

[Bruno] sorry, I meant "supported by a node and/or link"
That's just a nits. I felt that the sentence could be simplified, especially the part 'by a node at node". But it's up to you.

 > [jeff] agreed, will correct

[Bruno] ok, thanks.

 > [jeff] agreed will correct

[Bruno] ok, thanks.

 > [jeff] agreed will correct

[Bruno] ok, thanks.

 > [jeff] agreed will correct

[Bruno] ok, thanks.

 > [jeff] agreed will correct

[Bruno] ok, thanks.

Thanks Jeff,

Cheers,
--Bruno
 > _____________________________________________________________________________
 > ____________________________________________
 >

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 20 Dec 2017 20:01:42 +0000

Ketan -

Thanx for the comments.
I think we do want to allow MSD support for values other than imposition values. We will revise the text so we are not restricted to only imposition cases.

  Les

> From: Ketan Talaulikar (ketant)
> Sent: Wednesday, December 20, 2017 1:51 AM
> To: Christian Hopps <[email-masked]>; [email-masked]
> I support this document and would like to ask the authors and WG to
> consider if we can expand the scope of this draft to not just "imposition" of
> the SID stack but also other similar limits related to other actions (e.g.
> reading, processing, etc.). With Segment Routing, we are coming across
> various actions that nodes need to do with the SID stack for different
> purposes and IMHO it would be useful to extend the MSD ability to cover
> those as they arise.
> 
> Thanks,
> Ketan
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 21 Dec 2017 00:32:44 +0000

As for the maximum label stack depth reading capability, it has been defined in https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc and https://tools.ietf.org/html/draft-ietf-isis-mpls-elc. Once the WGLC for https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label is finished, we will request the WGLC for the above two drafts.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Isis-wg [mailto:[email-masked]] 代表 Ketan Talaulikar (ketant)
> 发送时间: 2017年12月20日 17:51
> 收件人: Christian Hopps; [email-masked]
> 抄送: [email-masked]; [email-masked]
> 主题: Re: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07
> 
> Hello,
> 
> I support this document and would like to ask the authors and WG to consider if
> we can expand the scope of this draft to not just "imposition" of the SID stack
> but also other similar limits related to other actions (e.g. reading, processing,
> etc.). With Segment Routing, we are coming across various actions that nodes
> need to do with the SID stack for different purposes and IMHO it would be
> useful to extend the MSD ability to cover those as they arise.
> 
> Thanks,
> Ketan
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 21 Dec 2017 02:40:02 +0000

Hi Les,

If I understand it correctly, the MSD concept was originated from (https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#page-7) as described below:

"The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in the context of this document) that a PCC is capable of
   imposing on a packet."

Before considering expanding the semantics of the MSD concept as defined in the above PCE-SR draft, how about first considering renaming the capability of imposing the maximum number of labels so as to eliminate possible confusions, e.g., Writable Label-stack Depth (WLD) as opposed to the Readable Label-stack Depth (RLD) as defined in (https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc) and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc) ?

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Isis-wg [mailto:[email-masked]] 代表 Les Ginsberg (ginsberg)
> 发送时间: 2017年12月21日 4:02
> 收件人: Ketan Talaulikar (ketant); Christian Hopps; [email-masked]
> I think we do want to allow MSD support for values other than imposition
> values. We will revise the text so we are not restricted to only imposition cases.
> 
>   Les
> 
> 
> > consider if we can expand the scope of this draft to not just
> > "imposition" of the SID stack but also other similar limits related to other
> actions (e.g.
> > purposes and IMHO it would be useful to extend the MSD ability to
> > cover those as they arise.
> >
> > Thanks,
> > Ketan
> >
> > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-is
> > is-
> > segment-routing-msd
> >

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 21 Dec 2017 04:15:36 +0000

Hi Xu,

I am arguing the exact opposite of what you are saying. 

Let us leave ELC/ERLD aside since it is very limited to entropy label use-case and the proposed IGP/BGP-LS encoding is very specific to that. I am not sure if this is the time anymore to revisit that.

The MSD proposal came later and I support is since I've found its use to be much more widespread and the proposed IGP/BGP-LS protocol encoding to be very efficient as an implementer of these protocols. Hence the request to not restrict it to "writable" or "imposition" cases solely. It is also not just about "readability" - which by itself is pretty meaningless. Even ERLD is about "reading" and then "doing *something specific* about it" as discussed in ietf-spring-segment-routing-mpls. 

There is no second thoughts about the IGP ELC drafts and they are very useful and necessary. Just to be clear there is *no functional or operational change* that I am arguing for here. The discussion is purely on the way to handle these encodings and whether we can use the MSD mechanism in a generalized manner. 

Thanks,
Ketan

-----Original Message-----
From: Xuxiaohu [mailto:[email-masked]] 
Sent: 21 December 2017 08:10
To: Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: 答复: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07

Hi Les,

Best regards,
Xiaohu

> I think we do want to allow MSD support for values other than 
> imposition values. We will revise the text so we are not restricted to only imposition cases.
> 
>   Les
> 
> 
> > reading, processing, etc.). With Segment Routing, we are coming 
> > across various actions that nodes need to do with the SID stack for 
> > different purposes and IMHO it would be useful to extend the MSD 
> > ability to cover those as they arise.
> >
> > Thanks,
> > Ketan
> >

---

From: Paul Mattes <[email-masked]>
Date: Thu, 21 Dec 2017 19:59:27 +0000

I agree. The term "Maximum SID Depth" is ambiguous, and that it represents the maximum label-imposition depth rather than the maximum label-read depth is a historical artifact rather than an indication of its relative importance. Better that the names and acronyms should directly reflect these two distinct concepts.

        pdm

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Wednesday, December 20, 2017 8:40 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Isis-wg] 答复: WG Last Call for draft-ietf-isis-segment-routing-msd-07

Hi Les,

If I understand it correctly, the MSD concept was originated from (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-pce-segment-routing-11%23page-7&data=02%7C01%7Cpamattes%40microsoft.com%7C757ccfb23bad4b5e33bf08d5481c2f29%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636494208255322142&sdata=v7qCqA3gbbQSpEzlxNEVco0c9nHl1Cu6OelBNKnrTDA%3D&reserved=0) as described below:

Before considering expanding the semantics of the MSD concept as defined in the above PCE-SR draft, how about first considering renaming the capability of imposing the maximum number of labels so as to eliminate possible confusions, e.g., Writable Label-stack Depth (WLD) as opposed to the Readable Label-stack Depth (RLD) as defined in (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ospf-mpls-elc&data=02%7C01%7Cpamattes%40microsoft.com%7C757ccfb23bad4b5e33bf08d5481c2f29%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636494208255322142&sdata=ejx66Ba86eQyHLwEu6m13swIFqRsWGY%2BEBqCbjNtSI8%3D&reserved=0) and (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-isis-mpls-elc&data=02%7C01%7Cpamattes%40microsoft.com%7C757ccfb23bad4b5e33bf08d5481c2f29%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636494208255322142&sdata=JLWqLM9dZp7A5j6iDguRulWZVuHWMIUZpBDIBC81zfo%3D&reserved=0) ?

Best regards,
Xiaohu

> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
> > atracker.ietf.org%2Fdoc%2Fdraft-ietf-isis-segment-routing-msd%2F&dat
> > a=02%7C01%7Cpamattes%40microsoft.com%7C757ccfb23bad4b5e33bf08d5481c2
> > f29%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636494208255322142&
> > sdata=jAe9BGh48%2BW7M%2B54r%2FSS3YGDvoTtfpFroVNUx4fH4AE%3D&reserved=
> > 0
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
> > atracker.ietf.org%2Fipr%2Fsearch%2F%3Fsubmit%3Ddraft%26id%3Ddraft-ie
> > tf-is&data=02%7C01%7Cpamattes%40microsoft.com%7C757ccfb23bad4b5e33bf
> > 08d5481c2f29%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364942082
> > 55322142&sdata=1cpNKOYIByZn1tpR6%2FkoNtY3SuPQT01tM%2Bkd56x51lM%3D&re
> > served=0
> > is-
> > segment-routing-msd
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > .ietf.org%2Fmailman%2Flistinfo%2Fisis-wg&data=02%7C01%7Cpamattes%40m
> > icrosoft.com%7C757ccfb23bad4b5e33bf08d5481c2f29%7C72f988bf86f141af91
> > ab2d7cd011db47%7C1%7C0%7C636494208255322142&sdata=LLhn%2B5j%2BWIqR0R
> > PknF9Nh0dBgJm9sItDxGDkCmCDYCM%3D&reserved=0
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fisis-wg&data=02%7C01%7Cpamattes%40micro
> soft.com%7C757ccfb23bad4b5e33bf08d5481c2f29%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C636494208255322142&sdata=LLhn%2B5j%2BWIqR0RPknF9Nh0
> dBgJm9sItDxGDkCmCDYCM%3D&reserved=0
_______________________________________________
Isis-wg mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fisis-wg&data=02%7C01%7Cpamattes%40microsoft.com%7C757ccfb23bad4b5e33bf08d5481c2f29%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636494208255322142&sdata=LLhn%2B5j%2BWIqR0RPknF9Nh0dBgJm9sItDxGDkCmCDYCM%3D&reserved=0

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 21 Dec 2017 13:26:49 -0800

Paul,

Where is the ambiguity? MSD (type 1) is about imposition indeed, while RLD is about ability to read at a particular depth, very different concepts, used differently by the path computation logic. Please elaborate?

Thanks!   

Cheers,
Jeff

-----Original Message-----
From: Paul Mattes <[email-masked]>
Date: Thursday, December 21, 2017 at 11:59
To: Xuxiaohu <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "Ketan Talaulikar (ketant)" <[email-masked]>, Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Isis-wg] 答复:  WG Last Call for draft-ietf-isis-segment-routing-msd-07
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Thu, 21 Dec 2017 11:59:34 -0800 (PST)

            pdm
    
    -----Original Message-----
    From: Isis-wg [mailto:[email-masked]] On Behalf Of Xuxiaohu
    Sent: Wednesday, December 20, 2017 8:40 PM
    To: Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
    Cc: [email-masked]; [email-masked]
    Subject: [Isis-wg] 答复: WG Last Call for draft-ietf-isis-segment-routing-msd-07
    
    Hi Les,

    
    
    Best regards,
    Xiaohu

---

From: Paul Mattes <[email-masked]>
Date: Thu, 21 Dec 2017 22:27:51 +0000

This is a nit about terminology, not about the underlying concepts or specific definitions, which are quite clear.

I've been part of a number of frustrating discussions about the "maximum number of labels", where people seem to automatically assume that it is just one number. Sometimes they assume it is the imposition limit, and sometimes they assume it is the read depth. Calling the standardized maximum number of labels imposed "Maximum SID Depth" only spreads the confusion, since (just looking at the name) it could refer to imposition, reading or both. If I could turn back the clock, I would call MSD something like "Maximum label imposition depth" to make the distinction more obvious.

This is similar to the use of the term "traffic engineering" often implying "RSVP traffic engineering", which was harmless when RSVP was the only way to do it, but now is confusing.

        pdm

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Thursday, December 21, 2017 3:27 PM
To: Paul Mattes <[email-masked]>; Xuxiaohu <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Isis-wg] 答复: WG Last Call for draft-ietf-isis-segment-routing-msd-07

Paul,

Thanks!   

Cheers,
Jeff

-----Original Message-----
From: Paul Mattes <[email-masked]>
Date: Thursday, December 21, 2017 at 11:59
To: Xuxiaohu <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "Ketan Talaulikar (ketant)" <[email-masked]>, Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Isis-wg] 答复:  WG Last Call for draft-ietf-isis-segment-routing-msd-07
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Thu, 21 Dec 2017 11:59:34 -0800 (PST)

            pdm
    
    -----Original Message-----
    From: Isis-wg [mailto:[email-masked]] On Behalf Of Xuxiaohu
    Sent: Wednesday, December 20, 2017 8:40 PM
    To: Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
    Cc: [email-masked]; [email-masked]
    Subject: [Isis-wg] 答复: WG Last Call for draft-ietf-isis-segment-routing-msd-07
    
    Hi Les,

    
    
    Best regards,
    Xiaohu

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 22 Dec 2017 11:09:19 -0800

Hi Paul,

Thanks for your comments!

I do see your point, at his point in time “MSD” is a common term in the industry and changing would create more confusion than good.

IETF documents provide formal definition of the terms defined in it, so for all practical reasons, a person who’s unsure about the meaning of a term, rather than trying to guess its meaning, should read the draft/RFC that defines the term and use that definition.

I understand, my explanation doesn’t quite address your comment, I do hope, if such frustrating discussion happens again, you could point to the above paragraph.

If you feel – Terminology section need more/better definitions, I’d be very grateful for your suggestions. 

Cheers,
Jeff

-----Original Message-----
From: Paul Mattes <[email-masked]>
Date: Thursday, December 21, 2017 at 14:27
To: Jeff Tantsura <[email-masked]>, Xuxiaohu <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "Ketan Talaulikar (ketant)" <[email-masked]>, Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Isis-wg] 答复:  WG Last Call for draft-ietf-isis-segment-routing-msd-07

    
    
            pdm
    
    -----Original Message-----
    From: Jeff Tantsura [mailto:[email-masked]] 
    Sent: Thursday, December 21, 2017 3:27 PM
    To: Paul Mattes <[email-masked]>; Xuxiaohu <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
    Cc: [email-masked]; [email-masked]
    Subject: Re: [Isis-wg] 答复: WG Last Call for draft-ietf-isis-segment-routing-msd-07
    
    Paul,

    Thanks!   
    
    Cheers,
    Jeff
    
    -----Original Message-----
    From: Paul Mattes <[email-masked]>
    Date: Thursday, December 21, 2017 at 11:59
    To: Xuxiaohu <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "Ketan Talaulikar (ketant)" <[email-masked]>, Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
    Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: RE: [Isis-wg] 答复:  WG Last Call for draft-ietf-isis-segment-routing-msd-07
    Resent-From: <[email-masked]>
    Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
    Resent-Date: Thu, 21 Dec 2017 11:59:34 -0800 (PST)

                pdm
        
        -----Original Message-----
        From: Isis-wg [mailto:[email-masked]] On Behalf Of Xuxiaohu
        Sent: Wednesday, December 20, 2017 8:40 PM
        To: Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
        Cc: [email-masked]; [email-masked]
        Subject: [Isis-wg] 答复: WG Last Call for draft-ietf-isis-segment-routing-msd-07
        
        Hi Les,

        
        
        Best regards,
        Xiaohu

---

From: Paul Mattes <[email-masked]>
Date: Fri, 22 Dec 2017 20:18:25 +0000

Thank you. I know "MSD" is now taken to mean the label imposition limit, so we're stuck with it.

I would be happy to comment on any incomplete/unhelpful terminology definitions I run across.

        pdm

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Friday, December 22, 2017 1:09 PM
To: Paul Mattes <[email-masked]>; Xuxiaohu <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Isis-wg] 答复: WG Last Call for draft-ietf-isis-segment-routing-msd-07

Hi Paul,

Cheers,
Jeff

-----Original Message-----
From: Paul Mattes <[email-masked]>
Date: Thursday, December 21, 2017 at 14:27
To: Jeff Tantsura <[email-masked]>, Xuxiaohu <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "Ketan Talaulikar (ketant)" <[email-masked]>, Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Isis-wg] 答复:  WG Last Call for draft-ietf-isis-segment-routing-msd-07

    
    
            pdm
    
    -----Original Message-----
    From: Jeff Tantsura [mailto:[email-masked]] 
    Sent: Thursday, December 21, 2017 3:27 PM
    To: Paul Mattes <[email-masked]>; Xuxiaohu <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
    Cc: [email-masked]; [email-masked]
    Subject: Re: [Isis-wg] 答复: WG Last Call for draft-ietf-isis-segment-routing-msd-07
    
    Paul,

    Thanks!   
    
    Cheers,
    Jeff
    
    -----Original Message-----
    From: Paul Mattes <[email-masked]>
    Date: Thursday, December 21, 2017 at 11:59
    To: Xuxiaohu <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "Ketan Talaulikar (ketant)" <[email-masked]>, Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
    Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: RE: [Isis-wg] 答复:  WG Last Call for draft-ietf-isis-segment-routing-msd-07
    Resent-From: <[email-masked]>
    Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
    Resent-Date: Thu, 21 Dec 2017 11:59:34 -0800 (PST)

                pdm
        
        -----Original Message-----
        From: Isis-wg [mailto:[email-masked]] On Behalf Of Xuxiaohu
        Sent: Wednesday, December 20, 2017 8:40 PM
        To: Les Ginsberg (ginsberg) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
        Cc: [email-masked]; [email-masked]
        Subject: [Isis-wg] 答复: WG Last Call for draft-ietf-isis-segment-routing-msd-07
        
        Hi Les,

        
        
        Best regards,
        Xiaohu