Subject: Re: [mpls] Progressing Resdience Time Measurement draft

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 29 Jan 2016 00:54:40 +0000

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:[email-masked]]
>Sent: Monday, December 14, 2015 7:23 PM
>To: Gregory Mirsky; [email-masked]; [email-masked]
>Cc: [email-masked]
>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
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/mpls

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 29 Jan 2016 10:29:51 -0500

Loa,

IMHO, this is a useful draft and shouldn’t be abandoned. However, I’m not
expert enough with timing protocols to have an informed opinion of its
readiness for WG LC, I’ll defer that to the authors or implementors. I
would also like to see Acee’s comments addressed.

Cheers,
Andy

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 31 Jan 2016 01:36:43 +0000

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:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Thursday, January 28, 2016 4:55 PM
To: Loa Andersson
Cc: [email-masked]; [email-masked]
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
>Working Group and authors, <chair hat off> As a matter of fact I 
>believe this document should be progressed.
><chair hat on>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 31 Jan 2016 12:50:49 +0000

Hi Greg, 
That sounds like a good plan.
Thanks,
Acee

On 1/30/16, 8:36 PM, "Gregory Mirsky" <[email-masked]> wrote:

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

---

From: Lou Berger <[email-masked]>
Date: Sun, 31 Jan 2016 09:27:07 -0500

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.