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

Yes, I see that SOME of this draft is about detecting performance degradation and switching to a secondary LSP.
I just don't see anything about how to detect such performance degradation and how to hitlessly switch to the backup.

The drafts in the MPLS WG about delay and loss are completely irrelevant to timing flows.

Y(J)S

From: fu.xihua@zte.com.cn [mailto:fu.xihua@zte.com.cn]
Sent: Wednesday, November 16, 2011 16:22
To: Yaakov Stein
Cc: tictoc@ietf.org; tictoc-bounces@ietf.org; zhang.junhui1@zte.com.cn
Subject: Re: Re: [TICTOC] Hello, everyone, I submit a new draft: draft-zhang-tictoc-pdv-lsp-00, Welcome comments and suggestions! Thank You!

Hi Yaakov,

I read through your comments.

In my understand, this draft is talking how to switch PTP LSP to secondary PTP LSP when the performance (delay,jitter and loss) of primary LSP is going worse.

It propose the slave dected the performace in the dataplane and notify performance failure to master, then master can switch it to secondary PTP LSP.

You may refere to some drafts in MPLS WG about the delay-loss TE.

draft-fuxh-mpls-delay-loss-te-framework

Best Regards,

Xihua Fu

Yaakov Stein <yaakov_s@rad.com>
发件人:  tictoc-bounces@ietf.org

2011-11-16 22:09

收件人

"zhang.junhui1@zte.com.cn" <zhang.junhui1@zte.com.cn>

抄送

"tictoc@ietf.org" <tictoc@ietf.org>

主题

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

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

 _______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc