Re: [TICTOC] Hello, everyone, I submit a new draft: draft-zhang-tictoc-pdv-lsp-00, Welcome comments and suggestions! Thank You!

[Yaakov Stein <[e-mail]>]

Junhui



I have read through your draft, and have some problems with it.



1.       You call the draft PDV-based PTP LSP Setup, but only a small portion of the text deals with PDV.

A lot deals with congestion and its detection, bandwidth reservation, recovery mechanisms, etc.

Yes, these are related in some way to PDV, but they aren't the same.

I would prefer a draft focusing on one issue and solving it, rather than touching on a lot of different issues.



2.       It is not clear whether this draft is trying to improve frequency distribution or time distribution.

If both, then please point out which parts relate to which.



3.       Many abbreviations are defined up at the top, but I don't see them ever used.

BC, MBB, and even PDV PTP LSP seem to have been thought up, but never made it into the text.



4.       The text says: The packet networks are Ethernet, MPLS, T-MPLS or  IP.

First, I guess you mean T-MPLS -> MPLS-TP. Second the rest of the text seems to be only for MPLS (TP?).



5.       But the third part networks(e.g.  MPLS  networks) may introduce the PDV noise.

I guess this should be    third part -> third party.

In any case, all networks, whatever party, have PDV.

Some of the effect of PDV may be reduced by on-path support, whether in your own network or someone elses.



These problems left me unsure as to what this draft aspires to achieve.



6.       I have a fundamental problem with the discussion of PDV metrics.

Saying "If the PDV exceeds network limits" is not meaningful for timing recovery, except for worst case behavior.

 G.8260 quoted in the draft merely states that for time recovery delay measurement is important,

while for frequency distribution delay variation may be more important.

It specifically leaves the definition of PDV metrics for further study.

As the author probably know, several metrics have been proposed,

but I know of no explicit relationship between any metric and actual recovery performance

(once again, I am not talking about very loose worst case limits).

I can easily create two scenarios, one with large very white PDV that can be easily filtered out,

and one with much smaller PDV but very low-pass, that strongly limits recovery.



7.       The whole section on LSP recovery left me confused. When switching over everything changes

and reconvergence may be lengthy. This hit may be much more significant than a slight PDV advantage

even were we know how to define a metric. The draft speaks of setting up 1+1 path protection.

This I really don't understand. How does the 1588 application know which path was taken ?

What rules out it receiving a few packets that traverse one path and then a few that traversed the other ?



8.       The security section is not relevant to the draft, and points to a non-normative section of 1588v2.

There is a lot of much more relevant security work that you could reference,

but since I don't understand what this draft is addressing, I can't tell what is needed here either.



Y(J)S