Re: [mpls] Review of draft-ietf-mpls-residence-time-12

[Stewart Bryant <[e-mail]>]

Well one scenario is that you would use SR to create the synchronization 
path, in which case you would need it to be in the IGP and flooded.

Stewart


On 19/01/2017 19:40, Uma Chunduri wrote:
>
> I support advertising this in IGP.
>
> >This is clearly not TE information –..
>
> >I do not see the IGPs as the appropriate mechanism to flood generic 
> interface capabilities
>
> We have instances where both the above are not met and we flooded 
> information.
>
> https://tools.ietf.org/html/rfc7883(Les, you co-authored the same!!)
>
> https://tools.ietf.org/html/rfc7880
>
> --
>
> Uma C.
>
> *From:*mpls [mailto:[e-mail]] *On Behalf Of *Les Ginsberg 
> (ginsberg)
> *Sent:* Thursday, January 19, 2017 9:25 AM
> *To:* John E Drake <[e-mail]>; Acee Lindem (acee) 
> <[e-mail]>; Alexander Vainshtein 
> <[e-mail]>; Greg Mirsky <[e-mail]>
> *Cc:* Abhay Roy (akr) <[e-mail]>; [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]; Robert Sparks 
> <[e-mail]>; [e-mail]
> *Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12
>
> John –
>
> For me, this raises the age-old question of when it is/is not 
> appropriate to use IGPs for flooding information.
>
> This is clearly not TE information – you just happen to be using this 
> in conjunction with MPLS – but it is a generic capability. I do not 
> see the IGPs as the appropriate mechanism to flood generic interface 
> capabilities. It also, as Acee has pointed out, results in flooding 
> information to all nodes in the domain when only a few care about it.
>
> Les
>
> *From:*John E Drake [mailto:[e-mail]]
> *Sent:* Thursday, January 19, 2017 8:54 AM
> *To:* Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les 
> Ginsberg (ginsberg)
> *Cc:* Robert Sparks; [e-mail] <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; Abhay Roy (akr)
> *Subject:* RE: [mpls] Review of draft-ietf-mpls-residence-time-12
>
> Acee,
>
> Relying on an omniscient controller is a non-starter in general and in 
> particular because the protocol by which it would learn each node’s 
> RTM capabilities and distribute them to the other nodes is undefined.  
> Further, one of the ways by which an omniscient controller learns a 
> node’s capabilities is by snooping the link/state database.
>
> Yours Irrespectively,
>
> John
>
> *From:*Acee Lindem (acee) [mailto:[e-mail]]
> *Sent:* Thursday, January 19, 2017 11:47 AM
> *To:* John E Drake <[e-mail] <mailto:[e-mail]>>; 
> Alexander Vainshtein <[e-mail] 
> <mailto:[e-mail]>>; Greg Mirsky 
> <[e-mail] <mailto:[e-mail]>>; Les Ginsberg 
> (ginsberg) <[e-mail] <mailto:[e-mail]>>
> *Cc:* Robert Sparks <[e-mail] 
> <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; Abhay Roy (akr) <[e-mail] 
> <mailto:[e-mail]>>
> *Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12
>
> Hi John,
>
> *From: *John E Drake <[e-mail] <mailto:[e-mail]>>
> *Date: *Thursday, January 19, 2017 at 10:43 AM
> *To: *Acee Lindem <[e-mail] <mailto:[e-mail]>>, Alexander 
> Vainshtein <[e-mail] 
> <mailto:[e-mail]>>, Greg Mirsky 
> <[e-mail] <mailto:[e-mail]>>, "Les Ginsberg 
> (ginsberg)" <[e-mail] <mailto:[e-mail]>>
> *Cc: *Robert Sparks <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>, 
> "[e-mail] 
> <mailto:[e-mail]>" 
> <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>, "Abhay Roy 
> (akr)" <[e-mail] <mailto:[e-mail]>>
> *Subject: *RE: [mpls] Review of draft-ietf-mpls-residence-time-12
>
>     Acee,
>
>     We discussed all of this with you over a year ago and used your
>     guidance in adding the indication of RTM capability to OSPF.
>
> I’m sorry but I focused mainly on the OSPF protocol aspects then and 
> didn’t question the use case. This question came up in the IS-IS WG 
> discussions.
>
> Thanks,
>
> Acee
>
>     Yours Irrespectively,
>
>     John
>
>     *From:*Acee Lindem (acee) [mailto:[e-mail]]
>     *Sent:* Thursday, January 19, 2017 11:38 AM
>     *To:* Alexander Vainshtein <[e-mail]
>     <mailto:[e-mail]>>; Greg Mirsky
>     <[e-mail] <mailto:[e-mail]>>; Les
>     Ginsberg (ginsberg) <[e-mail] <mailto:[e-mail]>>
>     *Cc:* Robert Sparks <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>;
>     [e-mail]
>     <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; Abhay Roy (akr) <[e-mail]
>     <mailto:[e-mail]>>
>     *Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12
>
>     I guess what we were trying to envision the use case and whether
>     it makes sense for all the nodes in the IGP routing domain to have
>     this information. Would the LSP ingress LSR only need to if the
>     egress LSR supports RTM and it is best effort recording for
>     transit LSRs in the path?
>
>     Additionally, if it is needed in the IGPs, should there also be a
>     BGP-LS Link Attribute TLV proposed?
>
>     Thanks,
>
>     Acee
>
>     *From: *Alexander Vainshtein <[e-mail]
>     <mailto:[e-mail]>>
>     *Date: *Thursday, January 19, 2017 at 10:15 AM
>     *To: *Greg Mirsky <[e-mail]
>     <mailto:[e-mail]>>, "Les Ginsberg (ginsberg)"
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc: *Acee Lindem <[e-mail] <mailto:[e-mail]>>, Robert
>     Sparks <[e-mail] <mailto:[e-mail]>>,
>     "[e-mail] <mailto:[e-mail]>" <[e-mail]
>     <mailto:[e-mail]>>, "[e-mail]
>     <mailto:[e-mail]>" <[e-mail]
>     <mailto:[e-mail]>>,
>     "[e-mail]
>     <mailto:[e-mail]>"
>     <[e-mail]
>     <mailto:[e-mail]>>,
>     "[e-mail] <mailto:[e-mail]>" <[e-mail]
>     <mailto:[e-mail]>>, "[e-mail]
>     <mailto:[e-mail]>" <[e-mail]
>     <mailto:[e-mail]>>, "Abhay Roy (akr)" <[e-mail]
>     <mailto:[e-mail]>>
>     *Subject: *RE: [mpls] Review of draft-ietf-mpls-residence-time-12
>
>         Hi all,
>
>         I concur with Greg: from my POV an interoperable solution
>         should not depend on an omniscient NMS client distributing
>         information about capabilities of each node to each other node.
>
>         Regards,
>
>         Sasha
>
>         Office: [phone]
>
>         Cell: [phone]
>
>         Email: [e-mail]
>         <mailto:[e-mail]>
>
>         *From:*Greg Mirsky [mailto:[e-mail]]
>         *Sent:* Thursday, January 19, 2017 6:01 PM
>         *To:* Les Ginsberg (ginsberg) <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc:* Acee Lindem (acee) <[e-mail]
>         <mailto:[e-mail]>>; Robert Sparks <[e-mail]
>         <mailto:[e-mail]>>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>;
>         [e-mail]
>         <mailto:[e-mail]>;
>         [e-mail] <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; Abhay Roy (akr) <[e-mail]
>         <mailto:[e-mail]>>
>         *Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12
>
>         Hi Les,
>
>         I believe that IGP extensions to advertise RTM capability are
>         required.
>
>         Regards,
>
>         Greg
>
>         On Thu, Jan 19, 2017 at 7:57 AM, Les Ginsberg (ginsberg)
>         <[e-mail] <mailto:[e-mail]>> wrote:
>
>             Greg –
>
>             I am having trouble understanding your response.
>
>             The question we are raising is whether we should extend
>             the IGPs to support advertising RTM capability – an
>             alternative being to retrieve the capability via network
>             management.
>
>             Saying that the IGP functionality is optional and/or
>             wouldn’t always be advertised doesn’t really answer the
>             question of whether we should or should not define the IGP
>             extensions.
>
>             Could you respond more directly to this point?
>
>             Les
>
>             *From:*Greg Mirsky [mailto:[e-mail]
>             <mailto:[e-mail]>]
>             *Sent:* Thursday, January 19, 2017 7:44 AM
>             *To:* Acee Lindem (acee)
>             *Cc:* Robert Sparks; [e-mail] <mailto:[e-mail]>;
>             [e-mail] <mailto:[e-mail]>;
>             [e-mail]
>             <mailto:[e-mail]>;
>             [e-mail] <mailto:[e-mail]>; Les Ginsberg
>             (ginsberg); [e-mail]
>             <mailto:[e-mail]>; Abhay Roy (akr)
>
>
>             *Subject:* Re: [mpls] Review of
>             draft-ietf-mpls-residence-time-12
>
>             Hi Acee,
>
>             the draft defines optional functionality. If an operator
>             has no use neither for PTP's Transparent Clock, nor RTM
>             itself as performance metric, then RTM sub-TLV would not
>             be included and thus it would not be flooded. Of course,
>             it be right to reflect RTM capability through YANG data
>             model, thus allowing SDN scenario you've described.
>
>             Regards,
>
>             Greg
>
>             On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee)
>             <[e-mail] <mailto:[e-mail]>> wrote:
>
>             Hi Greg,
>
>             Although it is a bit late, we’ve had some discussions
>             amongst the IS-IS and OSPF chairs and are wondering
>             whether the interface capability belongs in the IGPs. This
>             will be flooded throughout the entire routing domain – is
>             it really needed on every node or will it the RTM testing
>             be initiated from an omniscient NMS client that would know
>             the capabilities of each node or easily query them using
>             YANG?
>
>             Thanks,
>
>             Acee
>
>             *From: *mpls <[e-mail]
>             <mailto:[e-mail]>> on behalf of Greg Mirsky
>             <[e-mail] <mailto:[e-mail]>>
>             *Date: *Wednesday, January 18, 2017 at 1:25 PM
>             *To: *Robert Sparks <[e-mail]
>             <mailto:[e-mail]>>
>             *Cc: *"[e-mail] <mailto:[e-mail]>"
>             <[e-mail] <mailto:[e-mail]>>, "[e-mail]
>             <mailto:[e-mail]>" <[e-mail]
>             <mailto:[e-mail]>>,
>             "[e-mail]
>             <mailto:[e-mail]>"
>             <[e-mail]
>             <mailto:[e-mail]>>,
>             "[e-mail] <mailto:[e-mail]>" <[e-mail]
>             <mailto:[e-mail]>>
>             *Subject: *Re: [mpls] Review of
>             draft-ietf-mpls-residence-time-12
>
>                 Hi Robert,
>
>                 thank you for the most expedient review and comments.
>                 I'll make changes in Section 2 per your suggestion.
>
>                 Regards,
>
>                 Greg
>
>                 On Wed, Jan 18, 2017 at 10:34 AM, Robert Sparks
>                 <[e-mail] <mailto:[e-mail]>>
>                 wrote:
>
>                 The changes all look good.
>
>                 I still think you should say something in the document
>                 about what "the time of packet arrival" and
>                 "transmission" means, and call out the point you made
>                 about being careful to not introduce apparent jitter
>                 by not making those measurements consistently. (The
>                 definitions you point to in your earlier mail from
>                 G.8013 don't really help - they just say "time of
>                 packet arrival". Again, the first and last bit are
>                 likely to be several nanoseconds apart so I think it
>                 matters. Perhaps you're saying it doesn't matter as
>                 long as each node is consistent (there will be error
>                 in the residence time measurement, but it will be
>                 constant at each node, so the sum of errors will be
>                 constant, and the clocks will be ok?)
>
>                 Please look at the new first paragraph of section 2 -
>                 there's a mix of "as case" and "in case" that should
>                 be made consistent. I suspect it would be easiest to
>                 simply say "referred to as using a one-step clock" and
>                 "referred to as using a two-step clock" or similar.
>
>                 RjS
>
>                 On 1/18/17 12:03 PM, Greg Mirsky wrote:
>
>                     Hi Robert,
>
>                     Sasha Vainshtein came with elegant idea to address
>                     disconnection between discussion of one-step and
>                     two-step modes that you've pointed out. We've
>                     moved Section 7 as sub-section into Section 2 now.
>                     Attached are updated diff and the proposed new
>                     version -13.
>
>                     Regards,
>
>                     Greg
>
>                     On Wed, Jan 18, 2017 at 8:13 AM, Greg Mirsky
>                     <[e-mail]
>                     <mailto:[e-mail]>> wrote:
>
>                     Hi Robert,
>
>                     once again, thank you for your thorough review and
>                     the most detailed comments. I've prepared updated
>                     version and would greatly appreciate if you review
>                     the changes and let us know whether your comments
>                     been addressed. Attached are diff and the new version.
>
>                     Regards,
>
>                     Greg
>
>                     On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks
>                     <[e-mail]
>                     <mailto:[e-mail]>> wrote:
>
>                         Reviewer: Robert Sparks
>                         Review result: Ready with Nits
>
>                         I am the assigned Gen-ART reviewer for this
>                         draft. The General Area
>                         Review Team (Gen-ART) reviews all IETF
>                         documents being processed
>                         by the IESG for the IETF Chair.  Please treat
>                         these comments just
>                         like any other last call comments.
>
>                         For more information, please see the FAQ at
>                         <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
>                         Document: draft-ietf-mpls-residence-time-12
>                         Reviewer: Robert Sparks
>                         Review Date: 2017-01-10
>                         IETF LC End Date: 2017-01-17
>                         IESG Telechat date: 2017-02-02
>
>                         Summary: Ready (with nits) for publication as
>                         a Proposed Standard
>
>                         I have two primary comments. I expect both are
>                         rooted in the authors
>                         and working group knowing what the document
>                         means instead of seeing
>                         what
>                         it says or doesn't say:
>
>                         1) The document is loose with its use of
>                         'packet', and where TTLs
>                         appear when
>                         they are discussed. It might be helpful to
>                         rephrase the text that
>                         speaks
>                         of RTM packets in terms of RTM messages that
>                         are encoded as G-ACh
>                         messages and
>                         not refer to packets unless you mean the whole
>                         encapsulated packet
>                         with MPLS
>                         header, ACH, and G-ACh message.
>
>                         2) Since this new mechanic speaks in terms of
>                         fractional nanoseconds,
>                         some
>                         discussion of what trigger-point you intend
>                         people to use for taking
>                         the
>                         precise time of a packet's arrival or
>                         departure seems warranted. (The
>                         first and
>                         last bit of the whole encapsulated packet
>                         above are going to appear at
>                         the
>                         physical layer many nanoseconds apart at OC192
>                         speeds if I've done the
>                         math
>                         right). It may be obvious to the folks
>                         discussing this, but it's not
>                         obvious
>                         from the document.  If it's _not_ obvious and
>                         variation in technique
>                         is
>                         expected, then some discussion about issues
>                         that might arise from
>                         different
>                         implementation choices would be welcome.
>
>                         The rest of these are editorial nits:
>
>                         It would help to pull an overview description
>                         of the difference
>                         between
>                         one-step and two-step much earlier in the
>                         document. I suggest in the
>                         overview
>                         in section 2. Otherwise, the reader really has
>                         to jump forward and
>                         read section
>                         7 before section 3's 5th bullet makes any sense.
>
>                         In section 3, "IANA will be asked" should be
>                         made active. Say "This
>                         document
>                         asks IANA to" and point to the IANA
>                         consideration section. Apply
>                         similar
>                         treatment to the other places where you talk
>                         about future IANA
>                         actions.
>
>                         There are several places where there are
>                         missing words (typically
>                         articles or
>                         prepositions). You're less likely to end up
>                         with misinterpretations
>                         during the
>                         RFC Editor phase if you provide them before
>                         the document gets that far
>                         in the
>                         process. The spots I found most disruptive
>                         were these (this is not
>                         intended to
>                         be exhaustive):
>
>                           Section 3: "set 1 according" -> "set to 1
>                         according"
>                           Section 3: "the Table 19 [IEEE..." -> "Table
>                         19 of [IEEE..."
>                           Section 4.2: "Detailed discussion of ...
>                         modes in Section 7."
>                         -> "Detailed discussion of ... modes appears
>                         in Section 7."
>                           Section 10: "most of" -> "most of all"
>
>                         In Setion 3.1 at "identity of the source
>                         port", please point into the
>                         document
>                         that defines this identity and its
>                         representation. I suspect this is a
>                         pointer
>                         into a specific section in IEEE.1588.2008].
>