Subject: [mpls] Open Issues in draft-fuxh-mpls-delay-loss-te-framework

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

Hi Working Group,

We would like to get comments for the following open issues.

1. Latency and jitter of Node
Advertising node latency may result in oscillation risk because of queue 
delay.
Authors of this drafts have ever discussed this issues. We descided drafts 
ignore the queuing delay for the benefit of simplicity. 
Node latency (e.g., a fixed or average/approximate latency ) can be 
included in the advertised link delay.

2.One maximum threshold could be configured to link. If the link 
performance exceeds the threshold, the IGP should get the anomalous state 
of this link.
It may result in heavy configuration work.

3.Composite Link Performance Advertisement
Option 1: Only TLV for Composite Link. The performance may be the range, 
average or maximum latency/loss of all component links.
Option 2: Both a TLV for each component link, plus one for the bundle with 
the average.

4. E2E loss computation: 
The latest version of this draft say the end-to-end path loss should be 
sum of each link. It isn't correct. 
We will give a little change in next version to clarify the e2e loss 
computation is multiplication of each link rather than sum.
i.e. packet loss of e2e path = 1-(1-lossrate_Link1)*(1-lossrate_Link2)*…
*(1-lossrate_Linkn)
Assume packet loss is 10% for two hops of a link. The measurements will 
come to 19% total packet loss. Because of 10% loss on the first link only 
90% packet reach the second link where another 10% of 90% are lost, which 
is 9% of total packets.
You may refer to ITU-T Y.1541 8.2 section.

Best Regards,

Authors

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 18 Nov 2011 13:21:42 -0800

Hi Fu,

> Option 2: Both a TLV for each component link, plus one for the bundle with
If we are sending for each component why do we need to send the average at
all. Any device can easily calculate the average. Though in my view Average
is of no use at all.

> i.e. packet loss of e2e path =
> 1-(1-lossrate_Link1)*(1-lossrate_Link2)*…*(1-lossrate_Linkn)
Yes if it is percentge or ratio, we need to use the mechanism as defined in
ITU draft. If its actual packets, then we can directly use the sum.

Thanks,
Vishwas

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 21 Nov 2011 15:03:59 -0800

Dear Fu and Authors,
two notes to make:

   - it is important to maintain consistent terminology during the
   discussion and in document itself. I believe that latency and jitter are
   characteristics of links, not of a node. And that specific levels of jitter
   and latency are function of PHB and CoS.
   - I think that queuing latency is an important if not dominant portion
   especially as link usage gets to BW saturation. And since links even at
   some PHB can be oversubscribed ignoring queuing latency might make static
   latency/jitter metric irrelevant.

Regards,
Greg

2011/11/16 <[email-masked]>

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 21 Nov 2011 15:14:59 -0800

Hi Greg,

I agree queuing latencies can be an issue.

However as mentioned in the draft because of the fact that the latencies
are going high we can go into the "unusable state" for the latency
parameter, which means any latency sensitive LSP's that need to be placed
will not use the link. The idea is to go for simplicity instead of absolute
optimization.

Thanks,
Vishwas
On Mon, Nov 21, 2011 at 3:03 PM, Greg Mirsky <[email-masked]> wrote:

>> Authors of this drafts have ever discussed this issues. We descided
>> drafts ignore the queuing delay for the benefit of simplicity.
>> Option 2: Both a TLV for each component link, plus one for the bundle
>> with the average.
>>
>> 4. E2E loss computation: