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

"Adrian Farrel" <> Sat, 21 July 2012 11:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7D1421F85BB; Sat, 21 Jul 2012 04:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[AWL=-1.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8XXtOobAXe4o; Sat, 21 Jul 2012 04:16:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0D3F021F851A; Sat, 21 Jul 2012 04:16:05 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id q6LBH2e5003600; Sat, 21 Jul 2012 12:17:02 +0100
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id q6LBH07e003578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Jul 2012 12:17:00 +0100
From: "Adrian Farrel" <>
To: <>, <>, <>
References: <>
In-Reply-To: <>
Date: Sat, 21 Jul 2012 12:16:59 +0100
Message-ID: <0f0001cd6732$59596930$0c0c3b90$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F01_01CD673A.BB23EBB0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLVQQuhTEZQREJvxOl839Lfcpk+5JUj4KKQ
Content-Language: en-gb
Subject: Re: [rsvp-dir] [mpls] Reuqest for suggestion
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RSVP directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Jul 2012 11:16:08 -0000

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 :-)
From: [] On Behalf Of
Sent: 19 July 2012 15:59
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
Following is the latest draft. We didn't upload it to MPLS WG website. 

Any comments are appreciated. 


Lou Berger <> 
2012-03-05 下午 10:20 



Re: Reuqest for suggestion


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 <>?  If not, please just forward this
or let me know and I'll do so.


On 3/5/2012 3:09 AM, wrote:
> Hi Chairs,
> In Taibei meeting, Lou suggested
> _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