Re: [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06
Vishnu Pavan Beeram <vishnupavan@gmail.com> Fri, 06 October 2017 21:23 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 DCD9C133075; Fri, 6 Oct 2017 14:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 m0tFJ7qjZKbQ; Fri, 6 Oct 2017 14:23:51 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 AC86B13239C; Fri, 6 Oct 2017 14:23:51 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id m16so8782856iod.1; Fri, 06 Oct 2017 14:23:51 -0700 (PDT)
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=0vBgDPK/l8wnc2vfuB8vJGy6aC368pzO/5hFJ2oJfXw=; b=Xtau0UOLaomBKbQf2gst+mt4dtZ//01su8KDucihxLncUloI41gMc+IHUxxdZtdtjH gnoXdkJLVrD3sKhY7tpbcIKtUuBaTPtnvC6plkR0lbVUUV2rnIG34MRxptc7+I12YjbS L++aLBfSc0V0toCtQyC6tGtcO9Te/IZc3WxETN1hCmyh8VCUNxUVfKerumkL+1Kqi89I 1ExCRVlbyrcM1mvSqloz/dJdaMgehKiTqUqt2uqESrEuqmBZnAEG00Fy8UlV7ABRe9Sp RCIlCH7xIXIYOXL7NDSIHck0MrEbFLaIB/I2at2eaNSQP5WZFWKTl+LE4DVxo65ql5gr EKLQ==
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=0vBgDPK/l8wnc2vfuB8vJGy6aC368pzO/5hFJ2oJfXw=; b=Ri77Sbwc7qZmRgo313foYd6ANjxVlwZxUuWR6ZvUbKq1LFAvQt55Whe2CHy7KwrxjH klPXGI2+W10l/6yT3kkJhNnOCKhtAVuV0pGSQT+g/p5nQpViWhdEl5qEsktoX7BqoC5V fKiahTV+hQmKklnArLJgdBMl7gUAyfS9CxTHkgMSPnijxUuykL7DYceFvTtV4XYhe8Nq lzvtaGUK9myLC5Gsldwf3Z9BiOpkZk59eeALSkBmJ4O9Wph3y38F/qRfgCiWOe7PnaXX pS1zpulZvFMTDEGfw7VUbQ8jKeXvG/ZiexnOynt7tWNh/Cxjhp2msIwmBIGrUQfg/Vk/ OidA==
X-Gm-Message-State: AMCzsaXSBTmNovWpmGGiP7gCh+ceb0kSRfOKix+IaZOlyk/slO+RKXaP 4EeOjqIk880GHCEEH6+V8qVNRgbqF6W+vxRA0YU=
X-Google-Smtp-Source: AOwi7QDx9ymwNC7fAZjSJjrNS4T2jBwR1YTuMsMcuAyEHnfR4206V+Zmvc2knbpnCAwl5JX6y77toptjHmEYbrec8SY=
X-Received: by 10.107.143.3 with SMTP id r3mr4596461iod.272.1507325030940; Fri, 06 Oct 2017 14:23:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.15.140 with HTTP; Fri, 6 Oct 2017 14:23:50 -0700 (PDT)
In-Reply-To: <2cdc53f9-11c4-40d7-c37c-09b747b763f6@labn.net>
References: <8wh65ldo8qkrghsf29x4nukb.1506702288623@email.android.com> <CA+YzgTuUcUxzoGHx2_mF+k0wu=X52ervTwuMk=fVEKTWNV=jjA@mail.gmail.com> <15eec201498.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <B1AAF8A9-FC5C-41D2-928F-F6E144C9AEFE@juniper.net> <2cdc53f9-11c4-40d7-c37c-09b747b763f6@labn.net>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Fri, 06 Oct 2017 17:23:50 -0400
Message-ID: <CA+YzgTvt_pVQWMQ6PBBJDUAxGE4b1soJ5ePsYVA7DsK+7Xsppw@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Cc: Vishnu Pavan Beeram <vbeeram@juniper.net>, Elwyn Davies <elwynd@dial.pipex.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org" <draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org>, "teas@ietf.org" <teas@ietf.org>, ietf <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05910807c5c1055ae77514"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/hOEMZv7iWEOrGPwO658WIWkkW5E>
Subject: Re: [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06
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, 06 Oct 2017 21:23:58 -0000
Lou, Thanks for the response. I think that settles the "update" debate. Elwyn, Hi! Are you satisfied with my other responses? I'll submit a new revision as agreed in my responses. Regards, -Pavan On Fri, Oct 6, 2017 at 3:31 PM, Lou Berger <lberger@labn.net> wrote: > Hi Pavan, > > On 10/05/2017 07:44 AM, Vishnu Pavan Beeram wrote: > > Lou, Hi! > > > > Responses inline (prefixed PB). > > > > Regards, > > -Pavan > > > > From: Lou Berger <lberger@labn.net <mailto:lberger@labn.net>> > > Date: Thursday, October 5, 2017 at 6:41 AM > > To: "EXT-vishnupavan@gmail.com <mailto:EXT-vishnupavan@gmail.com>" > > <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>, Elwyn Davies > > <elwynd@dial.pipex.com <mailto:elwynd@dial.pipex.com>> > > Cc: "gen-art@ietf.org <mailto:gen-art@ietf.org>" <gen-art@ietf.org > > <mailto:gen-art@ietf.org>>, > > "draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org > > <mailto:draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org>" > > <draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org > > <mailto:draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org>>, > > "teas@ietf.org <mailto:teas@ietf.org>" <teas@ietf.org > > <mailto:teas@ietf.org>>, ietf <ietf@ietf.org <mailto:ietf@ietf.org>> > > Subject: Re: [Teas] Genart last call review of > > draft-ietf-teas-rsvp-te-scaling-rec-06 > > > > Hi Pavan, > > > > WRT if this document updates rfc2961: > > > > I don't have a strong opinion on or objection to this document updating > > rfc2961. To have this document be an update, I do think we and it need > > to be clear on what exactly is being updated in 2961. After rereading > > both it's unclear to me what you see is being updated. As best I can > > see, this document basically relates to 2961 in that it says (a) use the > > reliable message delivery defined in 2961 and (b) restates that 2205 > > refresh processing of path and resv messages still applies after a rapid > > retry period expires and (c) sending acks moves from recommended to > > required. > > > > What did I miss? > > > > FWIW I think (a) and (c) are requirements of this document not 2961 and > > (b) seems like an informative statement that the basic refresh > > processing rules of rfc2205 still apply. > > > > -- > > [PB] This is all about how we interpret (b). RFC2961 doesn’t explicitly > > state what happens the rapid retry period expires. The current draft > > explains what needs to be done. Does this warrant an official update to > > RFC2961? > > The RFC doesn't generally review unmodified RFC2205 processing, nor has > that been the normal practice when defining RSVP extensions. An > informative statement in this draft certainly would do no harm if you > feel that it is needed, but I don't think it raises to the level of an > update. > > Thanks, > Lou > > > > — > > > > Thanks > > Lou > > > > On October 1, 2017 9:14:15 AM Vishnu Pavan Beeram <vishnupavan@gmail.com > > <mailto:vishnupavan@gmail.com>> wrote: > > > >> Elwyn, Hi! > >> > >> Please see inline for responses. > >> > >> Regards, > >> -Pavan > >> > >> On Fri, Sep 29, 2017 at 1:34 PM, Elwyn Davies <elwynd@dial.pipex.com > >> <mailto:elwynd@dial.pipex.com>> wrote: > >> > >> > >> > >> Hi, Pavan. > >> > >> I've checked through the changes in -07 and I think all is good as > >> regards fixing the 'major issue', restucturing s2 and fixing the > >> nits - thanks. > >> > >> > >> [Pavan] Great! > >> > >> > >> Looking at the IESG comments I think you have covered most of > >> them except it would be good to put a pointer to Appendix A into > >> the intro of s2. > >> > >> With reference to Appendix A(d), it would be helpful to s/periodic > >> retransmission interval/Periodic Retransmission Interval/ and > >> possibly give it a name (Rpri or some such) in s2.3 and Appendix > >> A(d). Adding the name of the interval after "retransmission of > >> these on a slower timer" migt mak it clearer also. > >> > >> > >> [Pavan] Ok. We'll add a pointer to the Appendix and also find a short > >> form for the periodic retransmission interval. > >> > >> > >> However, I think you still need to address all three of the minor > >> issues: > >> - Capability object: A 'basic' implementation of RFC 2209/RFC3209 > >> will not include the RFC5063 extensions. > >> > >> > >> [Pavan] I think you meant RFC2205 and not RFC2209. > >> > >> I think you should therefore make it explicit that a prerequisite > >> for your extensions is an implementation of the Capability object > >> as specified in RFC5063 (my proposal for s3) , making it clear > >> that this does not require any of the other functionality of RFC > >> 5063, especially no support for the S bit in the Capabilities. > >> > >> > >> [Pavan] I'm not really sure that "Capability Object" needs a separate > >> prerequisite section. I'll let the Document-Shepherd and our AD take a > >> call on this. Please note that the document also talks about using > >> Node-ID hellos from RFC4558. Would "Node-Hellos/RFC4558" also then > >> need a separate prerequisite section? We added a separate section for > >> RFC2961 because there is a need to explicitly clarify the usage of > >> certain 2961 procedures. With "Capability Object" and "Node Hellos", > >> there isn't anything (IMHO) that needs to be explicitly clarified. We > >> could just add a statement in Section 4.1 saying that you don't need > >> to set any other flags. Would that address your concern about the > >> ambiguity regarding the "Graceful Restart" bits? > >> > >> OLD > >> An implementation supporting the RI-RSVP technique > >> MUST set a new > >> flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello > >> messages. > >> NEW > >> > >> An implementation supporting the RI-RSVP technique MUST set a new > >> flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello > >> messages. This MAY be the only flag set in the object. > >> > >> > >> - Your response regarding what happens if a peer initially > >> acknowledges that it supports the new capabilities by setting the > >> I/F bits in the Capability and sends some messages with the > >> Refresh-Reduction-Capable bit set, but then stops setting the > >> Refresh-Reduction-Capable bit doesn't really address the problem. > >> Would this mean that the receiver should assume that the peer can > >> no longer support the extensions? > >> > >> > >> [Pavan] Yes. > >> > >> Is this a permanent state or could the peer start setting the > >> Refresh-Reduction-Capable bit again and restore initial > >> functionality - or should this just not be allowed. > >> > >> > >> [Pavan] The peer can set the bit again and restore the functionality. > >> > >> I think you need to think through what happes in the various > >> possible cases and explain what an implementation should do in > >> each case. > >> > >> > >> [Pavan] There are only two possibilities -- Is the functionality > >> enabled on the peer or is it not? If the functionality is enabled, the > >> implementation does everything that is specified as required for the > >> given technique. If it is not enabled, then the implementation doesn't > >> employ the technique and just behaves like it does today. We'll try > >> and add some text to make this obvious. > >> > >> > >> - So, I have done my homework and checked back on what happens > >> when there is no acknowledgement of refreshes. The relevant > >> parameter is the cleanup time. However, this leaves us with a > >> problem.. the cleanup time is typically set as a multiple of the > >> refresh interval (9 times seems to be the default) - indeed I see > >> that the interface configuration on a Juniper router (!) actually > >> sets it by asking for the multiple rather than an absolute value. > >> Wth the new dispensation in ths document, there are two time > >> periods involved: I think you do need to respecify how to > >> calculate a sensible cleanup interval, and note that the > >> retransmissions will then halt after this interval. > >> > >> > >> [Pavan] I think you are confusing this with the "setup retry" timer > >> (which comes into play when you signal the PATH setup of an LSP > >> instance and don't get a RESV back). Please go through > >> https://tools.ietf.org/html/draft-ravisingh-teas-rsvp-setup-retry-01 > >> <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__tools.ietf.org_html_draft-2Dravisingh-2Dteas-2Drsvp- > 2Dsetup-2Dretry-2D01&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=k7e- > cloxf90XW9b_KRgpp7fxJRT4Q-f-_Nor0jTe8fg&s=XXwwGPXiCQhVIgNDbiHxKEuHs1fkmM > oiGQsHcQ33ZQE&e=> > >> for a detailed account of setup retry timer, issues associated with it > >> and recommended practices. The staged retransmission (Section 2.3) > >> that comes into play when there is no ACK is different from what you > >> are alluding to -- it is meant for any message seeking ACK (not just > >> PATH). This is very specific to the exponential back-off procedure > >> discussed in Section 6 of RFC2961. As per RFC2961, the rapid > >> retransmissions stop after we reach a certain retry limit. In Section > >> 2.3, we are clarifying what needs to be done after this Retry limit is > >> reached --- the recommendation is to fall back on a not so rapid > >> retransmission interval. As a I said in my previous email, this needs > >> to be done until either an ACK is received or the corresponding state > >> is torn down. > >> > >> > >> Does this last modification constitute an update of RFC 2209? I > >> am not sure -consult your AD! > >> > >> > >> [Pavan] RFC2209 is an informational document that provides guidance on > >> the various data-models and procedures needed for an implementation to > >> be RFC2205 compliant. Most of the content in RFC2209 is outdated > >> (imho). No one has had the inclination over the years to update this > >> and we don't intend to do this either. > >> > >> [Pavan] Reading through the various questions/comments from the IESG, > >> I'm convinced that this document needs to formally update RFC2961. > >> We'll go ahead and do that if the shepherd and our AD have no > objections. > >> > >> > >> > >> Regards, > >> Elwyn > >> > >> Sent from Samsung tablet. > >> > >> -------- Original message -------- > >> From: Vishnu Pavan Beeram <vishnupavan@gmail.com > >> <mailto:vishnupavan@gmail.com>> > >> Date: 28/09/2017 03:48 (GMT+00:00) > >> To: Elwyn Davies <elwynd@dial.pipex.com > >> <mailto:elwynd@dial.pipex.com>> > >> Cc: gen-art@ietf.org <mailto:gen-art@ietf.org>, > >> draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org > >> <mailto:draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org>, ietf > >> <ietf@ietf.org <mailto:ietf@ietf.org>>, teas@ietf.org > >> <mailto:teas@ietf.org> > >> Subject: Re: [Teas] Genart last call review of > >> draft-ietf-teas-rsvp-te-scaling-rec-06 > >> > >> Elwyn, Hi! > >> > >> Thanks for the detailed review and the text suggestions. We just > >> posted a new revision (-07) to address the concerns listed below. > >> Please go through the new diffs > >> (https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te- > scaling-rec-07 > >> <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dteas- > 2Drsvp-2Dte-2Dscaling-2Drec-2D07&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=k7e- > cloxf90XW9b_KRgpp7fxJRT4Q-f-_Nor0jTe8fg&s=xuSuAQ7BlTuE-ue- > 3t5WtAzMMA9cBuBNzk4iM7yoTHs&e=>) > >> and let us know if additional changes are required. > >> > >> Please see inline for further responses (prefixed VPB). > >> > >> Regards, > >> -Pavan > >> > >> On Fri, Sep 22, 2017 at 6:06 PM, Elwyn Davies > >> <elwynd@dial.pipex.com <mailto:elwynd@dial.pipex.com>> wrote: > >> > >> Reviewer: Elwyn Davies > >> Review result: Not Ready > >> > >> I am the assigned Gen-ART reviewer for this draft. The General > >> Area > >> Review Team (Gen-ART) reviews all IETF documents being processed > >> by the IESG for the IETF Chair. Please treat these comments > just > >> like any other last call comments. > >> > >> For more information, please see the FAQ at > >> > >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq > >> <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__trac.ietf.org_trac_gen_wiki_GenArtfaq&d=DwMDaQ&c= > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r= > CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=k7e- > cloxf90XW9b_KRgpp7fxJRT4Q-f-_Nor0jTe8fg&s=7EVfFwYHvGi6M8T035d7tGPQVwgnEJ > q_TzB3RddVx2Q&e=>>. > >> > >> Document: draft-ietf-teas-rsvp-te-scaling-rec-06 > >> Reviewer: Elwyn Davies > >> Review Date: 2017-09-22 > >> IETF LC End Date: 2017-09-22 > >> IESG Telechat date: 2017-09-28 > >> > >> Summary: Not ready, primarily because the title and > >> presentation give the > >> impression that the content is really a BCP when it isn't. > >> This conceals the > >> considerable amount of tweaking of RFC 2961 functionality and > >> addition of new > >> RSVP Capabilities described in the document. There are also a > >> couple of minor > >> issues that need to be sorted out. > >> > >> Major issues: > >> Title and way proposals are presented: The document defines > >> two new > >> 'capabilities' for RSVP-TE and is indeed (as specified in the > >> document header) > >> correctly intended for Standards Track status. However the > >> title and the whole > >> of the meat of the document in Section 2 presents the proposals > as > >> 'recommendations' which says to me that I am expecting a BCP > >> where a profile of > >> available options from existing standards is recommended as > >> the best choice for > >> implementation and deployment. In my opinion, the title would > >> be better as > >> something like "Additional Capabilities Designed to Improve > >> the Scalability of > >> RSVP-TE Deployments". Whilst the proposals are based on the > >> techniques in RFC > >> 2961, the document *requires* the implementor to conform to > >> rules that were > >> optional and constrains configurable values to different > >> ranges in order to be > >> able to deliver the capabilities defined in the document as > >> well as defining > >> new RSVP extensions modifying some of the behaviour defined in > >> RFC 2961. Thus > >> although some of the rules could be met by choosing particular > >> values within > >> the RFC 2961 set, the use of MUST, tweaking of functionality > >> and variation of > >> ranges takes it well beyond a set of recommendations for RFC > >> 2961 options > >> selections. In view of this Section 1 needs to be written as > >> an introduction > >> to the definitions of the new capabilities rather than > >> advocacy for selection > >> of RFC 2961 options and the implication that the techniques > >> mentioned in the > >> last paragraph of s1 are just a matter of selecting a profile > >> of option values. > >> In actuality new protocol values are introduced and ss2.2 and > >> 2.3 define novel > >> extensions to RSVP beyond what is available for RFC 2961 and > >> requiring > >> modification to basic RFC 2961 functionality.. > >> > >> > >> [VPB] We changed the title to "Techniques to Improve the > >> Scalability of RSVP-TE Deployments". We also tweaked the text in > >> the introduction section as suggested. Please see if the new set > >> of diffs address the comment above. > >> > >> Minor issues: > >> Interaction with RFC 5063: The document does not explicitly > >> state that an > >> implementation would need to support (at least) the extra > >> capability obect > >> defined in s4.2 of RFC 5063. Some words about interaction > >> with RFC 5063 are > >> probably required in that s4.2.1 of RFC 5063 rather assumes > >> that if there is a > >> capability object, by default its S bit will be set. > >> > >> > >> [VPB] The CAPABILITY object in RFC5063 is meant for generic use > >> and can be used even when there are no Graceful Restart extensions > >> in play (even when no GR flags are set). As far as we can tell, > >> there is nothing in RFC5063 that precludes this. We added a > >> reference to RFC5063 when the new Capability flags are introduced. > >> Would this be sufficient to address this concern? > >> > >> > >> > >> Behaviour if a node stops setting Refresh-Reduction-Capable > >> bit: The last para > >> of s2 in RFC 2961 discusses behaviour if a node stops setting > >> this bit in > >> messages. What would happen with the extensions defined in > >> this document if > >> this happened while either of the extensions is in use? As a > >> matter of > >> interest, if a peer offers the capabilities defined in this > >> draft, is it > >> possible or sensible for it to stop setting the > >> Refresh-Reduction-Capable bit > >> without stopping offering the extensions? > >> > >> > >> [VPB] If a peer sets the I or F bit in the CAPABILITY object but > >> does not set the Refresh-Reduction-capable bit, then the > >> corresponding functionality ("RI-RSVP" or "Per-Peer Flow-Control") > >> is not activated for that peer. In other words, resetting the > >> Refresh-Reduction-Capable bit immediately makes the node incapable > >> of supporting the two capabilities discussed in this document. > >> This is covered in Sections 3.1 and 4.1 ( -07 version). > >> > >> > >> s2.1.3, para 2: As specified, it appears that the 'slower > >> timer' transmission > >> of Path and Resv messages can go on indefinitely if no ack > >> arrives. What puts > >> an end to this repetition? [It may be that I have forgotten > >> how basic RSVP > >> works, but since this is altering the behaviour it would be > >> good to explain how > >> it terminates, and whether this requires any additional > >> modification to timers.] > >> > >> > >> [VPB] There is nothing new about Path and Resv messages getting > >> transmitted indefinitely (this is normal soft-state signaling > >> behavior) -- all that this section does is discuss how these > >> transmissions are paced in the absence of an ack. 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. > >> > >> > >> Nits/editorial comments: > >> Abstract: RSVP-TE is not a 'well-known' abbreviation: > >> s/RSVP-TE/RSVP Traffic > >> Engineering (RSVP-TE)/ > >> > >> > >> Abstract and s1, first para: This para is not future proof. > >> Suggest: > >> OLD: > >> The scale at which RSVP-TE [RFC3209] Label Switched Paths > >> (LSPs) get > >> deployed is growing continually and there is considerable > >> onus on > >> RSVP-TE implementations across the board to keep up with this > >> increasing demand in scale. > >> NEW: > >> At the time of writing, networks which utilise RSVP Traffic > >> Engineering > >> (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are > >> encountering limitations > >> in the ability of implementations to support the growth in > >> the number of LSPs > >> deployed. This document defines two additional RSVP-TE > >> extensions that > >> are intended to reduce the number of messages needed to > >> maintain RSVP-TE > >> soft state in routers and hence allow implementations to > >> support larger > >> scale deployments. > >> ENDS > >> Note: Omit reference from Abstract. > >> > >> > >> [VPB] Fixed in -07 > >> > >> s1, para 2: s/under certain/beyond a certain/ > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> s1, para 3: s/makes a set of concrete implementation > >> recommendations/defines > >> two extensions/; s/- push higher/by increasing/; s/maintain > >> LSP state./maintain > >> LSP state by reducing the number of messages needed./ > >> > >> Abstract, para 2 and s1, last para: [Omit reference from > >> Abstract] > >> OLD: > >> This document advocates the use of a couple of techniques - > >> "Refresh- > >> Interval Independent RSVP (RI-RSVP)" and "Per-Peer > >> Flow-Control" - > >> for significantly cutting down the amount of processing > cycles > >> required to maintain LSP state. > >> NEW: > >> This document defines two RSVP Capabilities [RFC5063] > "Refresh- > >> Interval Independent RSVP (RI-RSVP)" and "Per-Peer > >> Flow-Control" > >> that will cut down the number of messsages and processing > >> cycles > >> required to maintain LSP state. > >> ENDS > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> s1, last para: Add new penultimate sentence: > >> Note that the "Per-Peer Flow-Control" capability requires > >> the "RI-RSVP" > >> capability as a prerequisite. > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> s1, last para: s/RECOMMENDED/recommended/ - this isn't a > >> recommendation about > >> the protocol on the wire. > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> Subdivision of s2: The issues regarding the nature of the > >> document would be > >> helped by altering s2 into four top level sections, thus: s2: > >> Requirement for > >> RFC 2961 Refresh Overhead Reduction Support and Specific > >> Option Choices (from > >> s2.1) s3: Requirement for RFC 5063 Capability Object support > >> (see Minor Issues > >> above) s4: Refresh-Interval Independent RSVP Capability (from > >> s2.3) s5: > >> Per-Peer RSVP Flow Control Capability (from s2.4) Subsequent > >> major sections > >> then renumbered as s6 onwards. References to s2.x will need to > >> be updated > >> throughout. > >> > >> > >> [VPB] We subdivided s2 into 3 top level sections. We did not add a > >> separate section for discussing RFC5063 Capability Object support. > >> > >> > >> s2.1 (would be introduction of new s2): > >> OLD: > >> The implementation recommendations discussed in this > >> section are > >> based on the proposals made in [RFC2961] and act as > >> prerequisites for > >> implementing the techniques discussed in Sections 2.2 and > 2.3. > >> > >> NEW: > >> The Capabilities defined in Sections 4 and 5 of this > >> document are based on > >> proposals made in [RFC2961]. Implementations of these > >> Capabilities will > >> need to support the RSVP messages and techniques defined in > >> [RFC2961] as set > >> out in Section 2.1 [was 2.1.1] with > >> some minor modifications and alterations to recommended > >> time intervals and > >> iteration counts as defined in the remainder of this section. > >> ENDS > >> > >> > >> [VPB] Fixed in -07 > >> > >> s2.1.1, title and para 1 [will be s2.1]: > >> OLD: > >> 2.1.1. Basic Prerequisites > >> > >> An implementation that supports the techniques discussed in > >> Sections > >> 2.2 and 2.3 must meet certain basic prerequisites. > >> NEW: > >> 2.1. Required Functionality from RFC 2961 to be Implemented > >> > >> An implementation that supports the capabiities discussed > >> in Sections > >> 4 and 5 must provide a large subset of the functionality > >> described > >> in [RFC2961] as follows: > >> ENDS > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> s2.1.2, para 2 [will be s2.2]: s/techniques discussed in > >> Sections 2.2 and > >> 2.3/Capabilities defined in Sections 4 and 5/ > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> s2.1.2, para 2: s/MESSAGE ID/MESSAGE_ID/ > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> s2.2, para 1: s/improvement on transmission > >> overhead/improvement of > >> transmission overhead/ > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> s2.2, para 1: s/proposes sufficient recommendations/sets out > >> additional > >> requirements/ > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> s2.2, last bullet: Add a reference to the proposed new Section > >> 3 that discusses > >> the Capability object. > >> > >> > >> [VPB] Added a direct reference to RFC5063 > >> > >> > >> s2.2.1, last para: s/set Refresh-Reduction-Capable bit in > >> common header/set the > >> Refresh-Reduction-Capable bit in the common header/ > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> s2.3, para 1: s/set of recommendations/functionality/; > >> s/provide/provides/; > >> s/RSVP-TE control plane congestion/a significant portion of > >> the RSVP-TE control > >> message load/ > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> s2.3.2: s/MESSAGE ID/MESSAGE_ID/ > >> > >> > >> [VPB] Fixed in -07 > >> > >> > >> > >> _______________________________________________ > >> Teas mailing list > >> Teas@ietf.org <mailto:Teas@ietf.org> > >> https://www.ietf.org/mailman/listinfo/teas > >> <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_teas&d=DwMDaQ&c= > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r= > CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=k7e- > cloxf90XW9b_KRgpp7fxJRT4Q-f-_Nor0jTe8fg&s=g6wdiVKa0BcV5n4De8h3NjtO0hRGaF > GruAncUJvpq_k&e=> > >> > >> > >> > >
- Re: [Teas] Genart last call review of draft-ietf-… Elwyn Davies
- Re: [Teas] Genart last call review of draft-ietf-… Vishnu Pavan Beeram
- [Teas] Genart last call review of draft-ietf-teas… Elwyn Davies
- Re: [Teas] Genart last call review of draft-ietf-… Vishnu Pavan Beeram
- Re: [Teas] Genart last call review of draft-ietf-… Lou Berger
- Re: [Teas] Genart last call review of draft-ietf-… Vishnu Pavan Beeram
- Re: [Teas] Genart last call review of draft-ietf-… Lou Berger
- Re: [Teas] Genart last call review of draft-ietf-… Vishnu Pavan Beeram
- Re: [Teas] Genart last call review of draft-ietf-… Elwyn Davies
- Re: [Teas] Genart last call review of draft-ietf-… Vishnu Pavan Beeram
- Re: [Teas] Genart last call review of draft-ietf-… Vishnu Pavan Beeram