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

["Yemin (Amy)" <[e-mail]>]

Hi Autumn,



Thanks for the comments.

Sorry for the late reply, we just had a mid-autumn holiday. Please see my reply below.



BR,

Amy

________________________________
发件人: Autumn Liu [[e-mail]]
发送时间: 2013年9月19日 11:28
收件人: Yemin (Amy); Yuji Tochio; [e-mail]
主题: RE: [CCAMP] 答复: draft-long-ccamp-rsvp-te-bandwidth-availability-01

Hi Amy,

If the bandwidth on the link between B and C could not meet the requirement for PATH message, why the PATH is forwarded to C at the first place?
[Amy] When A initiates the PATH message, if bandwidth on the link between B and C could not meet the requirement, C should return the PATHERR to A, the PATH is not forwarded to C. Maybe some misunderstanding here.

There are existing SENDER TSPEC objects, can they co-exist with new tspec object? It does not seem so. The same question applies to flowspec.
[Amy] We don't want to introduce a new tspec nor flowspec object. The availability TLV is proposed to use as the sub_TLV of Ethernet banwidth profiles. I guess the inconsistent with existing SENDER TSPEC, the "class-specific information", leads to this question. I will fix it.

Is it assumed that the nodes along the path will all support <availability, bandwidth>? If not, it will be good to describe how old sender tspec objects can pass the cac with <availablity, banddith>, or new object goes through the cac without taking the availablity into account.
[Amy] The nodes along the path are not required to support the <bandwidth, availability>. The descripation on how to ignore will be added in next version.

section 3.1, class-num for sender_tspec should be tbd, 12 is used for ethernet tspec object already.
[Amy] 12 is the class-num for generic sender_tspec. class type 6 is used to ethernet tspec. So I think it's ok to use 12.
                 class-specific information : what is this?
[Amy]  I will modify it to make sure it's consisten with RFC 6003.

3.1.1  Where will availability sub-TLV in new bandwidth profile TLV, before traffic parameter or after? It seems the draft is extending RFC 6003 ethernet sender tspec, so flag 3 is used on profile.
[Amy] I perfer to put the availability sub_TLV after the traffic parameter. Yes, the draft is extending RFC6003.

Thanks,
Autumn


________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Yemin (Amy)
Sent: Wednesday, September 18, 2013 1:21 AM
To: Yuji Tochio; [e-mail]
Subject: [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
发件人: [e-mail] [mailto:[e-mail]] 代表 Yuji Tochio
发送时间: 2013年9月17日 16:54
收件人: [e-mail]
主题: 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

[e-mail]<mailto:[e-mail]>

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