Message-ID: <52381894.1030705@jp.fujitsu.com>
Date: Tue, 17 Sep 2013 17:53:40 +0900
From: Yuji Tochio <tochio@jp.fujitsu.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: ccamp@ietf.org
References: <42AD3B5FE67D4090B41F24C617A55395@china.huawei.com>
In-Reply-To: <42AD3B5FE67D4090B41F24C617A55395@china.huawei.com>
Content-Type: multipart/alternative;
 boundary="------------080809020703040802000006"
Subject: Re: [CCAMP] draft-long-ccamp-rsvp-te-bandwidth-availability-01
Precedence: list

This is a multi-part message in MIME format.
--------------080809020703040802000006
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

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
> https://www.ietf.org/mailman/listinfo/ccamp


--------------080809020703040802000006
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-2022-JP"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi all<br>
      <br>
      FYI:<br>
      As to #4 (comment from me) below, I had offline talk with Amy via
      e-mail and <br>
      she has understood the point.<br>
      So I believe the editors will update the draft per my comments.<br>
      <br>
      Thanks, Yuji <br>
      <br>
      (2013/08/01 17:59), Amy wrote:<br>
    </div>
    <blockquote
      cite="mid:42AD3B5FE67D4090B41F24C617A55395@china.huawei.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-2022-JP">
      <meta name="GENERATOR" content="MSHTML 8.00.6001.23487">
      <style></style>
      <div><font face="Times New Roman">Hi CCAMPers,</font></div>
      <div>&nbsp;</div>
      <div><font face="Times New Roman">There were some questions and
          comments after the presentation of <em>draft-long-ccamp-rsvp-te-bandwidth-availability</em>
          and <em>draft-long-ccamp-ospf-availability-extension</em>.</font></div>
      <div>&nbsp;</div>
      <div><font face="Times New Roman">Below are the comments and
          replies:</font></div>
      <div>&nbsp;</div>
      <div><font face="Times New Roman">1. The motivation </font></div>
      <div><font face="Times New Roman">[Authors] For the links with
          variable discrete bandwidth, availability is used to decribe
          the bandwidth. It's proposed to add&nbsp;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&nbsp;99.999%
          availability while the actual requirement is only 99.9%,&nbsp;and
          consequently it can not reserve the bandwidth when the real
          requirement with 99.999% availability comes.</font></div>
      <div>&nbsp;</div>
      <div><font face="Times New Roman">2. The mechanism, how to use the
          availability profile</font></div>
      <div><font face="Times New Roman">[Authors]&nbsp;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.<br>
        </font></div>
      <div><font face="Times New Roman">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?</font></div>
      <div><font face="Times New Roman">[Authors] When there are
          multiple links between two nodes, the link aggregation&nbsp;may be
          used so that the two links can be treated as one logic
          link.&nbsp;&nbsp;And the&nbsp;link aggregation should be transparent to
          resource resveration as it belongs to the link layer
          technology, </font></div>
      <div>&nbsp;</div>
      <div><font face="Times New Roman">4. When the requirements in the
          PATH message couldn't be satisfied,&nbsp;D should send the PATHERR
          message.</font></div>
      <div><font face="Times New Roman">[Authors] If the requirements
          couldn't be satisfied, to keep the consistent with the normal
          process, the&nbsp;resv process is terminated&nbsp;at C, C should send
          the PATHERR message,&nbsp;&nbsp;and RESV message won't be passed to D.</font></div>
      <div>&nbsp;</div>
      <div><font face="Times New Roman">5. In TSVWG, there's a draft on
          multiple-TSPEC which might be useful in this case.&nbsp;</font></div>
      <div><font face="Times New Roman">[Authors] After looking into the
          draft-ietf-tsvwg-intserv-multiple-tspec-02,&nbsp;it might&nbsp;work to
          add a availability field in the TSPEC instead of having a
          sub-TLV in bandwidht profile TLV&nbsp;(&nbsp;if I understand correlty).
        </font></div>
      <div>&nbsp;</div>
      <div>&nbsp;</div>
      <div><font face="Times New Roman">Thank&nbsp;Khuzema, Lou, Yuji, Dieter
          to give their comments. And more comments are appreciated.</font></div>
      <div>&nbsp;</div>
      <div><font face="Times New Roman">BR,</font></div>
      <div><font face="Times New Roman">Amy Ye(on behalf of co-authors)</font></div>
      <font face="Times New Roman">
        <div><br>
          <br>
        </div>
      </font>
      <div>&nbsp;</div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
CCAMP mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CCAMP@ietf.org">CCAMP@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ccamp">https://www.ietf.org/mailman/listinfo/ccamp</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------080809020703040802000006--