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

From: Yaakov Stein <[email-masked]>
Date: Wed, 16 Nov 2011 14:09:36 +0000

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

---

From: [email-masked]
Date: Wed, 16 Nov 2011 22:22:23 +0800

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 <[email-masked]> 
发件人:  [email-masked]
2011-11-16 22:09

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [TICTOC] Hello, everyone, I submit a new draft: 
draft-zhang-tictoc-pdv-lsp-00, Welcome comments and suggestions! Thank 
You!

Junhui

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.

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-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 16 Nov 2011 14:31:12 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 16, 2011 16:22
To: Yaakov Stein
Cc: [email-masked]; [email-masked]; [email-masked]
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,

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.

Best Regards,

Xihua Fu

2011-11-16 22:09

收件人

抄送

主题

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

Junhui

Y(J)S

---

From: [email-masked]
Date: Thu, 17 Nov 2011 08:58:12 +0800

Hi Yaakov,

In the draft-fuxh-mpls-delay-loss-te-framework-03, section 2.5, we 
describe the requirement of restoration and protection based on the 
perfomrnace IGP database.
I think it may apply for PTP LSP recovery. For example, if some 
performance of links along PTP LSP get worse, Master can get the latest 
IGP database and find that end-to-end PTP LSP SLA could not meet the PTP 
traffic performance requirement, then it should be recoveried.

Best Regards,

Xihua Fu

2011-11-16 22:31

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
RE: 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

Subject: Re: Re: [TICTOC] Hello, everyone, I submit a new draft: 

Hi Yaakov, 

Best Regards, 

Xihua Fu 

收件人

Junhui 

  

  

  

Y(J)S

---

From: [email-masked]
Date: Thu, 17 Nov 2011 10:33:31 +0800

Hi,  Yaakov
 
            Thank you very much for  your  comments. 

 >>>  PDV is relate with many facotrs, I think, it isn't enough  for only 
one issue to be solved. 

 >>> Yes,   I can't make it clear. The draft is mainly focus on  frequency 
recovery. 

 >>> Sorry, I will amend it in the later version. 

>>> Yes, this draft is focus on ip/mpls; 

 >>> Yes, I make a mistake, third part should be "third party" which means 
that some traditional networks(e.g. non-1588 networks) 

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

>>>I think, when switching over the salve may enter holdover. 
 
               >>> 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
*******************************************************************

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [TICTOC] Hello, everyone, I submit a new draft: 
draft-zhang-tictoc-pdv-lsp-00, Welcome comments and suggestions! Thank 
You!

Junhui

 

 

 

Y(J)S