Re: [mpls] Progressing Residence Time Measurement draft

[Lou Berger <[e-mail]>]

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.

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

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

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
>