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

[Alexander Vainshtein <[e-mail]>]

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 <[e-mail]>

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

To: [e-mail]; [e-mail]

Cc: [e-mail]

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:

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?

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

2) Will possible to enhance RRO to serve RSO purpose instead of carrying both RRO and RSO in the message?

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

4) two-step clock mode is quite complex. The description in Section 7 is not clear to me why this mode is necessary.

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