Re: [Teas] Mirja Kühlewind's Discuss on draft-ietf-teas-rsvp-te-scaling-rec-06: (with DISCUSS and COMMENT)
Vishnu Pavan Beeram <vishnupavan@gmail.com> Fri, 22 December 2017 07:44 UTC
Return-Path: <vishnupavan@gmail.com>
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 D4BF912AF83; Thu, 21 Dec 2017 23:44:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 by6Qg7tAFnL0; Thu, 21 Dec 2017 23:44:07 -0800 (PST)
Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (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 5405212D810; Thu, 21 Dec 2017 23:44:07 -0800 (PST)
Received: by mail-pl0-x229.google.com with SMTP id g2so12493612pli.8; Thu, 21 Dec 2017 23:44:07 -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=OGWQeQmn+xu64+/Q7IkH449wqECwnmiNMybWaNRSNf4=; b=qb856P3mgszvKf16RUH6TdWCmonBmFCAq+vgO3FlQIdu+9XU1kiwAn9iNwgn0dsKue k+9yIjkLQk36moEBcil9VFRggpuTc6BvJS3JoKmrDx5oqjHjReahpr+o9C1T81bYpDaN nU99WINLCXgpjPdPbKZ4T4M/9jFAkVVHR+dc3rHYIbytzNi6aZ2RmX4KOCpzFcmpGhcT t5vmtHR69gEmeCEz+8aXGKKE04ZRdpI97xbCcvIWCufpguB/jra48sSCSskMmzv8OocD MujYKv+eQcD13F0b+OyItXwBjTZqygPG+7rOoXf7Wz2ZxhKDu980U1v+eEvNf1rck4/1 db3w==
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=OGWQeQmn+xu64+/Q7IkH449wqECwnmiNMybWaNRSNf4=; b=gHXhD/GeQJgJLubWjZU/ZcGJGNfUg1oHWi1cDjsk/kjsud3UyWIIe778ZEhaHtsGB+ CjH3N3UE4Q2z4t4C5lwkWEmYkW3CzstDesQ7rc0nDFq+UGBX61LYqvSA2DeBjRHS6iKy ZbIS13e7bfavaTYqOCy4wJ+owbMLSoB17bRZJkxgIdZ9aA9zbZeKO/DVw4jWMzK3njTu ZmDtrNhKyJfpvGs4VozNGiFTYghSKuKie/MtIh8EVDxGpDU+IfUM3+Mge3jz5CfPP2Qd 4uG71I7qflq+mdiQ6eOct60JSeN2P0QjL4kTebQmj9vsu1inemR+EaqEV6Y4El/eQjzv o04w==
X-Gm-Message-State: AKGB3mLGovr0MwwSbhmWnqdOOtjUyOJuVOSjKLsGBaYNa9rfHxxDxufL SySLkxjsQp8BSO2j38AEGXFD2oOOSTE3ARZ6gMQ=
X-Google-Smtp-Source: ACJfBov1s4gMr9DXith7C5qFu7IWjBsIKXI9Ny0xlkhQ7vezjlYqGTWYc3Aht9EmE6VUEZggMDA/oO65wCmDQSr1vHg=
X-Received: by 10.159.196.135 with SMTP id c7mr13277740plo.197.1513928646794; Thu, 21 Dec 2017 23:44:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.170.203 with HTTP; Thu, 21 Dec 2017 23:44:06 -0800 (PST)
In-Reply-To: <cfda7846-8637-f6c7-07dc-9979bd2fa7b2@labn.net>
References: <150644890311.20830.6212136664552694640.idtracker@ietfa.amsl.com> <CA+YzgTtqT9Ojs8Ed8fwW3FCLGVaJMTgCxsonH1Gxe-H7Q85orA@mail.gmail.com> <BBCF6104-8351-4C90-BD38-6A515DCAB9E5@kuehlewind.net> <CA+YzgTt77KmC1g2+C==c0F2BxWS0PEiuP-R0SNvWiv=_OO7s9Q@mail.gmail.com> <FFA062AD-A257-4AA8-8DE6-C7B03330DF81@kuehlewind.net> <CA+YzgTsqAyWY=gepg=moJCmDr=JDTop_sy-+SHJ8u1qn8g2jsQ@mail.gmail.com> <cfda7846-8637-f6c7-07dc-9979bd2fa7b2@labn.net>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Fri, 22 Dec 2017 02:44:06 -0500
Message-ID: <CA+YzgTt-8g7-7juWg0zBqah=CPLVzktGacWa19rFoK5XoSMy4g@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Cc: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, TEAS WG Chairs <teas-chairs@ietf.org>, The IESG <iesg@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="089e082e0c243524560560e8fbd5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/8KYbORBVFK_faKOq8Wi-nFwqCE0>
Subject: Re: [Teas] Mirja Kühlewind's Discuss on draft-ietf-teas-rsvp-te-scaling-rec-06: (with DISCUSS and COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Dec 2017 07:44:11 -0000
Mirja, Hi! Please see if the responses above address your concerns. Please let 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: >> >> Hi Vishnu, >> >> I don’t 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.“ >> >> > 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 this >> 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 <scaling-rec> 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 and >> 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 <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 (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 >> <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>: >> >> > >> > Mirja, Hi! >> > >> > This was discussed in my response to Elwyn. I apologize for not >> responding directly. >> > >> > RFC2961 doesn't discuss what to do with the retransmissions after >> the retry limit is reached. It doesn't discuss how retransmissions >> 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 these >> transmissions get paced after the rapid retry limit is reached. The >> slower timer transmission will go on until either an ack is received >> (at which point the regular "refresh interval" comes into play) or >> the corresponding LSP instance state is torn down. >> > >> > ---- >> > (2) Why couldn't the regular refresh interval be used for these >> 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 interval >> 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 message. >> > >> > 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 20m >> refresh state. >> > >> > --- >> > >> > Do these two responses adequately answer your questions? >> > >> > Regards, >> > -Pavan >> > >> > On Thu, Oct 5, 2017 at 7:57 AM, Mirja Kuehlewind (IETF) >> <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote: >> > Hi Pavan, >> > >> > I don’t see any changes in the new version that addresses 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 >> <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>: >> > > >> > > Mirja, Hi! >> > > >> > > Thanks for the review. We just posted a new revision (-07) to >> address the Gen-Art review comments. Please go through the new diffs >> (https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-s >> caling-rec-07 >> <https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-s >> caling-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ühlewind >> <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote: >> > > Mirja Kühlewind has entered the following ballot position for >> > > draft-ietf-teas-rsvp-te-scaling-rec-06: Discuss >> > > >> > > When responding, please keep the subject line intact and reply >> 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 >> <https://www.ietf.org/iesg/statement/discuss-criteria.html> >> > > for more information about IESG DISCUSS and COMMENT positions. >> > > >> > > >> > > The document, along with other ballot positions, can be found >> here: >> > > >> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ >> <https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-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 if >> the Rl was >> > > reached and to that every 30s basically forever. First of all 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 extension >> specification. I >> > > would strongly recommend to apply the changes proposed by the >> 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 <mailto:Teas@ietf.org> >> > > https://www.ietf.org/mailman/listinfo/teas >> <https://www.ietf.org/mailman/listinfo/teas> >> > > >> > >> > >> >> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >>
- [Teas] Mirja Kühlewind's Discuss on draft-ietf-te… Mirja Kühlewind
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Vishnu Pavan Beeram
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Vishnu Pavan Beeram
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Vishnu Pavan Beeram
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Lou Berger
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Vishnu Pavan Beeram
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Lou Berger
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Vishnu Pavan Beeram
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Vishnu Pavan Beeram
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Vishnu Pavan Beeram
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Vishnu Pavan Beeram
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Teas] Mirja Kühlewind's Discuss on draft-iet… Vishnu Pavan Beeram