Re: [rsvp-dir] [mpls] Reuqest for suggestion

["Adrian Farrel" <[e-mail]>]

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