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

From: Lucy yong <[email-masked]>
Date: Wed, 6 May 2015 22:39:07 +0000

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 7 May 2015 05:48:54 +0000

Lucy,

Lots of thanks for a prompt and very detailed review.

Please see my personal comments (I did not discuss them with other authors yet) on some of your proposals for simplification inline below.

Regards,

Sasha

________________________________________

From: Lucy yong <[email-masked]>

Sent: Thursday, May 7, 2015 1:39 AM

To: [email-masked]; [email-masked]

Cc: [email-masked]

Subject: RE: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

Hi All,

[[Sasha]] I do not think so. One of the benefits of distributing RTM capabilities with IGP is that the CSPF algorithm can compute an explicit path to the tail-end node that minimizes the number of transit nodes that are not RTM-capable. This minimization, in its turn, makes clock synchronization more accurate since the influence of residence time in each of the transit nodes on the clock of synchronization is minimized (and potentially completely eliminated).

I do not see how RSVP-TE could provide this functionality all by itself, but I may be missing something.

[[Sasha]] This is probably possible, but may affect backward compatibility with nodes that do not support RTM (or at least make it more complicated)

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.[[Sasha]] I fully agree.

[[Sasha]] I fully agree with you that 2-step clock is quite complex. However, it is quite useful if forwarding HW is not capable of modifying the packet that is transmitted via one of its ports very close to the moment when it is actually transmitted (definitely after it has been extracted from the egress queue for transmission). The 2-step clock addresses this issue by limiting the HW functionality to just taking the timestamp at this moment (much simpler!) and passing it to SW  handling so that, e.g., it can be inserted into the so-called "follow-up" packet.

Not sure if this explanation really helps.

Regards,

Lucy

---

From: Markus Jork <[email-masked]>
Date: Tue, 19 May 2015 03:07:21 +0000

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.

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?

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?

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: Tue, 26 May 2015 13:45:08 +0000

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:[email-masked]] On Behalf Of Lucy yong
> Sent: Wednesday, May 06, 2015 6:39 PM
> 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:
> 
> 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.
> 
> 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:
> 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.
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 28 May 2015 08:41:11 +0000

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

All the caveats that were discussed in the context of the TICTOC draft apply here as well.

In particular, all packets of timing flows must follow the same path, thus ruling out LAG, ECMP, entropy labels, etc.
Protection switching must also be avoided, since undetected delay changes are more detrimental than not receiving timing packets and going into holdover.

Y(J)S

---

From: "Osborne, Eric" <[email-masked]>
Date: Thu, 28 May 2015 10:51:40 +0000

Inline

...

> > 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.
> 
> In particular, all packets of timing flows must follow the same path, thus
> ruling out LAG, ECMP, entropy labels, etc.
> Protection switching must also be avoided, since undetected delay changes
> are more detrimental than not receiving timing packets and going into
> holdover.

Guh.  I remember being in the room for some of this stuff.  This essentially boils down to TE LSPs specifically for timing.  This sort of stuff needs to be spelled out very particularly, since these sorts of things aren't obvious to everyone who might consider the technology.  It doesn't have to be much, but IMO this draft needs "here's how to design your network around this protocol".

eric