Subject: Re: [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sun, 1 Oct 2017 09:13:23 -0400

Elwyn, Hi!

Please see inline for responses.

Regards,
-Pavan

On Fri, Sep 29, 2017 at 1:34 PM, Elwyn Davies <[email-masked]> 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 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 <[email-masked]>
> Date: 28/09/2017 03:48 (GMT+00:00)
> To: Elwyn Davies <[email-masked]>
> Cc: [email-masked], [email-masked],
> ietf <[email-masked]>, [email-masked]
> 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 <[email-masked]>
> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 05 Oct 2017 06:41:20 -0400

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.

Thanks
Lou

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 5 Oct 2017 11:44:50 +0000

Lou, Hi!

Responses inline (prefixed PB).

Regards,
-Pavan

From: Lou Berger <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 5, 2017 at 6:41 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Elwyn Davies <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, ietf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06

Hi Pavan,

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?
—

Thanks
Lou

On October 1, 2017 9:14:15 AM Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>> wrote:

Elwyn, Hi!

Regards,
-Pavan

On Fri, Sep 29, 2017 at 1:34 PM, Elwyn Davies <[email-masked]<mailto:[email-masked]>> 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.

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

-  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.

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=XXwwGPXiCQhVIgNDbiHxKEuHs1fkmMoiGQsHcQ33ZQE&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

-------- Original message --------
From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: 28/09/2017 03:48 (GMT+00:00)
To: Elwyn Davies <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, ietf <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
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.

Regards,
-Pavan

On Fri, Sep 22, 2017 at 6:06 PM, Elwyn Davies <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer: Elwyn Davies
Review result: Not Ready

<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=7EVfFwYHvGi6M8T035d7tGPQVwgnEJq_TzB3RddVx2Q&e=>>.

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

[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./

[VPB] Fixed in -07

[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.

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

[VPB] Fixed in -07

[VPB] Fixed in -07

[VPB] Fixed in -07

[VPB] Fixed in -07

[VPB] Fixed in -07

s2.2, last bullet: Add a reference to the proposed new Section 3 that discusses
the Capability object.

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

[VPB] Fixed in -07

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
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=g6wdiVKa0BcV5n4De8h3NjtO0hRGaFGruAncUJvpq_k&e=>

---

From: Lou Berger <[email-masked]>
Date: Fri, 6 Oct 2017 15:31:54 -0400

Hi Pavan,

On 10/05/2017 07:44 AM, Vishnu Pavan Beeram wrote:
> From: Lou Berger <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>, Elwyn Davies
> <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>,
> "[email-masked]
> <mailto:[email-masked]>"
> <[email-masked]
> <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, ietf <[email-masked] <mailto:[email-masked]>>
> 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

>>     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. 
>>
>>     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.
>>
>>
>>     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.
>>
>>
>> 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
>>     -  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.
>>
>>     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.
>>
>>
>> [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=XXwwGPXiCQhVIgNDbiHxKEuHs1fkmMoiGQsHcQ33ZQE&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.
>>
>>
>> [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 
>>
>>     Cc: [email-masked] <mailto:[email-masked]>,
>>     [email-masked]
>>     <mailto:[email-masked]>, ietf
>>     <[email-masked] <mailto:[email-masked]>>, [email-masked]
>>     <mailto:[email-masked]>
>>     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.
>>
>>     On Fri, Sep 22, 2017 at 6:06 PM, Elwyn Davies
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         Reviewer: Elwyn Davies
>>         Review result: Not Ready
>>
>>         <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=7EVfFwYHvGi6M8T035d7tGPQVwgnEJq_TzB3RddVx2Q&e=>>.
>>
>>     [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:
>>     [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?
>>      
>>
>>
>>     [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).
>>
>>
>>     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:
>>         [email-masked] <mailto:[email-masked]>
>>         <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=g6wdiVKa0BcV5n4De8h3NjtO0hRGaFGruAncUJvpq_k&e=>
>>
>>
>>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 6 Oct 2017 17:23:50 -0400

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 <[email-masked]> wrote:

> >> <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=>
> >>     <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=>)
> >>         <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=>>.
> >>
> >>         <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=>
> >>
> >>
> >>
>
>

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 13 Oct 2017 13:37:30 +0100

Hi, Pavan.

Sorry for the delay in replying.

Yes, I meant RFC 2205 in a couple of places where I said RFC 2209. Oops!

I had a think about the points below and I believe there may still be 
things to be noted. My thoughts are inline below.

Cheers,
Elwyn

On 06/10/2017 22:23, Vishnu Pavan Beeram wrote:
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Pavan,
>
>     > From: Lou Berger <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     > To: "[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>"
>     > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>,
>     Elwyn Davies
>     > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     > Cc: "[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>"
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>,
>     <mailto:[email-masked]>
>     > <mailto:[email-masked]
>     <mailto:[email-masked]>>"
>     <mailto:[email-masked]>
>     > <mailto:[email-masked]
>     <mailto:[email-masked]>>>,
>     > "[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>, ietf
>     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     > On October 1, 2017 9:14:15 AM Vishnu Pavan Beeram
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >> Elwyn, Hi!
>     >>
>     >> On Fri, Sep 29, 2017 at 1:34 PM, Elwyn Davies
>     <[email-masked] <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>     >>
>     >>
>     >>
>     >>     Hi, Pavan.
>     >>
>     >>     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.
>     >>
>     >>
>     >> there isn't anything (IMHO) that needs to be explicitly clarified.
>
I think it would be useful to prospective implementors to have a very 
short statement either at the end of s1 or as a new section to say that 
you need to have the Capability Object implemented as this is not 
necessarily in a basic RSVP  implementation or RSVP-TE implementation.  
Since this draft is about RSVP-TE deployments (RFC 3209) you get 
Node-Hellos automatically (and the RFC 4558 clarification is mentioned) 
and doesn't need to be called out explicitly.
>     We
That sounds fine.
>     >>     possible cases and explain what an implementation should do in
What seems to be missing is what should be done if either or both of the 
two capabilities are active on the peer or some of its LSPs when the  
Refresh-Reduction-Capable bit is cleared in a message (which I think 
could be any message from the peer).  If I understand correctly it is 
possible that RI-RSVP might have to be switched off and depending on 
where the RI-RSVP process had got to in terms of sending repeat PATH 
messages, it might be necessary to revert to standard refreshing 
procedures from part way through the revised procedure - I think you 
probably need to be clear about what you would do in terms of where to 
enter the default refresh procedure and whether this means the refresh 
interval should revert to a lower value.   I am not sure whether 
immediately unthrottling the flow control would be desirable either!
>     <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=XXwwGPXiCQhVIgNDbiHxKEuHs1fkmMoiGQsHcQ33ZQE&e=
>     <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=XXwwGPXiCQhVIgNDbiHxKEuHs1fkmMoiGQsHcQ33ZQE&e=>>
No.  I am not talking about the setup-retry timer.  I was thinking about 
the L value (the local state lifetime) as discussed in Section 3.7 of 
RFC 2205.  This is usually defined in terms of a multiple of the refresh 
timer - s3 of the draft suggests that the refresh timer be configured to 
20 minutes making the L value at least an hour in the default case.  
This would mean the slower refresh retries would go on for an hour which 
seems excessive.  I suspect you need to specify an alternative algorithm 
for setting L.
>
>     >>
>     >>
>     >>     Does this last modification constitute an update of RFC
>     2209?  I
>     >>     am not sure -consult your AD!
>     >>
>     >>
This has been addressed in your discussions with Lou.
>     >>     From: Vishnu Pavan Beeram <[email-masked]
>     <mailto:[email-masked]>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >>     To: Elwyn Davies <[email-masked]
>     <mailto:[email-masked]>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >>     Cc: [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>,
>     <mailto:[email-masked]>
>     >>     <mailto:[email-masked]
>     <mailto:[email-masked]>>, ietf
>     >>     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>, [email-masked] <mailto:[email-masked]>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <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=
>     <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=>>)
>     >>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>
>     >>         Reviewer: Elwyn Davies
>     >>         Review result: Not Ready
>     >>
>     >>         I am the assigned Gen-ART reviewer for this draft. The
>     General
>     >>         Area
>     <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=7EVfFwYHvGi6M8T035d7tGPQVwgnEJq_TzB3RddVx2Q&e=
>     <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=7EVfFwYHvGi6M8T035d7tGPQVwgnEJq_TzB3RddVx2Q&e=>>>.
>     >>
>     >>         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
>     >>         'capabilities' for RSVP-TE and is indeed (as specified
>     in the
>     >>         document header)
>     >>         'recommendations' which says to me that I am expecting
>     a BCP
>     >>         where a profile of
>     >>         implementation and deployment.  In my opinion, the
>     title would
>     >>         be better as
>     >>         RSVP-TE Deployments".  Whilst the proposals are based
>     on the
>     >>         techniques in RFC
>     >>         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
>     >>         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
>     >>         Interaction with RFC 5063:  The document does not
>     explicitly
>     >>         state that an
>     >>         of s2 in RFC 2961 discusses behaviour if a node stops
>     setting
>     >>         this bit in
>     >>         this happened while either of the extensions is in
>     use?  As a
>     >>         matter of
>     >>         an end to this repetition?  [It may be that I have
>     forgotten
>     >>         how basic RSVP
>     >>         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
>     >>            At the time of writing, networks which utilise RSVP
>     Traffic
>     >>         Engineering
>     >>            in the ability of implementations to support the
>     growth in
>     >>         the number of LSPs
>     >>            This document advocates the use of a couple of
>     techniques -
>     >>         "Refresh-
>     >>            that will cut down the number of messsages and
>     processing
>     >>         cycles
>     >>            Note that the "Per-Peer Flow-Control" capability
>     requires
>     >>         the "RI-RSVP"
>     >>         helped by altering s2 into four top level sections,
>     thus: s2:
>     >>         Requirement for
>     >>         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.
>     >>
>     >>
>     >>            need to support the RSVP messages and techniques
>     defined in
>     >>         [RFC2961] as set
>     >>            An implementation that supports the techniques
>     discussed in
>     >>         Sections
>     >>            An implementation that supports the capabiities
>     discussed
>     >>         in Sections
>     >>         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.
>     >>
>     >>
>     >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <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=g6wdiVKa0BcV5n4De8h3NjtO0hRGaFGruAncUJvpq_k&e=
>     <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=g6wdiVKa0BcV5n4De8h3NjtO0hRGaFGruAncUJvpq_k&e=>>
>     >>
>     >>
>     >>
>
>