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

[Vishnu Pavan Beeram <[e-mail]>]

Elwyn, Hi!

Please see if the responses above address your concerns. Please let us know
if there are any issues with progressing this document.

Regards,
-Pavan

On Sun, Nov 12, 2017 at 9:59 PM, Vishnu Pavan Beeram <[e-mail]>
wrote:

> Elwyn, Hi!
>
> Apologize for the delayed reply.
> We posted a new rev (-08) to address the comments that have been raised so
> far. Please do take a look at the diffs and see if your concerns are
> adequately addressed.
>
> Please see inline for responses (prefixed [VPB])
>
> Regards,
> -Pavan
>
> Snipped..
>
> >>
>>> >>     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.
>>>
>> 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.
>>
>
> [VPB] We added a statement in Section 1 to make this explicit.
> **
>
> Snipped..
>
>>
>> >>
>>> >>     -  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.
>>>
>> 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!
>>
>>
> [VPB] Inactivation of "Refresh-Reduction" Capability will immediately
> inactivate both the "capabilities" discussed in the draft. This means that
> the implementation would immediately fall back on to traditional non-2961
> RSVP procedures (and stop following the procedures outlined in sections 3
> and 4). We added an explicit statement to the draft saying that
> "Inactivation of the RI-RSVP functionality MUST result in the use of the
> traditional smaller refresh interval". We believe implementations don't
> need any further guidance in order to cater to this "revert to traditional
> procedures" requirement. Note that implementations today already know how
> to handle "disabling/enabling" of the "Refresh-Reduction" capability knob
> (this includes disabling/enabling per-session flow control). They already
> know how to handle adjustments to "refresh-interval".
>
>> >>
>>> >>
>>> >> [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-2Dretr
>>> y-2D01&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoC
>>> I&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=k7e-
>>> cloxf90XW9b_KRgpp7fxJRT4Q-f-_Nor0jTe8fg&s=XXwwGPXiCQhVIgNDb
>>> iHxKEuHs1fkmMoiGQsHcQ33ZQE&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.
>>>
>> 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.
>>
>
> [VPB] There is really no need to specify a new algorithm for setting L. It
> is understood that having a large refresh-interval will significantly
> increase the L value. With the procedures defined for "RI-RSVP", we have
> completely eliminated RSVP's reliance on refreshes and refresh-timeouts. A
> smaller "L" value is important only if you are relying on refresh-timeouts
> to clean up state.
>
>