From adrian@olddog.co.uk Sat Jul 21 04:16:08 2012 Return-Path: X-Original-To: rsvp-dir@ietfa.amsl.com Delivered-To: rsvp-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D1421F85BB; Sat, 21 Jul 2012 04:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XXtOobAXe4o; Sat, 21 Jul 2012 04:16:07 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3F021F851A; Sat, 21 Jul 2012 04:16:05 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q6LBH2e5003600; Sat, 21 Jul 2012 12:17:02 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (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$@olddog.co.uk> 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 Cc: rcallon@juniper.net Subject: Re: [rsvp-dir] [mpls] Reuqest for suggestion X-BeenThere: rsvp-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk 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 This is a multipart message in MIME format. ------=_NextPart_000_0F01_01CD673A.BB23EBB0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I haven't done a detailed review, but something amusing jumped out at = me. =20 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. =20 Thus, your argument "if idea A is not supported it will not work" = bounces back on you :-) =20 Adrian =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of fu.xihua@zte.com.cn Sent: 19 July 2012 15:59 To: mpls@ietf.org; rsvp-dir@ietf.org Cc: rcallon@juniper.net Subject: Re: [mpls] Reuqest for suggestion =20 Hi All,=20 I forwarded this mail to MPLS WG and rsvp-directorate according to Lou's suggestion in order to get comments from WG.=20 Thanks Lou's suggestion. It is very valuable.=20 Following is the requirement to extend RSVP-TE to deal with delay/loss = traffic engineering application.=20 We defined SENDER_TSPEC, ADSPEC and FLOWSPEC sub-object, i.e., option 2 = as Lou suggested.=20 Following is the latest draft. We didn't upload it to MPLS WG website.=20 Any comments are appreciated.=20 Xihua=20 Lou Berger =20 2012-03-05 =CF=C2=CE=E7 10:20=20 =CA=D5=BC=FE=C8=CB fu.xihua@zte.com.cn=20 =B3=AD=CB=CD rcallon@juniper.net, loa@pi.nu, swallow@cisco.com=20 =D6=F7=CC=E2 Re: Reuqest for suggestion =20 =09 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 ? If not, please just forward this or let me know and I'll do so. Lou On 3/5/2012 3:09 AM, fu.xihua@zte.com.cn wrote: >=20 > Hi Chairs, >=20 > In Taibei meeting, Lou suggested > _draft-fuxh-mpls-delay-loss-rsvp-te-ext-00_ > = > may be done in Tsvwg related to IntServ. >=20 > 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/ >=20 > Lou gave us a right direction, but it may involce serveral chairs. = Would > you like to give us some suggestions? >=20 > Xihua Fu ------=_NextPart_000_0F01_01CD673A.BB23EBB0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On = Behalf Of fu.xihua@zte.com.cn
Sent: 19 July 2012 = 15:59
To: mpls@ietf.org; rsvp-dir@ietf.org
Cc: = rcallon@juniper.net
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 = <lberger@labn.net> =

2012-03-05 = =CF=C2=CE=E7 10:20 =

=CA=D5=BC=FE=C8=CB<= /p>

fu.xihua@zte.c= om.cn

=B3=AD=CB=CD

rcallon@junipe= r.net, loa@pi.nu, swallow@cisco.com

=D6=F7=CC=E2

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

Lou

On 3/5/2012 3:09 AM, = fu.xihua@zte.com.cn wrote:
>
> Hi = Chairs,
>
> In Taibei meeting, Lou = suggested
> = _draft-fuxh-mpls-delay-loss-rsvp-te-ext-00_
> = <http://tools.ietf.org/html?draft=3Ddraft-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

------=_NextPart_000_0F01_01CD673A.BB23EBB0--