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 protected]
https://www1.ietf.org/mailman/listinfo/gen-art
