Re: [Teas] Mirja Kühlewind's Discuss on draft-ietf-teas-rsvp-te-scaling-rec-06: (with DISCUSS and COMMENT)
Lou Berger <lberger@labn.net> Fri, 12 January 2018 13:04 UTC
Return-Path: <lberger@labn.net>
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 C502C12E872 for <teas@ietfa.amsl.com>; Fri, 12 Jan 2018 05:04:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 ZBJFzjF1ibPH for <teas@ietfa.amsl.com>; Fri, 12 Jan 2018 05:04:34 -0800 (PST)
Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CBD12E869 for <teas@ietf.org>; Fri, 12 Jan 2018 05:04:33 -0800 (PST)
Received: from cmgw4 (cmgw5 [10.0.90.85]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 4CD1C175CDA for <teas@ietf.org>; Fri, 12 Jan 2018 06:04:32 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id xR4U1w00j2SSUrH01R4XfN; Fri, 12 Jan 2018 06:04:32 -0700
X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=56brtfLAAAAA:8 a=pGLkceISAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=5xtO9L42cWlhRLNCRncA:9 a=3bRaBsiRyWbU71sz:21 a=zM-E-k4RtqyjLDJC:21 a=QEXdDO2ut3YA:10 a=mYAOWqAtFUkA:10 a=1dbGxDndw2gA:10 a=MR7wyZgDW2UHtLKj5oSU:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=aChj1mRmRhwJ5QyJSXx45A6MO0uht2rZ4LeGr1CeZf4=; b=Jdvm6rJg1TmFtbj0qfQwYgfskF STNzHyJXLl/6yIjoyCWUGJqmbkzUqv9mIic6jppNMgKt6IlMnH3ADL3ssb2Xzi1/nhHMh138ZZEoX orpIf719FIRGJ9lz5W6F3urv6;
Received: from [172.58.184.82] (port=28529 helo=[IPV6:2607:fb90:6507:f7e1:0:19:2234:e601]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <lberger@labn.net>) id 1eZz0W-002gRw-5v; Fri, 12 Jan 2018 06:04:28 -0700
From: Lou Berger <lberger@labn.net>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, Vishnu Pavan Beeram <vishnupavan@gmail.com>
CC: TEAS WG Chairs <teas-chairs@ietf.org>, draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, The IESG <iesg@ietf.org>, teas@ietf.org
Date: Fri, 12 Jan 2018 08:04:25 -0500
Message-ID: <160ea78aba8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <AD4CDD02-ECE6-49ED-886D-3B4631329496@kuehlewind.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> <CA+YzgTt-8g7-7juWg0zBqah=CPLVzktGacWa19rFoK5XoSMy4g@mail.gmail.com> <AD4CDD02-ECE6-49ED-886D-3B4631329496@kuehlewind.net>
User-Agent: AquaMail/1.13.2-730 (build: 101300200)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 172.58.184.82
X-Exim-ID: 1eZz0W-002gRw-5v
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPV6:2607:fb90:6507:f7e1:0:19:2234:e601]) [172.58.184.82]:28529
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/eHHi2Fbbj_a-XkdwyERVaPqsi6Y>
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, 12 Jan 2018 13:04:37 -0000
Umm, perhaps I'm misunderstanding your objection, but the message retransmission strategy is inherent in RSVP's (rfc2205) Soft State approach. Lou On January 12, 2018 7:19:40 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 concern > 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 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-scaling-rec-07 >> <https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-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ü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