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

[Gregory Mirsky <[e-mail]>]

Hi Eric,
many thanks for your help and kind consideration. We'll upload the draft shortly and will wait for the call from Loa on the next step.

	Regards,
		Greg

-----Original Message-----
From: Osborne, Eric [mailto:[e-mail]] 
Sent: Thursday, July 02, 2015 6:59 AM
To: Gregory Mirsky; Yaakov Stein ([e-mail]); Lucy yong; [e-mail]; [e-mail]; Markus Jork
Cc: [e-mail]
Subject: RE: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

Hi Greg-

  Sorry for the late reply, I've been buried in stuff.  I took a quick scan of the diffs and they look good to me.




eric

> -----Original Message-----
> From: Gregory Mirsky [mailto:[e-mail]]
> Sent: Thursday, June 25, 2015 5:02 PM
> To: Gregory Mirsky; Osborne, Eric; Yaakov Stein ([e-mail]); 
> Lucy yong; [e-mail]; mpls- 
> [e-mail]; Markus Jork
> Cc: [e-mail]
> Subject: RE: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt
> 
> 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; draft- 
> [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]; mpls- 
> [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