Subject: Review of draft-ietf-mpls-residence-time-12

From: Robert Sparks <[email-masked]>
Date: Wed, 11 Jan 2017 07:48:23 -0800

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

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 11 Jan 2017 10:36:18 -0800

Hi Robert,
thank you for your the most detailed review and helpful comments. I'll
prepare -13 version based on your suggestions.
Please find my responses, notes in-lined and tagged GIM>>

Regards,
Greg

> header, ACH, and G-ACh message.
GIM>> Will use "message" as you've suggested. Indeed, interchangeable use
of packet and message does confuse.

> implementation choices would be welcome.
GIM>> G.8013, formerly Y.1731, does not require or define when a time stamp
must be taken. The document only indicates during which process time been
taken, e.g.:
TxTimeStampf: Timestamp at the transmission time of ETH-DM frame
 RxTimeStampf: Timestamp at the time of receiving frame with ETH-DM request
information.
What is important for quality of measurement is for an implementation to be
reading and writing in timestamp at the same stage of processing the RTM
packet and avoiding queuing/de-queuing in order to avoid impact of jitter
caused by queuing/de-queuing.

> 7 before section 3's 5th bullet makes any sense.
GIM>> Will try.

> treatment to the other places where you talk about future IANA
GIM>> Will make changes accordingly.

>   Section 10: "most of" -> "most of all"
GIM>> Thank you, will make the changes.

> into a specific section in IEEE.1588.2008].
GIM>>  Will add the reference.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Jan 2017 08:13:28 -0800

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

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Jan 2017 10:03:57 -0800

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

---

From: Robert Sparks <[email-masked]>
Date: Wed, 18 Jan 2017 12:34:11 -0600

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 <[email-masked] 
> <mailto:[email-masked]>> 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
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Reviewer: Robert Sparks
>         <https://trac.ietf.org/trac/gen/wiki/GenArtfaq
>         <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 18 Jan 2017 18:45:44 +0000

We need to be clear that you only need to be consistent within a node. 
There is no requirement for any two nodes along the path use the same 
bit in the packet as an epoch, nor do the input and output need to 
physically use the same bit in the packet as the epoch provided they 
know and account for the wire delay that corresponds to those bits. So 
long as we accurately measure the local variable delay that is all that 
is required.

- Stewart

On 18/01/2017 18:34, Robert Sparks wrote:
> 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?)
>
>> 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
>>
>>     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
>>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Jan 2017 11:25:07 -0800

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 <[email-masked]>
wrote:

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 18 Jan 2017 22:51:59 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 18, 2017 at 1:25 PM
To: Robert Sparks <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> wrote:

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer: Robert Sparks
Review result: Ready with Nits

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 19 Jan 2017 07:44:13 -0800

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) <[email-masked]> 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 <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> To: Robert Sparks <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <draft-ietf-mpls-residence-
> [email-masked]>, "[email-masked]" <[email-masked]>
>> "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
>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 19 Jan 2017 15:57:56 +0000

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:[email-masked]]
Sent: Thursday, January 19, 2017 7:44 AM
To: Acee Lindem (acee)
Cc: Robert Sparks; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Les Ginsberg (ginsberg); [email-masked]; 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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks,
Acee

Hi Robert,

Regards,
Greg

RjS

Regards,
Greg

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 19 Jan 2017 08:00:30 -0800

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) <[email-masked]

> 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.
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Thursday, January 19, 2017 7:44 AM
> *To:* Acee Lindem (acee)
> *Cc:* Robert Sparks; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Les Ginsberg
> (ginsberg); [email-masked]; 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
> *From: *mpls <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Wednesday, January 18, 2017 at 1:25 PM
> *To: *Robert Sparks <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [mpls] Review of draft-ietf-mpls-residence-time-12
>
>
>
> Hi Robert,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 20 Jan 2017 16:10:43 -0000

I agree with Hannes on this.

However, if the document was to highlight strongly that the data is "a
non-routing related capability" (if that's what we believe!) and stress that the
information "that does not change frequently" (perhaps with some explanation of
"frequently") I believe that might help everyone.

Adrian

> >we have taken turns long-time ago to advertise non-routing
> >related information which is only relevant to controllers
> >(l2bundles comes into mind ;-)).
> >
> >while it would have been nice to get at least notice that
> >an IS-IS extension is being worked on (i mean prior to
> >IANA asking for expert review :-/ ) i see no reason why we
> >should hold this back. - we can argue perhaps whether it should
> >be part of GENAPP or ROUTERCAP TLVs, but i cannot see the
> >sky falling to advertise a non-routing related capability,
> >that does not change frequently.
> 
> I agree but was just trying to get a better idea of precisely how the
> information will be used and whether interface is the right granularity.

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 21 Jan 2017 18:42:53 +0000

Eric, Les and all,
I concur with Eric. RTM capability is a kind of TE information that the path computation algorithm must take into account when selecting the suitable path for the LSP that would be used for RTM purposes.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: Eric Gray [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 10:32 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Uma Chunduri <[email-masked]>; John E Drake <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Alexander Vainshtein <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Abhay Roy (akr) <[email-masked]>; Robert Sparks <[email-masked]>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

                It's nice to have a good discussion about technical aspects of a proposed standard, even late in the game.

                But I have some difficulty is seeing how this usage is "clearly not TE information."

This information should allow the head-end of an LSP to select a path based on desirable interface capabilities.  For the purposes of accurate time information, the best path may not also be the shortest path.  Is this not exactly what traffic engineering is about?

As far as extending this argument to the ability to advertise additional link capabilities, I can easily imagine scenarios where that would make sense.  But nobody is suggesting that every LSR (or router for that matter) either must have this capability for every scenario, or that - having the capability - it would need to be turned on.

If there is an application or use-case out there that might require advertising every conceivable interface capability, then vendors will want to take a look at the size of the opportunity represented by that and make a decision as to whether or not to support this.

--
Eric

From: mpls [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, January 19, 2017 3:11 PM
To: Uma Chunduri <[email-masked]<mailto:[email-masked]>>; John E Drake <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Abhay Roy (akr) <[email-masked]<mailto:[email-masked]>>; Robert Sparks <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Uma -

I readily admit S-BFD descriptors are - strictly speaking - a violation of the "non-routing info" policy - this was publicly acknowledged at the time the drafts were written. The exception was justified on the basis that:

  o IGPs are BFD clients
  o The S-BFD discriminator information is unique and extremely modest in size

What we have here is a proposal to start advertising non-routing related interface attribute information. There is nothing special or unique about RTM - it is simply one of many interface attributes which are generic in nature. Having agreed to advertise RTM in the IGPs, how would you then determine what other interface attributes should/should not be advertised by the IGPs? Take a look at your favorite vendors box and see how many interface attributes can be configured.
It is also concerning that - when using the IGPs - we flood information which must be stored on every node even though the use case for it is limited to a much smaller subset.

I think we can and should be smarter in this regard - and given the extensive work being done to enhance manageability I would like to see us benefit from this.

The authors of draft-ietf-mpls-residence-time clearly had some thoughts in this regard - which is why they proposed to use RFC 6823 (GENAPP) in IS-IS to advertise the information -but the proposal in the draft is flawed in this regard. If we were to head in the "application" direction I would propose a much more generic "application" which is capable of advertising many interface attributes. However this goes back to my original concern - whether we want to use IGPs to flood interface attribute information unrelated to routing even if it is segregated under an application. Remember that RFC 6823 stipulates that a separate instance of the protocol (a la RFC 6822) be used for such cases.

   Les

From: Uma Chunduri [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 11:41 AM
To: Les Ginsberg (ginsberg); John E Drake; Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky
Cc: Abhay Roy (akr); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Sparks; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

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:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, January 19, 2017 9:25 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: Abhay Roy (akr) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Sparks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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:[email-masked]]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg (ginsberg)
Cc: Robert Sparks; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 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:[email-masked]]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Robert Sparks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Abhay Roy (akr) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi John,

From: John E Drake <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 19, 2017 at 10:43 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>, Greg Mirsky <[email-masked]<mailto:[email-masked]>>, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Cc: Robert Sparks <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Abhay Roy (akr)" <[email-masked]<mailto:[email-masked]>>
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:[email-masked]]
Sent: Thursday, January 19, 2017 11:38 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Robert Sparks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Abhay Roy (akr) <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 19, 2017 at 10:15 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Robert Sparks <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Abhay Roy (akr)" <[email-masked]<mailto:[email-masked]>>
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: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: Greg Mirsky [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 6:01 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Robert Sparks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Abhay Roy (akr) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Les,

Regards,
Greg

On Thu, Jan 19, 2017 at 7:57 AM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> 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.

   Les

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, January 19, 2017 7:44 AM
To: Acee Lindem (acee)
Cc: Robert Sparks; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>; Abhay Roy (akr)

Hi Acee,

Regards,
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

Hi Robert,

Regards,
Greg

RjS

Regards,
Greg

Regards,
Greg

---

From: Mach Chen <[email-masked]>
Date: Sun, 22 Jan 2017 01:46:13 +0000

Sounds like a good idea, I agree with this.

Best regards,
Mach

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Saturday, January 21, 2017 12:11 AM
To: 'Acee Lindem (acee)'; 'Hannes Gredler'; 'Les Ginsberg (ginsberg)'; 'John E Drake'; 'Alexander Vainshtein'; 'Greg Mirsky'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; 'Abhay Roy (akr)'; 'Robert Sparks'
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

However, if the document was to highlight strongly that the data is "a non-routing related capability" (if that's what we believe!) and stress that the information "that does not change frequently" (perhaps with some explanation of
"frequently") I believe that might help everyone.

Adrian

> >we have taken turns long-time ago to advertise non-routing related 
> >information which is only relevant to controllers (l2bundles comes 
> >into mind ;-)).
> >
> >while it would have been nice to get at least notice that an IS-IS 
> >extension is being worked on (i mean prior to IANA asking for expert 
> >review :-/ ) i see no reason why we should hold this back. - we can 
> >argue perhaps whether it should be part of GENAPP or ROUTERCAP TLVs, 
> >but i cannot see the sky falling to advertise a non-routing related 
> >capability, that does not change frequently.
> 

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Jan 2017 09:29:55 +0000

Les

This is very much path related and thus it is entirely reasonable to 
carry it in the IGP.

If you want a path that gives you the highest quality time transfer, 
then you need to select a path on which every hop provides the 
information needed to minimise the uncertainly in the transit delay 
time. Thus I can see paths being chosen on the basis that every hop 
performs this service. That is obviously a routing decision and thus it 
is reasonable to advertise the information needed to make that decision 
in the routing protocol.

- Stewart

On 19/01/2017 21:08, Les Ginsberg (ginsberg) wrote:
>
> John –
>
> The text you have excerpted below was trying to say two things:
>
> 1)If you want to advertise this in the IGPs the OSPF style proposal is 
> much better from an implementation standpoint than the IS-IS GENAPP 
> proposal
>
> 2)There is a larger question as to whether we should be using the IGPs 
> for this at all
>
> Statement #1 should not be interpreted to imply that I am advocating 
> using the IGPs. J
>
> That said, we “ALWAYS” end up choosing using the IGPs to do this sort 
> of thing – not because it is the “RIGHT” thing to do architecturally – 
> but because it is so convenient.
>
> I am just asking for folks to pause and think about this a bit more 
> from an architectural perspective.
>
> Les
>
> *From:*John E Drake [mailto:[email-masked]]
> *Sent:* Thursday, January 19, 2017 12:20 PM
> *To:* Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander 
> Vainshtein; Greg Mirsky
> [email-masked]; [email-masked]; 
> [email-masked]; Abhay Roy (akr)
> *Subject:* RE: [mpls] Review of draft-ietf-mpls-residence-time-12
>
> Les,
>
> Comments inline.
>
> Yours Irrespectively,
>
> John
>
> *From:*Les Ginsberg (ginsberg) [mailto:[email-masked]]
> *Sent:* Thursday, January 19, 2017 12:25 PM
> *To:* John E Drake <[email-masked] <mailto:[email-masked]>>; 
> Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>>; Alexander 
> Vainshtein <[email-masked] 
> <mailto:[email-masked]>>; Greg Mirsky 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* Robert Sparks <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Abhay Roy (akr) <[email-masked] 
> <mailto:[email-masked]>>
> *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.
>
> *//*
>
> */[JD] RTM support as defined in the draft would be used to provide 
> extremely accurate time synchronization in an MPLS network so I would 
> suggest that all nodes in such a network would be using it and hence 
> that it does belong in the IGP.  As an aside, advertising it in the 
> IGP facilitates incremental or partial deployment.  Your yesterday’s 
> email supports this: /*
>
> *//*
>
> */“It would seem more appropriate to treat RTM information either as:/*
>
> *//*
>
> */o an extension to link attribute information already advertised by 
> the IGPs (as has been suggested for OSPF) - which would suggest in 
> IS-IS a sub-TLV of TLV 22(et al)/*
>
> *//*
>
> */or/*
>
> *//*
>
> ·*/As an interface attribute independent of routing protocols which 
> could be retrieved utilizing network management tools”/*
>
> Les
>
> *From:*John E Drake [mailto:[email-masked]]
> *Sent:* Thursday, January 19, 2017 8:54 AM
> *To:* Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les 
> Ginsberg (ginsberg)
> *Cc:* Robert Sparks; [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 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:[email-masked]]
> *Sent:* Thursday, January 19, 2017 11:47 AM
> *To:* John E Drake <[email-masked] <mailto:[email-masked]>>; 
> Alexander Vainshtein <[email-masked] 
> <mailto:[email-masked]>>; Greg Mirsky 
> <[email-masked] <mailto:[email-masked]>>; Les Ginsberg 
> (ginsberg) <[email-masked] <mailto:[email-masked]>>
> *Cc:* Robert Sparks <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Abhay Roy (akr) <[email-masked] 
> <mailto:[email-masked]>>
> *From: *John E Drake <[email-masked] <mailto:[email-masked]>>
> *Date: *Thursday, January 19, 2017 at 10:43 AM
> *To: *Acee Lindem <[email-masked] <mailto:[email-masked]>>, Alexander 
> Vainshtein <[email-masked] 
> <mailto:[email-masked]>>, Greg Mirsky 
> <[email-masked] <mailto:[email-masked]>>, "Les Ginsberg 
> (ginsberg)" <[email-masked] <mailto:[email-masked]>>
> *Cc: *Robert Sparks <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, 
> "[email-masked] 
> <mailto:[email-masked]>" 
> <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>, "Abhay Roy 
> (akr)" <[email-masked] <mailto:[email-masked]>>
> *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:[email-masked]]
>     *Sent:* Thursday, January 19, 2017 11:38 AM
>     *To:* Alexander Vainshtein <[email-masked]
>     <mailto:[email-masked]>>; Greg Mirsky
>     <[email-masked] <mailto:[email-masked]>>; Les
>     Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Robert Sparks <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; Abhay Roy (akr) <[email-masked]
>     <mailto:[email-masked]>>
>     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?
>
>     *From: *Alexander Vainshtein <[email-masked]
>     <mailto:[email-masked]>>
>     *Date: *Thursday, January 19, 2017 at 10:15 AM
>     *To: *Greg Mirsky <[email-masked]
>     <mailto:[email-masked]>>, "Les Ginsberg (ginsberg)"
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc: *Acee Lindem <[email-masked] <mailto:[email-masked]>>, Robert
>     Sparks <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>,
>     "[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, "Abhay Roy (akr)" <[email-masked]
>     <mailto:[email-masked]>>
>     *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: +972-39266302
>
>         Cell: +972-549266302
>
>         <mailto:[email-masked]>
>
>         *From:*Greg Mirsky [mailto:[email-masked]]
>         *Sent:* Thursday, January 19, 2017 6:01 PM
>         *To:* Les Ginsberg (ginsberg) <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:* Acee Lindem (acee) <[email-masked]
>         <mailto:[email-masked]>>; Robert Sparks <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>;
>         [email-masked]
>         <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>; Abhay Roy (akr) <[email-masked]
>         <mailto:[email-masked]>>
>         On Thu, Jan 19, 2017 at 7:57 AM, Les Ginsberg (ginsberg)
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Greg –
>
>             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.
>
>             *From:*Greg Mirsky [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             *Cc:* Robert Sparks; [email-masked] <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>;
>             [email-masked]
>             <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>; Les Ginsberg
>             (ginsberg); [email-masked]
>             <mailto:[email-masked]>; Abhay Roy (akr)
>
>
>             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)
>             <[email-masked] <mailto:[email-masked]>> 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 <[email-masked]
>             <mailto:[email-masked]>> on behalf of Greg Mirsky
>             <[email-masked] <mailto:[email-masked]>>
>             *To: *Robert Sparks <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc: *"[email-masked] <mailto:[email-masked]>"
>             <[email-masked] <mailto:[email-masked]>>, "[email-masked]
>             <mailto:[email-masked]>" <[email-masked]
>             <mailto:[email-masked]>>,
>             "[email-masked]
>             <mailto:[email-masked]>"
>             <[email-masked]
>             <mailto:[email-masked]>>,
>             "[email-masked] <mailto:[email-masked]>" <[email-masked]
>             <mailto:[email-masked]>>
>                 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
>                 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
>                     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.
>                     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
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Jan 2017 09:37:49 +0000

Sorry Acee, I accidentally deleted your message about paths that support 
this.

Yes, to get the best quality time transfer you would pick paths such 
that all hops had the property. If you did not do that you can undo all 
the good work you did on the other hops by one that introduces variable 
delay. Indeed if the variability has certain systematic characteristics 
it can be very hard to use other techniques to minimise its impact on 
the quality of the time transfer. An example of a characteristic that is 
very difficult to address by other means is a very slowly increasing delay.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Jan 2017 09:38:44 +0000

Exactly

S

On 21/01/2017 18:42, Alexander Vainshtein wrote:
>
> Eric, Les and all,
>
> I concur with Eric. RTM capability is a kind of TE information that 
> the path computation algorithm must take into account when selecting 
> the suitable path for the LSP that would be used for RTM purposes.
>
> My 2c,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> *From:*Eric Gray [mailto:[email-masked]]
> *Sent:* Thursday, January 19, 2017 10:32 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; Uma Chunduri 
> <[email-masked]>; John E Drake <[email-masked]>; Acee 
> Lindem (acee) <[email-masked]>; Alexander Vainshtein 
> <[email-masked]>; Greg Mirsky <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Abhay 
> Roy (akr) <[email-masked]>; Robert Sparks <[email-masked]>
> It’s nice to have a good discussion about technical aspects of a 
> proposed standard, even late in the game.
>
> But I have some difficulty is seeing how this usage is “clearly not TE 
> information.”
>
> This information should allow the head-end of an LSP to select a path 
> based on desirable interface capabilities.  For the purposes of 
> accurate time information, the best path may not also be the shortest 
> path.  Is this not exactly what traffic engineering is about?
>
> As far as extending this argument to the ability to advertise 
> additional link capabilities, I can easily imagine scenarios where 
> that would make sense.  But nobody is suggesting that every LSR (or 
> router for that matter) either must have this capability for every 
> scenario, or that – having the capability – it would need to be turned on.
>
> If there is an application or use-case out there that might require 
> advertising every conceivable interface capability, then vendors will 
> want to take a look at the size of the opportunity represented by that 
> and make a decision as to whether or not to support this.
>
> --
>
> Eric
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Les Ginsberg 
> (ginsberg)
> *Sent:* Thursday, January 19, 2017 3:11 PM
> *To:* Uma Chunduri <[email-masked] 
> <mailto:[email-masked]>>; John E Drake <[email-masked] 
> <mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked] 
> <mailto:[email-masked]>>; Alexander Vainshtein 
> <[email-masked] 
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Abhay Roy (akr) 
> <[email-masked] <mailto:[email-masked]>>; Robert Sparks 
> <[email-masked] <mailto:[email-masked]>>
> Uma –
> I readily admit S-BFD descriptors are – strictly speaking - a 
> violation of the “non-routing info” policy – this was publicly 
> acknowledged at the time the drafts were written. The exception was 
> justified on the basis that:
>
> o IGPs are BFD clients
>
> What we have here is a proposal to start advertising non-routing 
> related interface attribute information. There is nothing special or 
> unique about RTM – it is simply one of many interface attributes which 
> are generic in nature. Having agreed to advertise RTM in the IGPs, how 
> would you then determine what other interface attributes should/should 
> not be advertised by the IGPs? Take a look at your favorite vendors 
> box and see how many interface attributes can be configured.
>
> It is also concerning that – when using the IGPs – we flood 
> information which must be stored on every node even though the use 
> case for it is limited to a much smaller subset.
>
> I think we can and should be smarter in this regard – and given the 
> extensive work being done to enhance manageability I would like to see 
> us benefit from this.
>
> The authors of draft-ietf-mpls-residence-time clearly had some 
> thoughts in this regard – which is why they proposed to use RFC 6823 
> (GENAPP) in IS-IS to advertise the information –but the proposal in 
> the draft is flawed in this regard. If we were to head in the 
> “application” direction I would propose a much more generic 
> “application” which is capable of advertising many interface 
> attributes. However this goes back to my original concern – whether we 
> want to use IGPs to flood interface attribute information unrelated to 
> routing even if it is segregated under an application. Remember that 
> RFC 6823 stipulates that a separate instance of the protocol (a la RFC 
> 6822) be used for such cases.
>
> Les
>
> *From:*Uma Chunduri [mailto:[email-masked]]
> *Sent:* Thursday, January 19, 2017 11:41 AM
> *To:* Les Ginsberg (ginsberg); John E Drake; Acee Lindem (acee); 
> Alexander Vainshtein; Greg Mirsky
> *Cc:* Abhay Roy (akr); [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Robert Sparks; 
> [email-masked] <mailto:[email-masked]>
> >This is clearly not TE information –..
>
> https://tools.ietf.org/html/rfc7883(Les, you co-authored the same!!)
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Les Ginsberg 
> (ginsberg)
> *Sent:* Thursday, January 19, 2017 9:25 AM
> *Cc:* Abhay Roy (akr) <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Robert Sparks 
> <[email-masked] <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>