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

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