Re: [mpls] Progressing Residence Time Measurement draft

[Lou Berger <[e-mail]>]

Greg,

See below.

On 1/31/2016 8:28 PM, Gregory Mirsky wrote:
> Hi Lou,
> thank you for your thorough review of RTM and thoughtful comments on proposed RSVP-TE extension. Greatly appreciate helping us to reach to DetNet community for consideration of RTM and helpful inputs. Please find my notes in-lined and tagged GIM>>.
>
> 	Regards,
> 		Greg
>
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Sunday, January 31, 2016 7:08 AM
> To: Alexander Vainshtein
> Cc: [e-mail]; Acee Lindem (acee); Gregory Mirsky; Loa Andersson; [e-mail]
> Subject: Re: [mpls] Progressing Residence Time Measurement draft
>
> Sasha,
>     See below.
>
> On 1/31/2016 9:50 AM, Alexander Vainshtein wrote:
>> Lou,
>> First of all, lots of thanks for the comments - both for ones you have sent and - in advance - for one dealing with RSVP-TE that you've promised to send.
>>
>> Second, I wonder which TE LSPs beyond ones set up by RSVP-TE ones you have in mind.
>>
>> If  you are speaking about statically configured LSPs (and these, in a way, are always TE LSPs), I do not foresee any problem with extending RTM to them.
> Yes.  Or controller based.
> GIM>> Would you suggest to consider extension to PCEP in this document or that could be in the new document?

I think a new document.  This document should just allow for it and at
most suggest it as an example.  (Personal opinion.)

>
>> If, however, you are speaking about LSPs that have been set up using Segment Routing (SR), I doubt RTM can work with these because these LSPs could (and, most probably, probably would) include multiple ECMP sub-paths between specific "pinned" nodes.
> Haven't really dug in enough on SR to have an opinion...
> GIM>> SR is very interesting scenario and may be the justification to use generic IGP TLV to advertise RTM capability. But RTM handling in SR data plane, as I think of it, requires additional consideration. Could that be in the new document?

Same answer.  But feel more strongly on this one.

Thanks,
Lou
>> So I am not sure extending (even at the level of a declaration without providing any details) applicability of RTP to all TE LSPs is the right way to go.
> I think the fully pinned/ER case should be covered -- and that's what I was really trying to refer to. 
> GIM>> I think that fully ER path would provide the best result for PTP and thus RTM but pinning RTM-capable nodes with loosely-routed segments in between may still be useful scenario. I'll ask Stefano to comment on that from PTP point of view.
>
> Thanks,
> Lou
>
>> Regards,
>> Sasha
>>
>> Office: [phone]
>> Cell:      [phone]
>> Email:   [e-mail]
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Sunday, January 31, 2016 4:27 PM
>> To: Acee Lindem (acee); Gregory Mirsky; Loa Andersson; 
>> [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [mpls] Progressing Resdience Time Measurement draft
>>
>> So this thread triggered me to reread the draft.  I don't really have any time sync experience, so won't be commenting on those aspects of the draft - but I did just send a message off to the DetNet WG as they be interested in using this at some point and are likely to have some folks with 1588 knowledge. 
>>
>> The following comment is independent of which LSA types are used, as discussed below, but others may feel it impacts the choice.
>>
>> Should the solution really scoped to just RSVP controlled TE LSPs?  It seems to me it should work for any TE LSP, and any TE LSP setup mechanism that can provide the participating nodes with the required information.  Does this make sense?
>>
>> I think the following changes are one way to make this change:
>> OLD
>>
>>     The scope of
>>    this document is on LSPs instantiated using RSVP-TE [RFC3209 <https://tools.ietf.org/html/rfc3209>] because
>>    the LSP's path can be determined.
>> NEW
>>
>>     The scope of this document is on TE LSPs, e.g., those  instantiated using
>>      RSVP-TE [RFC3209 <https://tools.ietf.org/html/rfc3209>], because the LSP's path can be determined.
>>
>> And add text that describes the following in a new section, perhaps at
>> 4.6 or 4.8 "Non-RSVP controlled LSPs"
>>   When the TE LSP is controlled via mechanisms other than RSVP-TE, the following information needs to be provided to the RTM capable nodes along the LSP path:
>>    - RTM role (ingress, transit, egress)
>>    - RTM neighbors
>>    - RTM hop counts (as needed)
>>   - Anything else I'm sure I missed!
>>   The method used to convey this information is out of scope of this document.
>>
>> I have an RSVP specific comment that I'll send separately.
>>
>> Thanks,
>> Lou
>>
>> PS I think this is important work and hope to see it completed soon.
>>
>> On 1/31/2016 7:50 AM, Acee Lindem (acee) wrote:
>>> Hi Greg,
>>> That sounds like a good plan.
>>> Thanks,
>>> Acee
>>>
>>> On 1/30/16, 8:36 PM, "Gregory Mirsky" <[e-mail]> wrote:
>>>
>>>> Hi Acee,
>>>> thank you for your thorough review and OSPF insights.
>>>> I've updated reference to RFC 7684 in the new -01 version.
>>>> When we were starting work on RTM we intended to address LDP 
>>>> signaled IP/MPLS networks as well and that, as I recall, was the 
>>>> reason to use more generic IGP TLVs rather than TE-specific. Since 
>>>> LDP drifted out of scope, I agree, use of TE advertisements is more 
>>>> suitable. We'll work on that and share new update with you and the IGP WGs.
>>>>
>>>> 	Regards,
>>>> 		Greg
>>>>
>>>> -----Original Message-----
>>>> From: mpls [mailto:[e-mail]] On Behalf Of Acee Lindem
>>>> (acee)
>>>> Sent: Thursday, January 28, 2016 4:55 PM
>>>> To: Loa Andersson
>>>> Cc: [e-mail]; [e-mail]
>>>> Subject: Re: [mpls] Progressing Resdience Time Measurement draft
>>>>
>>>> I’ve read the subject draft and think it offers a useful function to 
>>>> facilitate more accurate time synchronization in NTP/PTP deployments.
>>>> One question I have is why the capability is signaled in the generic 
>>>> IGP TLV LSAs and LSPs rather than the TE advertisements when the 
>>>> document is scoped to RSVP-TE [RFC3209] LSPs? One reason I ask is 
>>>> that we are waiting on implementations of the OSPFv3 Extended LSAs 
>>>> draft. Having said that,
>>>> OSPFv2 and OSPFv3 have separate registry for the TLV LSAs and 
>>>> section
>>>> 8 should reflect this. Also, OSPF Prefix/Link Attributes is now RFC 7684.
>>>>
>>>> Thanks,
>>>> Acee
>>>>> -----Original Message-----
>>>>> From: Loa Andersson [mailto:[e-mail]]
>>>>> Sent: Monday, December 14, 2015 7:23 PM
>>>>> To: Gregory Mirsky; [e-mail]; [e-mail]
>>>>> Cc: [e-mail]
>>>>> Subject: Re: [mpls] Progressing Resdience Time Measurement draft 
>>>>> Working Group and authors, <chair hat off> As a matter of fact I 
>>>>> believe this document should be progressed.
>>>>> <chair hat on>
>>>>> This draft has been a working group document since early August, 
>>>>> but there has been no discussion on the document on the wg mailing list.
>>>>> There are of course two ways if interpreting this.
>>>>> - there is total agreement on the draft
>>>>> - there is no intrest in the draft
>>>>> I have no basis to decide which is the case.
>>>>> Can we plese have at least a few (non-author) comments on the 
>>>>> mailing list if it is time to start the wglc.
>>>>> /Loa
>>>>> mpls wg co-chair
>>>>> On 2015-12-15 07:21, Gregory Mirsky wrote:
>>>>> Dear Chairs of the MPLS WG,
>>>>>> authors of the Residence Time Measurement in MPLS Network draft 
>>>>>> believe that all comments received during the WG adoption call 
>>>>>> been addressed.
>>>>>> Thus, authors would like to ask the WG Chairs to consider WG LC as 
>>>>>> the next step.
>>>>>>                 Regards,
>>>>>>                                 Greg 
>>>>>> _______________________________________________
>>>>>> mpls mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>> _______________________________________________
>>>> mpls mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
>