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

["Osborne, Eric" <[e-mail]>]

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