Hi, Yaakov
Thank you very much for your comments.
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.
>>> PDV is relate with many facotrs, I think, it isn't enough for only
one issue to be solved.
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.
>>> Yes, I can't make it clear. The draft is mainly focus on frequency
recovery.
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.
>>> Sorry, I will amend it in the later version.
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?).
>>> Yes, this draft is focus on ip/mpls;
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.
>>> Yes, I make a mistake, third part should be "third party" which means
that some traditional networks(e.g. non-1588 networks)
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.
>>>Yes, Delay variation is more important for frequency distribution. This
draft is mainly focus on frequency distribution;
I will describe PDV metrics in detail in the next
version.
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 ?
>>>I think, when switching over the salve may enter holdover.
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.
>>> I will revise it .
Thanks your comments again.
Best Regards
Junhui
*******************************************************************
Junhui Zhang
Bearer Network Product Pre-research Dept. ZTE Corporation
No.50 Ruanjian Ave,Yuhuatai District,Nanjing 210012,China
Telephone +86-25-88014227
Mobile Phone +86-13913845289
*******************************************************************
Yaakov Stein <[email protected]>
2011-11-16 22:09
收件人
"[email protected]" <[email protected]>
抄送
"[email protected]" <[email protected]>
主题
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
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
