Subject: [mpls] question on draft-fuxh-ccamp-delay-loss-te-framework-00

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 25 Jul 2011 11:07:46 -0400

Authors -

While this work is interesting, what is your opinion on
transitivity of the Delay and Loss to be used as an attribute for RSVP-TE LSP?
In rapidly changing network, measured Delay and Loss  snapshot value could very well have changed before
LSP has completed the establishment. Is that a concern?

Thanks,
himanshu

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 25 Jul 2011 13:56:58 -0700

Hi Himanshu,

Delay is generally bimodal, which means that its mails A or B, and does not
randomly spread the entire spectrum. With that mentioned, the thing to note
is that the values may change, and every change in value should not result
in the LSP being rerouted (tere has to be a lot of damping and heuristics
that will be involved for the same).

BTW, here is a draft I put up which looks at details a bit more
http://www.ietf.org/internet-drafts/draft-manral-mpls-service-00.txt
Thanks,
Vishwas
On Mon, Jul 25, 2011 at 8:07 AM, Shah, Himanshu <[email-masked]> wrote:

>  Authors –****
>
> ** **
>
> While this work is interesting, what is your opinion on ****
>
> transitivity of the Delay and Loss to be used as an attribute for RSVP-TE
> LSP?****
>
> In rapidly changing network, measured Delay and Loss  snapshot value could
> very well have changed before****
>
> LSP has completed the establishment. Is that a concern?****
>
> ** **
>
> Thanks,****
>
> himanshu ****
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: [email-masked]
Date: Wed, 27 Jul 2011 04:18:00 +0800

Hi Himanshu,

One of authors here. Thank you for your comments.
I change the email title with "MPLS" because I have uploaded the draft to 
MPLS WG. Thers is no any change of the content.
When you mention using delay and loss as an attribute for RSVP-TE LSP, 
suppose I understand what you are saying.
There are some requirement related to RSVP-TE.
1. Delay Accumulation and Verification
e.g., Some AS may not support communication delay and loss in IGP or PCE 
architecture isn't applied.
|--------AS1-------|              |-------AS2-------|
0---------0---------0---------0---------0--------0
A              B               C              D               E   F
The idea is to accumulate the delay performance along the 
multi-domain/multi-layer path in RSVP-TE.
I think this requirement is related to your question.
The delay performance accumulated should be a average value.
Suppose CP signal e2e LSP across multi-domain, accumulate delay 
performance and verify it meet SLA.
You may mention after the creation, delay of some segment routing may 
change (e.g., delay increase ).
If the delay of one segment (e.g., between D and F) doesn't exceed the 
threshold, ingress doesn't need to care about it.
If it exceed the threshold, D may notify it to ingress A. So A may refresh 
(e.g., accumulate it again) the e2e delay by using path message.
We may focus on requirement firstly. The solution should be next step. 

2. Conveying Delay and Loss in RSVP-TE.
e.g., There is a Composite Link between B and C including three component 
links (i.e., #1, #2 and #3)
A          B                      C          D
o------o                      o------o
              -------------- #1
              -------------- #2
              -------------- #3
Ingress node A should inform node B in signaling message the delay and 
loss constraint to indicate how to select a component link.
So I think this isn't related to your question. 

e.g., Suppose a LSP is over a H-LSP (B-C-D-E). There may be a delay and 
loss constraint for the LSP segment (e.g, between B and E). 
So ingress also may convey delay and loss constraint in RSVP-TE to B. So B 
should trigger H-LSP which must meet the constraint.
A          B                      E          F
o------o                      o------o
              \                    /
                o---------o
                C               D
I also think this isn't related to your question. 

Thanks,

Xihua

"Shah, Himanshu" <[email-masked]> 
发件人:  [email-masked]
2011-07-25 下午 11:07

收件人
"[email-masked]" <[email-masked]>
抄送

主题
[mpls] question  on draft-fuxh-ccamp-delay-loss-te-framework-00

Authors –
 
LSP?
very well have changed before
 
Thanks,
himanshu