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 <at> rad.com>
发件人: tictoc-bounces <at> ietf.org
2011-11-16 22:09
|
|
收件人
|
"zhang.junhui1 <at> zte.com.cn"
<zhang.junhui1 <at> zte.com.cn>
|
|
抄送
|
"tictoc <at> ietf.org" <tictoc <at> 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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
RSS Feed