Re: [mpls] Reuqest for suggestion

[[e-mail]]

If both IGP within a single domain and signaling aren't supported for TE 
of latency, jitter and loss, it couldn't do the performance TE 
application.
But it doesn't mean I-D couldn't make any sense.
We may need to first negotiate the capability (e.g., supporting 
performance accumulation, performance IGP flooding or not) among multi 
domains according to Dave's idea.
If all domains support performance accumulation, source node may require 
LSR to accumulate the performance.
Rather than carrying information from each intermediate node separately to 
the receiver, the accumulation result represents a summary.

Xihua




"Mcdysan, David E" <[e-mail]> 
2012-07-23 下午 08:34

收件人
"[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]>, Mpls <[e-mail]>, "[e-mail]" 
<[e-mail]>
抄送
Ross Callon <[e-mail]>
主题
Re: [mpls] Reuqest for suggestion






We should reword. The logic should be something like in order to support 
establishment of LSPs meeting performance bounds across multiple domains, 
signaling extensions are needed since the IGP method used within a single 
domain is not sufficient.

I envision a new capability being first introduced in a cooperating set of 
domains and then expanding as additional cooperation occurs. We could add 
a discussion along these lines as well if this would be helpful.

Thanks for the input,

Dave
From: Adrian Farrel <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
Date: Sat, 21 Jul 2012 07:16:59 -0400
To: "[e-mail]" <[e-mail]>, Mpls <[e-mail]>, "
[e-mail]" <[e-mail]>
Cc: Ross Callon <[e-mail]>
Subject: Re: [mpls] Reuqest for suggestion

I haven't done a detailed review, but something amusing jumped out at me.
 
In the Introduction you quite rightly point out that if the reporting of 
latency, jitter and loss are not available from a specific domain then it 
will not be possible to use BRPC to compute an optimal (or adequate) 
end-to-end path. However, you then go on to give this as a reason to make 
functional additions to RSVP-TE.  Does it not occur to you that if one 
domain does not support the signaling of latency, jitter and loss (and 
their collection in the routing protocols) then your I-D will not work.
 
Thus, your argument "if idea A is not supported it will not work" bounces 
back on you :-)
 
Adrian
 
From: [e-mail] [mailto:[e-mail]] On Behalf Of 
[e-mail]
Sent: 19 July 2012 15:59
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [mpls] Reuqest for suggestion
 

Hi All, 

I forwarded this mail to MPLS WG and rsvp-directorate according to Lou's 
suggestion in order to get comments from WG. 
Thanks Lou's suggestion. It is very valuable. 
Following is the requirement to extend RSVP-TE to deal with delay/loss 
traffic engineering application. 

We defined SENDER_TSPEC, ADSPEC and FLOWSPEC sub-object, i.e., option 2 as 
Lou suggested. 
Following is the latest draft. We didn't upload it to MPLS WG website. 


Any comments are appreciated. 

Xihua 

Lou Berger <[e-mail]> 
2012-03-05 下午 10:20 


收件人
[e-mail] 
抄送
[e-mail], [e-mail], [e-mail] 
主题
Re: Reuqest for suggestion
 








Xihua,

I was really trying to make a technical point not a procedural one.  My
main point is that latency is part of service/QoS
description/characterization and that as such belongs in a
flowspec/tspec/adspec and not as a generic RSVP object.  For example,
the intserv ADSPEC already supports a latency parameter, and RFC2212
make claims related to latency.

One possible approach is to modify IntServ (as represented by RFC210) to
provide the new parameters you are looking for.  Another alternative is
to define an alternative flowspec/tspec format.

So, as I see it, there are three options:
1) Extend RSVP: New RSVP-level object/attribue
2) Extend IntServ: New IntServ parameter(s)
3) New Traffic Description: new c-type for RSVP adspec/flowspec/tspec

You are currently proposing option 1, and I'm suggesting that option 2
and 3 should be considered first.

With respect to working group.  I personally think having this work done
in MPLS is just fine, but others such as TSVWG should know about it.  Of
course, the chairs of these WGs and ADs may disagree.

Do you have any objection to bringing this discussion to the MPLS WG and
rsvp-directorate <[e-mail]>?  If not, please just forward this
or let me know and I'll do so.

Lou

On 3/5/2012 3:09 AM, [e-mail] wrote:
> 
> Hi Chairs,
> 
> In Taibei meeting, Lou suggested
> _draft-fuxh-mpls-delay-loss-rsvp-te-ext-00_
> <
http://tools.ietf.org/html?draft=draft-fuxh-mpls-delay-loss-rsvp-te-ext-00
>
> may be done in Tsvwg related to IntServ.
> 
> Minutes:
> /Lou: changes concern IntServ. should be done maybe in tsvwg. I support
> the objective but 100% in scope interv and out of scope of rsvp/
> /Ross: good question. need to be resolved offline/
> /Xihua: was in ccamp, now moved to mpls, but not sure rsvp is good place
> indeed/
> /Loa: decision will involve serveral chairs and ADs/
> 
> Lou gave us a right direction, but it may involce serveral chairs. Would
> you like to give us some suggestions?
> 
> Xihua Fu