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

    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 protected]] 
    Sent: Thursday, December 21, 2017 3:27 PM
    To: Paul Mattes <[email protected]>; Xuxiaohu <[email protected]>; 
Les Ginsberg (ginsberg) <[email protected]>; Ketan Talaulikar (ketant) 
<[email protected]>; Christian Hopps <[email protected]>; [email protected]
    Cc: [email protected]; [email protected]
    Subject: Re: [Isis-wg] 答复: WG Last Call for 
draft-ietf-isis-segment-routing-msd-07
    
    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 protected]>
    Date: Thursday, December 21, 2017 at 11:59
    To: Xuxiaohu <[email protected]>, "Les Ginsberg (ginsberg)" 
<[email protected]>, "Ketan Talaulikar (ketant)" <[email protected]>, Christian 
Hopps <[email protected]>, "[email protected]" <[email protected]>
    Cc: "[email protected]" <[email protected]>, 
"[email protected]" 
<[email protected]>
    Subject: RE: [Isis-wg] 答复:  WG Last Call for 
draft-ietf-isis-segment-routing-msd-07
    Resent-From: <[email protected]>
    Resent-To: <[email protected]>, <[email protected]>, 
<[email protected]>, <[email protected]>
    Resent-Date: Thu, 21 Dec 2017 11:59:34 -0800 (PST)
    
        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 protected]] On Behalf Of Xuxiaohu
        Sent: Wednesday, December 20, 2017 8:40 PM
        To: Les Ginsberg (ginsberg) <[email protected]>; Ketan Talaulikar 
(ketant) <[email protected]>; Christian Hopps <[email protected]>; 
[email protected]
        Cc: [email protected]; [email protected]
        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:
        
        "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://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
        
        > -----邮件原件-----
        > 发件人: Isis-wg [mailto:[email protected]] 代表 Les Ginsberg 
        > (ginsberg)
        > 发送时间: 2017年12月21日 4:02
        > 收件人: Ketan Talaulikar (ketant); Christian Hopps; [email protected]
        > 抄送: [email protected]; [email protected]
        > 主题: Re: [Isis-wg] WG Last Call for 
        > draft-ietf-isis-segment-routing-msd-07
        > 
        > 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
        > 
        > 
        > > -----Original Message-----
        > > From: Ketan Talaulikar (ketant)
        > > Sent: Wednesday, December 20, 2017 1:51 AM
        > > To: Christian Hopps <[email protected]>; [email protected]
        > > Cc: [email protected]; [email protected]
        > > Subject: 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
        > >
        > > -----Original Message-----
        > > From: Isis-wg [mailto:[email protected]] On Behalf Of 
        > > Christian Hopps
        > > Sent: 20 December 2017 14:03
        > > To: [email protected]
        > > Cc: [email protected]; [email protected]
        > > Subject: [Isis-wg] WG Last Call for
        > > draft-ietf-isis-segment-routing-msd-07
        > >
        > >
        > > The authors have asked for and we are starting a WG Last Call on
        > >
        > >  
        > > 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
        > >
        > > which will last an extended 4 weeks to allow for year-end PTO 
patterns.
        > >
        > > An IPR statement exists:
        > >
        > >
        > > 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
        > >
        > > Authors please reply to the list indicating whether you are aware 
of 
        > > any
        > > *new* IPR.
        > >
        > > Thanks,
        > > Chris.
        > >
        > > _______________________________________________
        > > Isis-wg mailing list
        > > [email protected]
        > > 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
        > 
        > _______________________________________________
        > Isis-wg mailing list
        > [email protected]
        > 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 protected]
        
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
        
    
    
    


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

Reply via email to