Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

From: Gregory Mirsky <[email-masked]>
Date: Mon, 8 Jun 2015 04:42:38 +0000

Hi Eric,
many thanks for your thorough review and very helpful comments. We greatly appreciate your suggestions and some already in next version we're preparing. Please find some notes in-line and tagged GIM>>.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Osborne, Eric
Sent: Tuesday, May 26, 2015 6:45 AM
To: Lucy yong; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

I finally had some time to read this draft as well.  I agree with Lucy's general comments - this doc seems to achieve the goal it sets out.  Is it useful?  Not to me.  It seems like it's maybe for mobile networks?  I'm not an expert in the matter of timing so this review assumes that the actual timing procedures work.  My comments below are about how RTM fits into the larger picture.

General question: does RTM work over LAGs?  They're a flavor of ECMP in some respects.  If not, that needs to be spelled out somewhere.

It might be worth spending a few lines in the introduction talking about who might want to use this and what sort of restrictions it places on a network design.

Specific comments:

Section 4 talks about LDP and ECMP and the problems it causes.  It suggests that one solution is to disable ECMP used for RTM LSPs.  This seems like it would only make the problem worse; the more you separate the OAM path from the actual data path, the less useful your measurements are.  You may be far better off just saying "don't do RTM with MP2P LSPs".
GIM>> You're absolutely correct, value of RTM, like of all OAM, is when "in-line" rule been ensured. PTP is bi-directional and must be co-routed. If IP paths between A and B, when ECMP disabled, considered co-routed, then wouldn't LDP LSPs between A and B be as well co-routed?

Section 4.1, "LSAs sent from an interface".  This doesn't line up with how link-state protocols work.  There should be no property of an LSA dependant upon the interface that it's sent out (OK, modulo type 9 opaques and stuff).  I think this really wants to say "LSAs sent from a router which describe a particular interface".  
GIM>> Gladly taken in.

Section 4.5 could use a review from an ISIS expert.  I scanned the GENINFO TLV and it's not clear to me how RTM will associate a capability with a specific interface between peers.  What if I have several interfaces between A-B and only some of them support RTM?  I'm not saying this isn't covered, but that it's not clear to me as a casual reader of Section 4.5 and GENINFO.
GIM>> Thank you, will reach to ISIS WG for review.

Section 4.6, "egress LSR's egress interface".  So if I have

A---B---C---D---E---F

a TE LSP B->E and IP nodes A and F, is section 4.6 really referring to the E->F interface?

What if I have a TE LSP A->F?  Where's the 'egress LSR's egress interface'?
What if I have a TE LSP A->C, C->E and E->F?  Or LDP A->C, TE C->E, LDP E->F?

GIM>> Attached is slide to reflect the relationships and roles of nodes and interfaces. The challenge is to turn it into ASCII-art. I'll give it a fair try.

eric

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Lucy yong
> Sent: Wednesday, May 06, 2015 6:39 PM
> To: [email-masked]; mpls- 
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls] MPLS_RT review of 
> draft-mirsky-mpls-residence-time- 06.txt
> 
> Hi All,
> 
> I reviewed draft-mirsky-mpls-residence-time as the member of MPLS 
> Review Team and have the following comments:
> 
> is the document coherent?
> 
> Yes. It specifies how MPLS supports residence time measurement.
> 
> is it useful (ie, is it likely to be actually useful in operational networks)?
> 
> The document claims that such measurement can improve the accuracy of 
> clock synchronization across the network. I am not an operator and 
> author and not sure how useful this feature provides compared to the 
> complexity adding to.
> 
> is the document technically sound?
> Yes. The draft provides a detail solution in control plane and data 
> plane to achieve this purpose.
> 
> is the document ready to be considered for WG adoption?
> Yes. The document states the problem clearly and provides a solution 
> to address this problem.
> 
> IMHO:  after adopting it as the WG draft, the WG should further 
> evaluate if control plane and data plane solution can be simplified. 
> The areas may be
> considered:
> 1) Do we have to use IGP to announce node RTM capability? Can RSVP-TE 
> resolve the issue by itself?
> 2) Will possible to enhance RRO to serve RSO purpose instead of 
> carrying both RRO and RSO in the message?
> 3) Since this feature is designed for the LSP that is used for clock 
> synchronization, such LSPs are not majority, so it should be option in 
> LSP setup. Make that very clear.
> 4) two-step clock mode is quite complex. The description in Section 7 
> is not clear to me why this mode is necessary.
> 
> Regards,
> Lucy
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

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

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 8 Jun 2015 04:44:10 +0000

Hi Lucy,
many thanks for your thorough review and kind consideration of our work. We're preparing next version and will share with reviewers by end of this week.

	Regards,
		Greg

-----Original Message-----
From: Lucy yong [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2015 3:39 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

Hi All,

I reviewed draft-mirsky-mpls-residence-time as the member of MPLS Review Team and have the following comments:

The document claims that such measurement can improve the accuracy of clock synchronization across the network. I am not an operator and author and not sure how useful this feature provides compared to the complexity adding to. 

is the document technically sound? 
Yes. The draft provides a detail solution in control plane and data plane to achieve this purpose.

is the document ready to be considered for WG adoption?
Yes. The document states the problem clearly and provides a solution to address this problem.  

IMHO:  after adopting it as the WG draft, the WG should further evaluate if control plane and data plane solution can be simplified. The areas may be considered:
1) Do we have to use IGP to announce node RTM capability? Can RSVP-TE resolve the issue by itself?
2) Will possible to enhance RRO to serve RSO purpose instead of carrying both RRO and RSO in the message?
3) Since this feature is designed for the LSP that is used for clock synchronization, such LSPs are not majority, so it should be option in LSP setup. Make that very clear.
4) two-step clock mode is quite complex. The description in Section 7 is not clear to me why this mode is necessary. 

Regards,
Lucy

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 8 Jun 2015 05:00:59 +0000

Hi Markus,
thank you for your thorough review and very helpful comments. We're working on the next version and will share with the reviewers by week's end. Please find couple notes in-line and tagged GIM>>.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Markus Jork
Sent: Monday, May 18, 2015 8:07 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

I was asked to review draft-mirsky-mpls-residence-time-06.txt as part of the review team process.

The document provides justification for why residence time measurement for MPLS LSPs may be useful and coherently describes the procedure for performing it. However, I could not understand the 2-step process from reading this document.
GIM>> We'll keep on improving the text.

The proposed rsvp extensions look technically sound. Though I do question the extra complexity introduced for keeping track of the RTM capable LSRs (using the RTM_SET object). While I generally understand the value in supporting incremental deployment of new features, I do wonder how much value there is in doing partial residence time measurements for random sub-sections of an LSP? Are the incomplete measurements done in such a scenario really worth the added protocol complexity?
GIM>> We believe that incremental improvements are improvements nevertheless and bring better quality of clock synchronization.

The document talks about the difficulties of applying the measurement procedure to LDP networks due to ECMP. Maybe it should also discuss potential difficulties with rsvp when there is link aggregation/bundling which could lead to load-balancing over multiple egress interfaces?
GIM>> LAG may be better handled by the Conversation-sensitive frame collection and distribution section 6.6 in new revision of 802.1AX as likely to be the case for PTP data. Will look into the link bundling.

I can't really comment on the usefulness of the document as I'm not familiar with the time synchronization protocols and use cases.
Under the assumption that partial residence time measurements for an LSP are useful, I think the document is ready for WG adoption.

-Markus

---

From: "Osborne, Eric" <[email-masked]>
Date: Mon, 8 Jun 2015 15:43:07 +0000

...
trimmed, one comment
.... 
> Section 4 talks about LDP and ECMP and the problems it causes.  It suggests
> that one solution is to disable ECMP used for RTM LSPs.  This seems like it
> would only make the problem worse; the more you separate the OAM path
> from the actual data path, the less useful your measurements are.  You may
> be far better off just saying "don't do RTM with MP2P LSPs".
> GIM>> You're absolutely correct, value of RTM, like of all OAM, is when "in-
> line" rule been ensured. PTP is bi-directional and must be co-routed. If IP
> paths between A and B, when ECMP disabled, considered co-routed, then
> wouldn't LDP LSPs between A and B be as well co-routed?

I can't imagine disabling EMCP and running LDP.  That takes so much out of the network operator's toolbox.  But your customers may have different needs.
Even if you disable ECMP in LDP/IGP, you still have LAGs and other technlogies.  Are you going to outlaw those too?  Again, what you want to do may work for the people you want to do it to, but I've never worked in or with a network that could get away with single-path routing.

eric

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 18 Jun 2015 19:27:06 +0000

Hi Lucy, Markus, Eric, and Yaakov,
many thanks for your kind consideration and thoughtful comments. Attached are new version of the draft and diff that highlights changes proposed. Greatly appreciate your review and hope that you find your comments being addressed, mostly if not completely.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Osborne, Eric
Sent: Tuesday, May 26, 2015 6:45 AM
To: Lucy yong; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

Specific comments:

A---B---C---D---E---F

eric

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 25 Jun 2015 21:02:15 +0000

Dear Reviewers,
would greatly appreciate your comments on proposed changes. Please let us know whether  your comments, suggestions been addressed in -07 version of the draft.

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Thursday, June 18, 2015 12:27 PM
To: Osborne, Eric; Yaakov Stein ([email-masked]); Lucy yong; [email-masked]; [email-masked]; Markus Jork
Cc: [email-masked]
Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Osborne, Eric
Sent: Tuesday, May 26, 2015 6:45 AM
To: Lucy yong; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

Specific comments:

A---B---C---D---E---F

eric