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

From: Elwyn Davies <[email-masked]>
Date: Fri, 08 Sep 2006 20:04:42 +0100

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

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.

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.

s4.2: Reserved bits SHOULD be ignored on receipt to allow extensions.

s4.2.1, para 1, 2nd sentence: s/All nodes/All such nodes/

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.

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.

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, ...
>
s5.2.1, last para: As with s4.4.2, does anything need to be said about 
partial state already recovered?

s6, para 4: s/minilmalized/minimized/

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

---

From: Arun Satyanarayana <[email-masked]>
Date: Tue, 12 Sep 2006 08:55:10 -0700

Hi Elwyn,

Thanks much for the review. Please find responses inline.

Regards,
Arun (and co-authors)
==============================================================

> Generally an excellent document.  I am not sufficiently familiar with 

Thanks much.

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

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

> might be better to use something like RECOVERYPATH_CAP (to match with 

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.

> Capability object...'.  This allows administrative disabling/disguise of 

Intent was the same. However, suggested text certainly carries the
sub-text better. Will change.

> is able to expect that the downstream neighbor can send RecoveryPath 

Ok. Will change "MUST" to "can".

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

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

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

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 12 Sep 2006 18:17:00 +0100

<eliminating agreed items.

Arun Satyanarayana 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 do think this needs more explanation.
>
>> 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.
>
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.
> the future. Will change the name if you feel strongly about this.
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.
>
>
>
>> 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.
>
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.
>
>
>> s5.2.1, last para: As with s4.4.2, does anything need to be said 
>> about partial state already recovered?
>
Depends a bit on what you say about the other case.  Make it clear what 
it ought to do to continue.

/Elwyn