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

[Gregory Mirsky <[e-mail]>]

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:[e-mail]] On Behalf Of Gregory Mirsky
Sent: Thursday, June 18, 2015 12:27 PM
To: Osborne, Eric; Yaakov Stein ([e-mail]); Lucy yong; [e-mail]; [e-mail]; Markus Jork
Cc: [e-mail]
Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

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:[e-mail]] On Behalf Of Osborne, Eric
Sent: Tuesday, May 26, 2015 6:45 AM
To: Lucy yong; [e-mail]; [e-mail]
Cc: [e-mail]
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".

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


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.

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?




eric



> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Lucy yong
> Sent: Wednesday, May 06, 2015 6:39 PM
> To: [e-mail]; mpls- 
> [e-mail]
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls

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