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

[Yuji Tochio <[e-mail]>]

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]
> https://www.ietf.org/mailman/listinfo/ccamp