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

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

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-
>> 2Dretry-2D01&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-nd
>> b3voDTXcWzoCI&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.
>>
> 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.