Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2C912D868; Tue, 13 Feb 2018 10:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtn2pfUPeukD; Tue, 13 Feb 2018 10:13:22 -0800 (PST) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B10112D865; Tue, 13 Feb 2018 10:13:22 -0800 (PST) Received: by mail-pl0-x232.google.com with SMTP id t4so7027244plo.0; Tue, 13 Feb 2018 10:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wsNKv1kYahG+OFTMHvPvWIiSoQysoSJz0DUkQza79uA=; b=ZycgbBD9iHvaVL5AWmKGhPvROln/aRldHBd5Dg0hBqDcV14HdRK0MlWk4ahJu+gnDF lWJVIa0n+QTniOzG5CL1/0+nAinZ/05L6WLj8oEOtb4IM9k47OUFiE3y9wxYOcg1Pg3i x1iSrg6luH6P1w/VVN3ifyV8bUz2u1wqjMmBnOQEjhjayid0BePviC+229g0yHkwaFJU y3Dxl++bCfoghwDN6IgsgVXX34zaEbMaQH9G7pN7lmjtLAXl8OBTTEvtkaafBiGQZi5l FhUY0/HTMjh+wYUCC4H//pQKPFz5Zz+aWm/yXLveYZ1LIiOmrLZpRnIwmcdAwu9Beqh/ eP7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wsNKv1kYahG+OFTMHvPvWIiSoQysoSJz0DUkQza79uA=; b=YAq3hA7644bkJ7gzJImBRANC8j621aP7g942dojTqCho7ApiN7X9rhHAJ0YS0tHeV0 RmxP1bgeSAygNOL7qcvEgBhTo6u/H68fQvBKFtlo/6DtlDpEYer0Ww/FjWsZDfj0KH1Q SPV+7pOnMFIcFGtEkMbqESri1HRXPnq+oMjzqSPvn7iZx1/q65rzJ6u0WFpBpQ8ktVd1 MmgKmjiAT3TanUpqHFq2lqBCX3oWv+D+StrYGGaRVs/1+5Wo/Qd53GttQOsr5ciIIGDw AVJNdbMYW6unbfnywQQcFylurfvQK8FwN9jHkRs+24GvXFIhdIdqkTst7IgsYk6EyEiW iGTQ== X-Gm-Message-State: APf1xPBEC+NtWpguBqvP31k4IUIR+O7o14e5lnV22bVsZRpnj80qdsx5 uAKSi4nYlOd0L++fbiXNVHUeGb1MJQbqsK1R0qI= X-Google-Smtp-Source: AH8x224y/3mSZ2oH/unr21VLW2q3dAG+cIegieQNH7Da01FDaTRRs9pzQrhRWVX0jU3iefFudfoORqupJ2gdYkOXVEM= X-Received: by 2002:a17:902:aa85:: with SMTP id d5-v6mr1955054plr.239.1518545601658; Tue, 13 Feb 2018 10:13:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.182.129 with HTTP; Tue, 13 Feb 2018 10:13:20 -0800 (PST) In-Reply-To: <2074ADF5-C8E1-4F4A-A524-554B26BEA681@kuehlewind.net> References: <150644890311.20830.6212136664552694640.idtracker@ietfa.amsl.com> <2074ADF5-C8E1-4F4A-A524-554B26BEA681@kuehlewind.net> From: Vishnu Pavan Beeram Date: Tue, 13 Feb 2018 13:13:20 -0500 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: Lou Berger , TEAS WG Chairs , The IESG , "teas@ietf.org" , draft-ietf-teas-rsvp-te-scaling-rec@ietf.org Content-Type: multipart/alternative; boundary="00000000000029841b05651bf34b" Archived-At: Subject: Re: [Teas] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?teas-rsvp-te-scaling-rec-06=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 18:13:29 -0000 --00000000000029841b05651bf34b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mirja, Hi! Thanks for the response! It doesn't seem like we can make progress here if I keep recycling the same set of responses. I seem to have exhausted the "this is normal RSVP soft- state signaling behavior" line of argument :) I don't want to spend too much time arguing about a subtlety that (probably) only folks who have implemented RSVP-TE understand. So, let me try a different take on this. How about the following changes to the document? ** - Remove Section 2.3 (this takes out the contentious text) - Make the following change in Section 3 OLD: o MUST make the default value of the configurable refresh interval be a large value (10s of minutes). A default value of 20 minutes is RECOMMENDED by this document. NEW: o MUST make the default value of the configurable refresh interval (R) be a large value (10s of minutes). A default value of 20 minutes is RECOMMENDED by this document. o MUST use a separate refresh interval for refreshing state associated with unacknowledged Path/Resv messages (uR). A default value of 30 seconds is RECOMMENDED by this document. - Make the following change in Appendix A. OLD: (d) Periodic Retransmission Interval for unacknowledged Path/Resv messages (uR) - 30 seconds (Section 2.3). If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the 7 rapid retransmit steps to max out (The last delay from message 6 to message 7 is 16 seconds). After the 7 rapid retransmit steps are maxed out, the router starts periodic retransmission on a slower timer. This document recommends the use of the traditional default refresh interval value of 30 seconds for this periodic retransmission interval. NEW: (d) Refresh interval for refreshing state associated with unacknowledged Path/Resv messages (uR)- 30 seconds (Section 3). The recommended refresh interval (R) value of 20 minutes (for an implementation supporting RI-RSVP) can not be used for refreshing state associated with unacknowledged Path/Resv messages. This document recommends the use of the traditional default refresh interval value of 30 seconds for uR. *** Let me know if the above changes address your concerns. Regards, -Pavan On Tue, Feb 13, 2018 at 9:22 AM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi Pavan, > > I believe you that there may be implementation that transmit indefinitely= , > however, that is not how I read RFC2961: > > " The staged retransmission will continue > until either an appropriate MESSAGE_ID_ACK object is received, or the > rapid retry limit, Rl, has been reached.=E2=80=9C > > or > > =E2=80=9EThe sending node will retransmit the message until a message > acknowledgment is received or the message has been transmitted a > maximum number of times.=E2=80=9C > > For me these sentences say that one should not retransmit anymore after > the max number is reached. If this is implemented differently, that is a > not safe behavior and need to be clarified. There must be a termination > condition. It is not safe for the stability of the Internet to retransmit > packets indefinitely. Packet loss can have may reason but continuous pack= et > loss is a clear sign of congestion that one can not be ignored. > > Mirja > > > > > Am 12.01.2018 um 14:15 schrieb Vishnu Pavan Beeram < > vishnupavan@gmail.com>: > > > > Mirja, Hi! > > > > I thought the following response (sent on Oct 5th 2017) addressed this > concern. > > > > ** Copying text from an earlier email ** > > There is nothing new about Path and Resv messages getting transmitted > indefinitely (this is normal soft-state signaling behavior). All that is > being discussed in this section is how these transmissions get paced afte= r > the rapid retry limit is reached. The slower timer transmission will go o= n > until either an ack is received (at which point the regular "refresh > interval" comes into play) or the corresponding LSP instance state is tor= n > down. > > ** > > > > Please let me know if this still doesn't address the concern. We can se= t > up a call and walk through the base RSVP specs. > > > > Regards, > > -Pavan > > > > On Fri, Jan 12, 2018 at 7:12 AM, Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net> wrote: > > Hi Vishnu, hi all, > > > > sorry but I lost a little bit track of this and looking at this now the > clarification provided below do not seem to address my concern. My concer= n > is that for messages (that a MESSAGE_ID object with the ACK_Desired flag > set), these messages would retransmit forever (even though only every 30s= ) > and there is not stop criteria to finally give up (and report an error). > > > > Mirja > > > > > > > Am 22.12.2017 um 08:44 schrieb Vishnu Pavan Beeram < > vishnupavan@gmail.com>: > > > > > > Mirja, Hi! > > > > > > Please see if the responses above address your concerns. Please let u= s > know if there are any issues with progressing this document. > > > > > > Regards, > > > -Pavan > > > > > > On Mon, Nov 13, 2017 at 4:21 AM, Lou Berger wrote: > > > Hi, > > > Please see below. > > > > > > On 11/13/2017 5:57 AM, Vishnu Pavan Beeram wrote: > > > Mirja, Hi! > > > > > > Apologize for the delayed reply. > > > Please see inline for responses (prefixed VPB). > > > > > > Regards, > > > -Pavan > > > > > > On Mon, Oct 16, 2017 at 6:25 AM, Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net > wrote: > > > > > > Hi Vishnu, > > > > > > I don=E2=80=99t think what you proposed is a clarification at all= . RF2961 > > > clearly reads to me that you should not retry any more after the > > > Rapid retry limit has been reached: > > > > > > > > > "Rl is the maximum number of times a message will be > > > transmitted without being acknowledged.=E2=80=9C > > > > > > > > > Please not that this section applies to "a message containing a > MESSAGE_ID object with the ACK_Desired flag set" and > > > > > > The ACK_Desired flag will typically be set only in trigger messages. > > > > > > This means that these procedure does not apply to normal RSVP refresh > processing and that normal RFC2205 defined Refresh Processing or Summary > Refresh processing continues. > > > > > > > > > [VPB] Yes. As per RFC2961, the retry limit (Rl) is the maximum number > of times a message will be transmitted without being acknowledged. But th= is > just governs the number of times you retransmit the message during the > "rapid retransmission phase". > > > > > > RFC2961 is silent about what happens after the "rapid retransmission > phase" is complete and this is the clarification that is being provided > here in the draft. > > > > > > The draft is silent in general about anything that is *not* modified > by the draft. I think having the informative statement is appropriate. > > > > > > Note that the associated RSVP Path/Resv state doesn't get cleaned up > after the "rapid retransmission" phase is complete. So at each subsequent > refresh-interval, the unacked Path/Resv message will be sent out again > (note that if there is no change in the state, the same MESSAGE_ID would > get used). This behavior has always existed in RSVP-TE implementations -- > so it is incorrect to deduce from the "RFC 2961" text above that the > retransmission of the unacked Path/Resv will never happen after the "Rl" = is > reached. > > > > > > > > > Agreed. > > > Lou > > > > > > > > > Also RFC2961 suggests an initial Rf of 500ms with 7 retries and a= nd > > > delta of 2, that means you will see the following retries: > > > > > > 1. after 500ms > > > 2. after 1000ms > > > 3. after 2000ms > > > 4. after 4000ms > > > 5. after 8000ms > > > 6. after 16000ms > > > 7. after 32000ms > > > > > > and then give up. While you suggests to send all 300ms section > > > afterwards forever. That is not acceptable and can lead to > congestion. > > > > > > > > > No, that is not what is being suggested. > > > RFC2961 suggests an Rf of 500ms with 3 retries and a delta of 2. So > the rapid retransmissions would be: > > > 1. after 500ms > > > 2. after 1000ms > > > 3. after 2000ms. > > > > > > With the proposal in the draft, you would try 7 times > and then stop the "rapid retransmission phase". So, what that means is th= at > the rapid retransmission phase lasts 31.5 seconds (first retry is after > 500ms and the seventh retry is after 32000ms). After this "rapid > retransmission phase" is complete, you keep sending the message out every > 30000ms (30seconds is not 300ms) until an acknowledgement is received. > > > > > > Hope this helps. > > > > > > > > > > > > Mirja > > > > > > > > > > > > > > > > Am 05.10.2017 um 22:27 schrieb Vishnu Pavan Beeram > > > >: > > > > > > > > > > > Mirja, Hi! > > > > > > > > This was discussed in my response to Elwyn. I apologize for no= t > > > responding directly. > > > > > > > > RFC2961 doesn't discuss what to do with the retransmissions > after > > > the retry limit is reached. It doesn't discuss how retransmission= s > > > need to be paced after the rapid retries are stopped. Section 2.3 > > > (ver 7) of the current draft clarifies this and proposes the use = of > > > a "not so rapid (30secs)" retransmission interval. > > > > > > > > There were a couple of questions from this section that you > > > wanted to get discussed: > > > > ---- > > > > (1) Why is there no termination criteria specified? > > > > There is nothing new about Path and Resv messages getting > > > transmitted indefinitely (this is normal soft-state signaling > > > behavior). All that is being discussed in this section is how the= se > > > transmissions get paced after the rapid retry limit is reached. T= he > > > slower timer transmission will go on until either an ack is > received > > > (at which point the regular "refresh interval" comes into play) o= r > > > the corresponding LSP instance state is torn down. > > > > > > > > ---- > > > > (2) Why couldn't the regular refresh interval be used for thes= e > > > un-acked retransmissions? > > > > The primary goal of the retransmission is to eke out an > > > acknowledgement from the neighbor as quickly as you can. You can > use > > > the same value as the the regular refresh interval provided it is > > > small enough (like in the case of the conventional refresh interv= al > > > of 30 secs) . However, we are recommending the use of a "large > > > refresh interval" (20 mins) in the RI-RSVP technique -- we can't > > > wait that long for retrying the transmission of an unacked messag= e. > > > > > > > > Consider a rudimentary state machine with the following states > > > (assuming the defaults suggested in the Appendix of the draft): > > > > - first retransmit (exponential back off) > > > > - second retransmit (exponential back off) > > > > ... > > > > - seventh retransmit (exponential back off) > > > > - 30s retransmission > > > > - 20m refresh (regular refresh timer) > > > > > > > > At any point when the Ack is received, you transition to the 2= 0m > > > refresh state. > > > > > > > > --- > > > > > > > > Do these two responses adequately answer your questions? > > > > > > > > Regards, > > > > -Pavan > > > > > > > > On Thu, Oct 5, 2017 at 7:57 AM, Mirja Kuehlewind (IETF) > > > > wrote: > > > > Hi Pavan, > > > > > > > > I don=E2=80=99t see any changes in the new version that addres= ses may > > > actual discuss on section 2.1.3 (now section 2.3). Can you please > > > clarify? > > > > > > > > Thanks, > > > > Mirja > > > > > > > > > > > > > Am 28.09.2017 um 05:45 schrieb Vishnu Pavan Beeram > > > >: > > > > > > > > > > Mirja, Hi! > > > > > > > > > > Thanks for the review. We just posted a new revision (-07) t= o > > > address the Gen-Art review comments. Please go through the new > diffs > > > (https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te- > scaling-rec-07 > > > scaling-rec-07>) > > > and let us know if additional changes are required. > > > > > > > > > > Also, please go through the responses provided to the other > > > review comments and let us know if there are still any unanswered > > > questions. > > > > > > > > > > Regards, > > > > > -Pavan > > > > > > > > > > > > > > > > > > > > On Tue, Sep 26, 2017 at 2:01 PM, Mirja K=C3=BChlewind > > > > wrote: > > > > > Mirja K=C3=BChlewind has entered the following ballot positi= on for > > > > > draft-ietf-teas-rsvp-te-scaling-rec-06: Discuss > > > > > > > > > > When responding, please keep the subject line intact and rep= ly > > > to all > > > > > email addresses included in the To and CC lines. (Feel free = to > > > cut this > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > > > > for more information about IESG DISCUSS and COMMENT position= s. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be foun= d > here: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te- > scaling-rec/ scaling-rec/> > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------ > ---------- > > > > > DISCUSS: > > > > > > > > ------------------------------------------------------------ > ---------- > > > > > > > > > > I'm uncertain what section 2.1.3. actually recommends. My > > > understanding is that > > > > > it is recommend to still send retransmit some message even i= f > > > the Rl was > > > > > reached and to that every 30s basically forever. First of al= l > I > > > think this > > > > > still needs a termination criteria when to stop to try to > > > retransmit finally. > > > > > And the I don't understand why this is needed, instead of e.= g. > > > just using a > > > > > larger Rl value? Can you please clarify! > > > > > > > > > > > > > > > > > > ------------------------------------------------------------ > ---------- > > > > > COMMENT: > > > > > > > > ------------------------------------------------------------ > ---------- > > > > > > > > > > I fully agree with the gan-art review (Thanks Elwyn!) and > > > Alvaro, that this > > > > > reads from time to time like a BCP but is actually a extensi= on > > > specification. I > > > > > would strongly recommend to apply the changes proposed by th= e > > > gen-art review, > > > > > and there is also a very detailed list of nits/edits that > > > should probably be > > > > > applied. Please have a look at that! > > > > > > > > > > > > > > > _______________________________________________ > > > > > Teas mailing list > > > > > Teas@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/teas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > > > > > > > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --00000000000029841b05651bf34b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mirja, Hi!

Thanks for the= response!
It doesn't seem like we can make progress here if I keep = recycling the same set of responses. I seem to have exhausted the "this is normal RSVP soft-state signal= ing behavior" line of argument :)

I don't want to spend too much time arguing about = a subtlety that (probably) only folks who have implemented RSVP-TE understa= nd. So, let me try a different take on this.

How about the following changes to the document?
**
- Remove Section 2.3 (thi= s takes out the contentious text)

- Make the following change in Section 3
=C2=A0 OLD:
   o  MUST=
 make the default value of the configurable refresh interval
      be a large value (10s of minutes).  A default value of 20 minutes
      is RECOMMENDED by this document.
=C2=A0 NEW:
o MUST make the default value of the configur= able refresh interval (R) be a large value (10s of minutes). A default value of 20
= minutes is RECOMMENDED by this document.
   o  MUST use a separate refresh interval for refreshing state associated=

      with unacknowledged Path/Resv messages (uR).  A default value of =

      30 seconds is RECOMMENDED by this document.

- = Make the following change in Appendix A.
=C2=A0 OLD:
      (d) Periodic Retransmission Interval for unacknowl=
edged Path/Resv
      messages (uR) - 30 seconds (Section 2.3).
      If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the 7
      rapid retransmit steps to max out (The last delay from message 6
      to message 7 is 16 seconds).  After the 7 rapid retransmit steps
      are maxed out, the router starts periodic retransmission on a
      slower timer.  This document recommends the use of the traditional
      default refresh interval value of 30 seconds for this periodic
      retransmission interval.
=C2=A0 NEW:
      (d) Refresh interval for refreshing state associated with =

      unacknowledged Path/Resv messages (uR)- 30 seconds (Section 3).
      The recommended refresh interval (R) value of 20 minutes (for an
 =
     implementation supporting RI-RSVP) can not be used for refreshing
 =
     state associated with unacknowledged Path/Resv messages. This 
    =
  document recommends the use of the traditional default refresh 
      =
interval value of 30 seconds for uR.
***

Let me know if the above ch= anges address your concerns.

Regard= s,
-Pavan

On Tue, Feb 13, 2018 at 9:22 AM, Mirj= a Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
Hi Pavan,

I believe you that there may be implementation that transmit indefinitely, = however, that is not how I read RFC2961:

" The staged retransmission will continue
=C2=A0 =C2=A0until either an appropriate MESSAGE_ID_ACK object is received,= or the
=C2=A0 =C2=A0rapid retry limit, Rl, has been reached.=E2=80=9C

or

=E2=80=9EThe sending node will retransmit the message until a message
=C2=A0 =C2=A0acknowledgment is received or the message has been transmitted= a
=C2=A0 =C2=A0maximum number of times.=E2=80=9C

For me these sentences say that one should not retransmit anymore after the= max number is reached. If this is implemented differently, that is a not s= afe behavior and need to be clarified. There must be a termination conditio= n. It is not safe for the stability of the Internet to retransmit packets i= ndefinitely. Packet loss can have may reason but continuous packet loss is = a clear sign of congestion that one can not be ignored.

Mirja



> Am 12.01.2018 um 14:15 schrieb Vishnu Pavan Beeram <vishnupavan@gmail.com>:
>
> Mirja, Hi!
>
> I thought the following response (sent on Oct 5th 2017) addressed this= concern.
>
> ** Copying text from an earlier email **
> There is nothing new about Path and Resv messages getting transmitted = indefinitely (this is normal soft-state signaling behavior). All that is be= ing discussed in this section is how these transmissions get paced after th= e rapid retry limit is reached. The slower timer transmission will go on un= til either an ack is received (at which point the regular "refresh int= erval" comes into play) or the corresponding LSP instance state is tor= n down.
> **
>
> Please let me know if this still doesn't address the concern. We c= an set up a call and walk through the base RSVP specs.
>
> Regards,
> -Pavan
>
> On Fri, Jan 12, 2018 at 7:12 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
> Hi Vishnu, hi all,
>
> sorry but I lost a little bit track of this and looking at this now th= e clarification provided below do not seem to address my concern. My concer= n is that for messages (that a MESSAGE_ID object with the ACK_Desired flag = set), these messages would retransmit forever (even though only every 30s) = and there is not stop criteria to finally give up (and report an error). >
> Mirja
>
>
> > Am 22.12.2017 um 08:44 schrieb Vishnu Pavan Beeram <vishnupavan@gmail.com>:
> >
> > Mirja, Hi!
> >
> > Please see if the responses above address your concerns. Please l= et us know if there are any issues with progressing this document.
> >
> > Regards,
> > -Pavan
> >
> > On Mon, Nov 13, 2017 at 4:21 AM, Lou Berger <lberger@labn.net> wrote:
> > Hi,
> > Please see below.
> >
> > On 11/13/2017 5:57 AM, Vishnu Pavan Beeram wrote:
> > Mirja, Hi!
> >
> > Apologize for the delayed reply.
> > Please see inline for responses (prefixed VPB).
> >
> > Regards,
> > -Pavan
> >
> > On Mon, Oct 16, 2017 at 6:25 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote: > >
> >=C2=A0 =C2=A0 =C2=A0Hi Vishnu,
> >
> >=C2=A0 =C2=A0 =C2=A0I don=E2=80=99t think what you proposed is a c= larification at all. RF2961
> >=C2=A0 =C2=A0 =C2=A0clearly reads to me that you should not retry = any more after the
> >=C2=A0 =C2=A0 =C2=A0Rapid retry limit has been reached:
> >
> >
> >=C2=A0 =C2=A0 =C2=A0"Rl is the maximum number of times a mess= age will be
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tran= smitted without being acknowledged.=E2=80=9C
> >
> >
> > Please not that this section applies to "a message containin= g a MESSAGE_ID object with the ACK_Desired flag set" and
> >
> > The ACK_Desired flag will typically be set only in trigger messag= es.
> >
> > This means that these procedure does not apply to normal RSVP ref= resh processing and that=C2=A0 normal RFC2205 defined Refresh Processing or= Summary Refresh processing continues.
> >
> >
> > [VPB] Yes. As per RFC2961, the retry limit (Rl) is the maximum nu= mber of times a message will be transmitted without being acknowledged. But= this just governs the number of times you retransmit the message during th= e "rapid retransmission phase".
> >
> > RFC2961 is silent about what happens after the "rapid retran= smission phase" is complete and this is the clarification that is bein= g provided here in the <scaling-rec> draft.
> >
> > The draft is silent in general about anything that is *not* modif= ied by the draft.=C2=A0 I think having the informative statement is appropr= iate.
> >
> > Note that the associated RSVP Path/Resv state doesn't get cle= aned up after the "rapid retransmission" phase is complete. So at= each subsequent refresh-interval, the unacked Path/Resv message will be se= nt out again (note that if there is no change in the state, the same MESSAG= E_ID would get used). This behavior has always existed in RSVP-TE implement= ations -- so it is incorrect to deduce from the "RFC 2961" text a= bove that the retransmission of the unacked Path/Resv will never happen aft= er the "Rl" is reached.
> >
> >
> > Agreed.
> > Lou
> >
> >
> >=C2=A0 =C2=A0 =C2=A0Also RFC2961 suggests an initial Rf of 500ms w= ith 7 retries and and
> >=C2=A0 =C2=A0 =C2=A0delta of 2, that means you will see the follow= ing retries:
> >
> >=C2=A0 =C2=A0 =C2=A01. after 500ms
> >=C2=A0 =C2=A0 =C2=A02. after 1000ms
> >=C2=A0 =C2=A0 =C2=A03. after 2000ms
> >=C2=A0 =C2=A0 =C2=A04. after 4000ms
> >=C2=A0 =C2=A0 =C2=A05. after 8000ms
> >=C2=A0 =C2=A0 =C2=A06. after 16000ms
> >=C2=A0 =C2=A0 =C2=A07. after 32000ms
> >
> >=C2=A0 =C2=A0 =C2=A0and then give up. While you suggests to send a= ll 300ms section
> >=C2=A0 =C2=A0 =C2=A0afterwards forever. That is not acceptable and= can lead to congestion.
> >
> >
> > No, that is not what is being suggested.
> > RFC2961 suggests an Rf of 500ms with 3 retries and a delta of 2. = So the rapid retransmissions would be:
> > 1. after 500ms
> > 2. after 1000ms
> > 3. after 2000ms.
> >
> > With the proposal in the <scaling-rec> draft, you would try= 7 times and then stop the "rapid retransmission phase". So, what= that means is that the rapid retransmission phase lasts 31.5 seconds (firs= t retry is after 500ms and the seventh retry is after 32000ms). After this = "rapid retransmission phase" is complete, you keep sending the me= ssage out every 30000ms (30seconds is not 300ms) until an acknowledgement i= s received.
> >
> > Hope this helps.
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0Mirja
> >
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 > Am 05.10.2017 um 22:27 schrieb Vishnu Pa= van Beeram
> >=C2=A0 =C2=A0 =C2=A0<v= ishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>:
> >
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > Mirja, Hi!
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > This was discussed in my response to Elw= yn. I apologize for not
> >=C2=A0 =C2=A0 =C2=A0responding directly.
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > RFC2961 doesn't discuss what to do w= ith the retransmissions after
> >=C2=A0 =C2=A0 =C2=A0the retry limit is reached. It doesn't dis= cuss how retransmissions
> >=C2=A0 =C2=A0 =C2=A0need to be paced after the rapid retries are s= topped. Section 2.3
> >=C2=A0 =C2=A0 =C2=A0(ver 7) of the current draft clarifies this an= d proposes the use of
> >=C2=A0 =C2=A0 =C2=A0a "not so rapid (30secs)" retransmis= sion interval.
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > There were a couple of questions from th= is section that you
> >=C2=A0 =C2=A0 =C2=A0wanted to get discussed:
> >=C2=A0 =C2=A0 =C2=A0 > ----
> >=C2=A0 =C2=A0 =C2=A0 > (1) Why is there no termination criteria= specified?
> >=C2=A0 =C2=A0 =C2=A0 > There is nothing new about Path and Resv= messages getting
> >=C2=A0 =C2=A0 =C2=A0transmitted indefinitely (this is normal soft-= state signaling
> >=C2=A0 =C2=A0 =C2=A0behavior). All that is being discussed in this= section is how these
> >=C2=A0 =C2=A0 =C2=A0transmissions get paced after the rapid retry = limit is reached. The
> >=C2=A0 =C2=A0 =C2=A0slower timer transmission will go on until eit= her an ack is received
> >=C2=A0 =C2=A0 =C2=A0(at which point the regular "refresh inte= rval" comes into play) or
> >=C2=A0 =C2=A0 =C2=A0the corresponding LSP instance state is torn d= own.
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > ----
> >=C2=A0 =C2=A0 =C2=A0 > (2) Why couldn't the regular refresh= interval be used for these
> >=C2=A0 =C2=A0 =C2=A0un-acked retransmissions?
> >=C2=A0 =C2=A0 =C2=A0 > The primary goal of the retransmission i= s to eke out an
> >=C2=A0 =C2=A0 =C2=A0acknowledgement from the neighbor as quickly a= s you can. You can use
> >=C2=A0 =C2=A0 =C2=A0the same value as the the regular refresh inte= rval provided it is
> >=C2=A0 =C2=A0 =C2=A0small enough (like in the case of the conventi= onal refresh interval
> >=C2=A0 =C2=A0 =C2=A0of 30 secs) . However, we are recommending the= use of a "large
> >=C2=A0 =C2=A0 =C2=A0refresh interval" (20 mins) in the RI-RSV= P technique -- we can't
> >=C2=A0 =C2=A0 =C2=A0wait that long for retrying the transmission o= f an unacked message.
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > Consider a rudimentary state machine wit= h the following states
> >=C2=A0 =C2=A0 =C2=A0(assuming the defaults suggested in the Append= ix of the draft):
> >=C2=A0 =C2=A0 =C2=A0 > - first retransmit (exponential back off= )
> >=C2=A0 =C2=A0 =C2=A0 > - second retransmit (exponential back of= f)
> >=C2=A0 =C2=A0 =C2=A0 > ...
> >=C2=A0 =C2=A0 =C2=A0 > - seventh retransmit (exponential back o= ff)
> >=C2=A0 =C2=A0 =C2=A0 > - 30s retransmission
> >=C2=A0 =C2=A0 =C2=A0 > - 20m refresh (regular refresh timer) > >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > At any point when the Ack is received, y= ou transition to the 20m
> >=C2=A0 =C2=A0 =C2=A0refresh state.
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > ---
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > Do these two responses adequately answer= your questions?
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > Regards,
> >=C2=A0 =C2=A0 =C2=A0 > -Pavan
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > On Thu, Oct 5, 2017 at 7:57 AM, Mirja Ku= ehlewind (IETF)
> >=C2=A0 =C2=A0 =C2=A0<iet= f@kuehlewind.net <mailto:ietf= @kuehlewind.net>> wrote:
> >=C2=A0 =C2=A0 =C2=A0 > Hi Pavan,
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > I don=E2=80=99t see any changes in the n= ew version that addresses may
> >=C2=A0 =C2=A0 =C2=A0actual discuss on section 2.1.3 (now section 2= .3). Can you please
> >=C2=A0 =C2=A0 =C2=A0clarify?
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > Thanks,
> >=C2=A0 =C2=A0 =C2=A0 > Mirja
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > > Am 28.09.2017 um 05:45 schrieb Vish= nu Pavan Beeram
> >=C2=A0 =C2=A0 =C2=A0<v= ishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>:
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > Mirja, Hi!
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > Thanks for the review. We just post= ed a new revision (-07) to
> >=C2=A0 =C2=A0 =C2=A0address the Gen-Art review comments. Please go= through the new diffs
> >=C2=A0 =C2=A0 =C2=A0(https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-= scaling-rec-07
> >=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-scaling-rec-07>)
> >=C2=A0 =C2=A0 =C2=A0and let us know if additional changes are requ= ired.
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > Also, please go through the respons= es provided to the other
> >=C2=A0 =C2=A0 =C2=A0review comments and let us know if there are s= till any unanswered
> >=C2=A0 =C2=A0 =C2=A0questions.
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > Regards,
> >=C2=A0 =C2=A0 =C2=A0 > > -Pavan
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > On Tue, Sep 26, 2017 at 2:01 PM, Mi= rja K=C3=BChlewind
> >=C2=A0 =C2=A0 =C2=A0<iet= f@kuehlewind.net <mailto:ietf= @kuehlewind.net>> wrote:
> >=C2=A0 =C2=A0 =C2=A0 > > Mirja K=C3=BChlewind has entered th= e following ballot position for
> >=C2=A0 =C2=A0 =C2=A0 > > draft-ietf-teas-rsvp-te-scalin= g-rec-06: Discuss
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > When responding, please keep the su= bject line intact and reply
> >=C2=A0 =C2=A0 =C2=A0to all
> >=C2=A0 =C2=A0 =C2=A0 > > email addresses included in the To = and CC lines. (Feel free to
> >=C2=A0 =C2=A0 =C2=A0cut this
> >=C2=A0 =C2=A0 =C2=A0 > > introductory paragraph, however.) > >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > Please refer to
> >=C2=A0 =C2=A0 =C2=A0https://www.ie= tf.org/iesg/statement/discuss-criteria.html
> >=C2=A0 =C2=A0 =C2=A0<https://ww= w.ietf.org/iesg/statement/discuss-criteria.html>
> >=C2=A0 =C2=A0 =C2=A0 > > for more information about IESG DIS= CUSS and COMMENT positions.
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > The document, along with other ball= ot positions, can be found here:
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-re= c/ <https://datatracker.= ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/>
> >
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0-----------------------------------------= -----------------------------
> >=C2=A0 =C2=A0 =C2=A0 > > DISCUSS:
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0-----------------------------------------= -----------------------------
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > I'm uncertain what section 2.1.= 3. actually recommends. My
> >=C2=A0 =C2=A0 =C2=A0understanding is that
> >=C2=A0 =C2=A0 =C2=A0 > > it is recommend to still send retra= nsmit some message even if
> >=C2=A0 =C2=A0 =C2=A0the Rl was
> >=C2=A0 =C2=A0 =C2=A0 > > reached and to that every 30s basic= ally forever. First of all I
> >=C2=A0 =C2=A0 =C2=A0think this
> >=C2=A0 =C2=A0 =C2=A0 > > still needs a termination criteria = when to stop to try to
> >=C2=A0 =C2=A0 =C2=A0retransmit finally.
> >=C2=A0 =C2=A0 =C2=A0 > > And the I don't understand why = this is needed, instead of e.g.
> >=C2=A0 =C2=A0 =C2=A0just using a
> >=C2=A0 =C2=A0 =C2=A0 > > larger Rl value? Can you please cla= rify!
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0-----------------------------------------= -----------------------------
> >=C2=A0 =C2=A0 =C2=A0 > > COMMENT:
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0-----------------------------------------= -----------------------------
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > I fully agree with the gan-art revi= ew (Thanks Elwyn!) and
> >=C2=A0 =C2=A0 =C2=A0Alvaro, that this
> >=C2=A0 =C2=A0 =C2=A0 > > reads from time to time like a BCP = but is actually a extension
> >=C2=A0 =C2=A0 =C2=A0specification. I
> >=C2=A0 =C2=A0 =C2=A0 > > would strongly recommend to apply t= he changes proposed by the
> >=C2=A0 =C2=A0 =C2=A0gen-art review,
> >=C2=A0 =C2=A0 =C2=A0 > > and there is also a very detailed l= ist of nits/edits that
> >=C2=A0 =C2=A0 =C2=A0should probably be
> >=C2=A0 =C2=A0 =C2=A0 > > applied. Please have a look at that= !
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > ______________________________= _________________
> >=C2=A0 =C2=A0 =C2=A0 > > Teas mailing list
> >=C2=A0 =C2=A0 =C2=A0 > > Te= as@ietf.org <mailto:Teas@ietf.org>
> >=C2=A0 =C2=A0 =C2=A0 > > https://www.ietf.o= rg/mailman/listinfo/teas
> >=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mail= man/listinfo/teas>
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 >
> >
> >
> >
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas<= /a>
> >
> >
>
>

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

--00000000000029841b05651bf34b--