[CCAMP] 答复: draft-long-ccamp-rsvp-te-bandwidth-availability-01

"Yemin (Amy)" <amy.yemin@huawei.com> Wed, 18 September 2013 08:21 UTC

Return-Path: <amy.yemin@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D2B11E81D1 for <ccamp@ietfa.amsl.com>; Wed, 18 Sep 2013 01:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.65
X-Spam-Level: ***
X-Spam-Status: No, score=3.65 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 4fDg2Fh8Hmlb for <ccamp@ietfa.amsl.com>; Wed, 18 Sep 2013 01:21:25 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2AB11E81E2 for <ccamp@ietf.org>; Wed, 18 Sep 2013 01:21:20 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXY79381; Wed, 18 Sep 2013 08:21:19 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 18 Sep 2013 09:20:42 +0100
Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 18 Sep 2013 09:21:12 +0100
Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.229]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0146.000; Wed, 18 Sep 2013 16:21:08 +0800
From: "Yemin (Amy)" <amy.yemin@huawei.com>
To: Yuji Tochio <tochio@jp.fujitsu.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [CCAMP] draft-long-ccamp-rsvp-te-bandwidth-availability-01
Thread-Index: AQHOjpWJ/m0VyRd7ukKBjiPhuYORuZnJY4cAgAILItA=
Date: Wed, 18 Sep 2013 08:21:08 +0000
Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F73D3E1E6@szxema506-mbs.china.huawei.com>
References: <42AD3B5FE67D4090B41F24C617A55395@china.huawei.com> <52381894.1030705@jp.fujitsu.com>
In-Reply-To: <52381894.1030705@jp.fujitsu.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.169.33.63]
Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461F73D3E1E6szxema506mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [CCAMP] =?gb2312?b?tPC4tDogIGRyYWZ0LWxvbmctY2NhbXAtcnN2cC10ZS1i?= =?gb2312?b?YW5kd2lkdGgtYXZhaWxhYmlsaXR5LTAx?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2013 08:21:30 -0000

Hi Yuji,

Thanks for the question clarification.

Presuming the link blow:
A------ B - - - - C ------D

The dash line represents the link with discrete variable bandwidth.

When the bandwidth requirements couldn't be satisfied on the link between B and C,  it should be C to return the PATHERR message.

It might be not clear in the current draft, I will update the draft to make it clear.

BR,
Amy
发件人: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 代表 Yuji Tochio
发送时间: 2013年9月17日 16:54
收件人: ccamp@ietf.org
主题: Re: [CCAMP] draft-long-ccamp-rsvp-te-bandwidth-availability-01

Hi all

FYI:
As to #4 (comment from me) below, I had offline talk with Amy via e-mail and
she has understood the point.
So I believe the editors will update the draft per my comments.

Thanks, Yuji

(2013/08/01 17:59), Amy wrote:
Hi CCAMPers,

There were some questions and comments after the presentation of draft-long-ccamp-rsvp-te-bandwidth-availability and draft-long-ccamp-ospf-availability-extension.

Below are the comments and replies:

1. The motivation
[Authors] For the links with variable discrete bandwidth, availability is used to decribe the bandwidth. It's proposed to add the availability as an paramter along with the bandwidth request. Without this extension, the link bandwidth cannot get good utilization: for example, the node may reserve the bandwidth with 99.999% availability while the actual requirement is only 99.9%, and consequently it can not reserve the bandwidth when the real requirement with 99.999% availability comes.

2. The mechanism, how to use the availability profile
[Authors] Once the link is set up, the information on availability and bandwidth is saved in the link bandwidth capacity table on local node, and should also be propagated in the routing message to calculate a path. When the bandwidth request comes, the node will compare the request with the link capacity table. If the request can be satisfied, the bandwidth is reserved and the link capacity table is updated.
3. What will happen if there are two links between C and D(see the figure in the slides), will it end up with multiple path?
[Authors] When there are multiple links between two nodes, the link aggregation may be used so that the two links can be treated as one logic link.  And the link aggregation should be transparent to resource resveration as it belongs to the link layer technology,

4. When the requirements in the PATH message couldn't be satisfied, D should send the PATHERR message.
[Authors] If the requirements couldn't be satisfied, to keep the consistent with the normal process, the resv process is terminated at C, C should send the PATHERR message,  and RESV message won't be passed to D.

5. In TSVWG, there's a draft on multiple-TSPEC which might be useful in this case.
[Authors] After looking into the draft-ietf-tsvwg-intserv-multiple-tspec-02, it might work to add a availability field in the TSPEC instead of having a sub-TLV in bandwidht profile TLV ( if I understand correlty).


Thank Khuzema, Lou, Yuji, Dieter to give their comments. And more comments are appreciated.

BR,
Amy Ye(on behalf of co-authors)






_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<mailto:CCAMP@ietf.org>

https://www.ietf.org/mailman/listinfo/ccamp