Subject: [Gen-art] Re: Gen-art review of draft-ietf-ccamp-rsvp-restart-ext-05

From: Ross Callon <[email-masked]>
Date: Wed, 04 Oct 2006 22:24:00 -0400

I gather from reading through this exchange, and through the
document, that an update will be needed before the document
is put on the IESG agenda.

I don't expect to have any additional comments, and thus
suggest that you go ahead and update the draft to respond
to the Gen-ART comments. Let me know when the update
is available. For now I will change the state to "revised ID
needed".

Thanks, Ross

At 08:55 AM 9/12/2006 -0700, Arun Satyanarayana wrote:
>Hi Elwyn,
>
>Thanks much for the review. Please find responses inline.
>
>Regards,
>Arun (and co-authors)
>==============================================================
>Elwyn Davies wrote:
>
>>I am the assigned Gen-ART reviewer for
>>draft-ietf-ccamp-rsvp-restart-ext-05.txt. For background on Gen-ART, 
>>please see the FAQ at
>><http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>>Please consider these comments along with any other last call comments 
>>you may receive.
>>Summary
>>=======
>>Generally an excellent document.  I am not sufficiently familiar with
>
>Thanks much.
>
>>the details of GMPLS RSVP to be sure that the technical specification of 
>>state recovery are correct but nothing stuck out as missing or broken.
>>The one significant issue that I would suggest might need additional 
>>justification/consideration is the implication that it should be used 
>>after the control plane has suffered a security attack (s6, para 3). 
>>RFC3473 specifies the original restart mechanisms for use after faults 
>>and says nothing about security attacks. I would think that if a 
>>particular node has suffered an attack that requires RSVP-TE restart, 
>>there would be concerns about the whole chain of RSVP-TE nodes.  I would 
>>particularly worried about restarting an ingress node in these 
>>circumstances.  Would it be possible for a compromised node further down 
>>the chain to force a restart and load inappropriate state?  I don't know 
>>if this is feasible but I'd want to be sure this couldn't happen.
>
>Agree that the text is a bit open to interpretation. The basic surmise
>here is that the RSVP agent was already protected against a security
>breach (via means detailed in RFC2747). So, RSVP signaling state itself
>is not compromised. However, due to some other part of the control plane
>suffering a more penetrative attack, it is possible that the entire
>control plane is restarted to clear such compromised state. The text
>refers to RSVP state recovery under these conditions. Will re-work the
>text to reflect this, if you feel this is more explicit in indicating
>the case in question.
>
>>I have the impression that a graceful restart is going to create a fair 
>>bit of traffic on a router with many paths set up.  I didn't see any 
>>suggestions for values of the Recovery Period and its relationship to 
>>number of paths to recover - summarizing the total messages per path 
>>involved in recovery might help give a handle on this.
>
>Recovery times and actual number of messages are very dependant on the
>following factors at least:
>  - The CPU speed on which the restarting as well as neighboring RSVP
>    agents reside on.
>  - The CPU availability during the Recovery Period (there may be routing
>    and/or other control plane being recovered during this period).
>  - Actual implementation specifics that affect the time taken to
>    communicate with the hardware to read current connection state:
>    one implementation may be able read the current connection and label
>    state via an intermediate software agent quickly; there could be
>    another implementation may choose to superimpose recovered state
>    on existing data-plane state and depend on errors if any to validate
>    state being recovered.
>  - Forwarding plane flush timers: ingress agents that reside on
>    packet-originating nodes would possibly have other timers on the
>    forwarding plane that dictate the upper bound on the Recovery Period.
>    As an example, it is critical to know that a GMPLS LSP used as an
>    IP nexthop interface is still available for forwarding - the
>    keepalive mechanism could be RSVP signaling state combined with
>    RSVP hellos.
>
>These factors make such text far too open-ended to introduce in this
>I-D. It is preferable to suggest values in a companion Informational/BCP
>document (hopefully based on real numbers gathered from operational
>networks).
>
>>Otherwise there are a few minor comments, mostly editorial.
>>Details
>>=======
>>s3, para 8: The name of the Capability object seems a bit general for 
>>something which is very specific to the RecoveryPath mechanism.  It might 
>>be better to use something like RECOVERYPATH_CAP (to match with RESTART_CAP.
>
>The nomenclature was chosen so since the object is carried in Hellos and
>there are bits available for carrying other capability information in
>the future. Will change the name if you feel strongly about this.
>
>>s4.2: Reserved bits SHOULD be ignored on receipt to allow extensions.
>
>Thanks for catching this. Will change.
>
>>s4.2.1, para 1, 2nd sentence: s/All nodes/All such nodes/
>
>Will change.
>
>>s4.4.1: The fact that a node is 'capable' of sending RecoveryPath 
>>messages should not force it to announce and use this capability.  I 
>>think this should start something like: 'In order to announce that a node 
>>is capable of sending RecoveryPath messages, it MUST include the 
>>Capability object...'.  This allows administrative disabling/disguise of 
>>the capability.
>
>Intent was the same. However, suggested text certainly carries the
>sub-text better. Will change.
>
>>s4.4.2, para 3: '...it MUST treat the downstream neighbor..' - this is 
>>not a sensible 'requirement'.  I think it means that 'the receiving node 
>>is able to expect that the downstream neighbor can send RecoveryPath messages'.
>
>Ok. Will change "MUST" to "can".
>
>>s4.4.2, last para: Should something be said about any partial state that 
>>has already been recovered when the transition happens?  I don't know 
>>enough about the details of the two processes to know if this could cause 
>>problems with interactions between the two processes.
>
>This is covered in s4.5.2.3 (Procedures on Expiration of Recovery
>Period). The restarting node cannot make a decision reliably on partial
>state until the expiration of the Recovery Period.
>
>>s5.2.1, para 2:  This piece has got a bit garbled - apart from the 
>>editorial, do you mean Srefresh mesages?
>>
>>>
>>>   When the
>>>    restarting node does not desire the receipt of Reco=eryPath 
>>> messages,   see Section 4.4.2, or, the selective transmission mechanism 
>>> defined in this section, ...
>
>Will change to:
>To indicate to an RSVP neighbor that selective transmission of
>RecoveryPath messages is desired, a node MUST set (1) the S-bit in the
>Capability object in all Hello messages it sends. When the restarting
>node does not desire the receipt of RecoveryPath messages (see Section
>4.4.2 - Procedures for the Restarting Node), or, the selective
>transmission mechanism defined in this section, it MUST clear (0) the
>S-bit in the Capability object if included in Hello messages.
>
>>s5.2.1, last para: As with s4.4.2, does anything need to be said about 
>>partial state already recovered?
>
>Handling of partially recovered state is covered in s4.5.2.3 (Procedures
>on Expiration of Recovery Period). Since the SRefresh procedures are
>only an optimization to the RecoveryPath procedures defined earlier in
>the document, no explicit text has been included to handle partial
>state.
>
>Will include text if you feel strongly about this.
>
>>s6, para 4: s/minilmalized/minimized/
>
>Thanks! Will do.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Arun Satyanarayana <[email-masked]>
Date: Thu, 05 Oct 2006 16:08:09 -0700

Hi Ross,

Thanks much for the follow-up. I'll submit the revised version
within the couple of days.

Regards,
Arun
Ross Callon wrote:

>>> Please consider these comments along with any other last call 
>>> comments you may receive.
>>> Summary
>>> =======
>>> the details of GMPLS RSVP to be sure that the technical specification 
>>> of state recovery are correct but nothing stuck out as missing or 
>>> broken.
>>> RFC3473 specifies the original restart mechanisms for use after 
>>> faults and says nothing about security attacks. I would think that if 
>>> a particular node has suffered an attack that requires RSVP-TE 
>>> restart, there would be concerns about the whole chain of RSVP-TE 
>>> nodes.  I would particularly worried about restarting an ingress node 
>>> in these circumstances.  Would it be possible for a compromised node 
>>> further down the chain to force a restart and load inappropriate 
>>> state?  I don't know if this is feasible but I'd want to be sure this 
>>> couldn't happen.
>>
>>
>>> I have the impression that a graceful restart is going to create a 
>>> fair bit of traffic on a router with many paths set up.  I didn't see 
>>> any suggestions for values of the Recovery Period and its 
>>> relationship to number of paths to recover - summarizing the total 
>>> messages per path involved in recovery might help give a handle on this.
>>
>>
>>> something which is very specific to the RecoveryPath mechanism.  It 
>>> might be better to use something like RECOVERYPATH_CAP (to match with 
>>> RESTART_CAP.
>>
>>
>>> think this should start something like: 'In order to announce that a 
>>> node is capable of sending RecoveryPath messages, it MUST include the 
>>> Capability object...'.  This allows administrative disabling/disguise 
>>> of the capability.
>>
>>
>>> s4.4.2, para 3: '...it MUST treat the downstream neighbor..' - this 
>>> is not a sensible 'requirement'.  I think it means that 'the 
>>> receiving node is able to expect that the downstream neighbor can 
>>> send RecoveryPath messages'.
>>
>>
>>> s4.4.2, last para: Should something be said about any partial state 
>>> that has already been recovered when the transition happens?  I don't 
>>> know enough about the details of the two processes to know if this 
>>> could cause problems with interactions between the two processes.
>>
>>
>>>> messages,   see Section 4.4.2, or, the selective transmission 
>>>> mechanism defined in this section, ...
>>
>>
>> Will change to:
>>> s5.2.1, last para: As with s4.4.2, does anything need to be said 
>>> about partial state already recovered?
>>
>>

---

From: Arun Satyanarayana <[email-masked]>
Date: Thu, 05 Oct 2006 16:05:56 -0700

Hi Elwyn,

My apologies for the late response on this.

Please find responses inline.

Regards,
Arun
Elwyn Davies wrote:

> <eliminating agreed items.
> 
> Arun Satyanarayana wrote:
> 
>> Hi Elwyn,
>>
> I do think this needs more explanation.

Will add text to this effect.

> Clearly there are difficulties in expressing the full problem but your 
> own last point would be a good one to make since it is not performance 
> dependent.  Just a sentence reminding people how much time is needed per 
> LSP (one round trip time or whatever) would be a good idea.

Ok, will do.

> I don't feel terribly strongly, but it is not clear to me that the 
> semantics of CAPABILITY (tied to RESTART_CAP) make it useful for 
> anything except other restart associated capabilities, so the generic 
> name might be confusing.

Hmmm... not the idea the authors intended to convey. We have explicitly
allowed the Capability object to be carried in all Hellos. Also, there
is no text tying it's presence to one of the bits defined in this I-D. I
feel this is sufficient to allow its use to convey other Capabilities as
well in the future.

> Hmm!  I am not sure that this statement doesn't actually make matters 
> worse!  So what does it do between the time the bit switches and the end 
> of the recovery period?
 >
> Clearly we don't want very elaborate statements about all of this 
> because it is going to be a rare event (I assume).  However, I think you 
> need to be absolutely clear whether the restarting node should accept 
> the partial state that it has got before the bit switches or discard it 
> and behave as if it never got any refreshed state.  I am unclear as to 
> whether this last (discard process) is possible and whether the state 
> could be in an inconsistent state (too many states) as a result of the 
> partial interchange.

Would the following text added to the end of s4.4.2 be sufficient to
address your concern?
   Specifically, the restarting node MUST continue processing of
   all Path messages containing a Recovery_Label object, that have been
   received and saved per procedures defined in Section 4.5.2.1. Such
   processing MUST follow procedures for handling a Path message with a
   Recovery_Label object as defined in Section 9.5.2 of RFC3473.

> Depends a bit on what you say about the other case.  Make it clear what 
> it ought to do to continue.

Will add text referring to the new text suggested above.

> /Elwyn