Re: [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06
Elwyn Davies <elwynd@dial.pipex.com> Fri, 29 September 2017 17:50 UTC
Return-Path: <elwynd@dial.pipex.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 53D0213337F; Fri, 29 Sep 2017 10:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 ZNP7slYlcV8Y; Fri, 29 Sep 2017 10:50:31 -0700 (PDT)
Received: from a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [81.187.30.51]) (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 56775128D0D; Fri, 29 Sep 2017 10:50:31 -0700 (PDT)
Received: from 153.107.2.81.in-addr.arpa ([81.2.107.153] helo=[192.168.0.128]) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <elwynd@dial.pipex.com>) id 1dxzB3-0004et-T6; Fri, 29 Sep 2017 18:34:21 +0100
Date: Fri, 29 Sep 2017 18:34:09 +0100
Message-ID: <8wh65ldo8qkrghsf29x4nukb.1506702288623@email.android.com>
Importance: normal
From: Elwyn Davies <elwynd@dial.pipex.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Cc: gen-art@ietf.org, draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, ietf <ietf@ietf.org>, "teas@ietf.org" <teas@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_154488561075070"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ERcF-1L_FrAZBsDH_huzgAIOfxw>
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, 29 Sep 2017 17:50:39 -0000
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. 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. 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. 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.- 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? 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. I think you need to think through what happes in the various possible cases and explain what an implementation should do in each case.- 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. Does this last modification constitute an update of RFC 2209? I am not sure -consult your AD! Regards,Elwyn Sent from Samsung tablet. -------- Original message --------From: Vishnu Pavan Beeram <vishnupavan@gmail.com> Date: 28/09/2017 03:48 (GMT+00:00) To: Elwyn Davies <elwynd@dial.pipex.com> Cc: gen-art@ietf.org, draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, ietf <ietf@ietf.org>, 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) 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> 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>. 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 https://www.ietf.org/mailman/listinfo/teas
- 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