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 <[email protected]> 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. > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
