Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart
draft-ietf-ccamp-rsvp-restart-ext-09

[Ballot discuss]
Section 4.1:

The section is neglecting to inform that the format of RecoveryPath message is the same as Reserver message but with message type set in the common header set to the TBD value. Please add a sentence indicating that the MSG Type field will have a different value. Quite obvious but there is no mention about this difference except in the IANA section.

[Ballot discuss]
Based on a security review by Derek Atkins and comments from Sandy
Murphy, please help me understand why the trust model of this spec and
normal operation of RSVP is the same. In particular, what damage can
be done by a malicious peer sending back altered contents of path
messages?  How could the same damage be done in the normal protocol?


It may well be that writing text to cover these issues is too
expensive.  If the authors would like to discuss with me offline that
could work too.  Text is of course preferred if it is relatively easy
to write because then the entire world can review our findings.

[Ballot comment]
Minor open issue from gen-ART review by Elwyn Davies:

My remaining comment relates to the transient situation that could occur as a result of the (hopefully rare) eventuality noted in the last para of s4.4.2, where the node switches from using the new RecoveryPath mechanism back to using the old mechanism part way through recovery (possibly because of a failure downstream?)  My query related to whether the partial state from RecoveryPath messages should be used at all in this case.  I was unclear as to whether there could be a conflict between the partial state and information received after the switch.  The authors claim that the clear up at the end of the Recovery Period (s4.5.2.3) deals with the problem but I am not quite convinced.  I would like to see some justification as to why there is not a problem - I presume the occasion where the switch might occur is when a path switch was in progress resulting in a downstream node change, maybe?  This is an awkward corner case clearly but I think it deserves a sentence (or some real explanaion of why it does not result in a conflict).  A similar issue applies to s5.2.1.

Proto writeup by Adrian Farrel:

Here is the proto write up for draft-ietf-ccamp-rsvp-restart-ext.

Cheers,
Adrian

===

1. Have the chairs personally reviewed this version of the
  Internet Draft (ID), and in particular, do they believe
  this ID is ready to forward to the IESG for publication?

Yes.


2. Has the document had adequate review from both key WG
  members and key non-WG members? Do you have any concerns
  about the depth or breadth of the reviews that have been
  performed?

Pretty good review and implementation.


3. Do you have concerns that the document needs more review
  from a particular (broader) perspective (e.g., security,
  operational complexity, someone familiar with AAA, etc.)?

No concerns.
Note that we have just had review from SecDir that gives rise to the need
for a couple of new sentences (this resulted in -07).


4. Do you have any specific concerns/issues with this
  document that you believe the ADs and/or IESG should be
  aware of? For example, perhaps you are uncomfortable with
  certain parts of the document, or have concerns whether
  there really is a need for it. In any event, if your
  issues have been discussed in the WG and the WG has
  indicated it that it still wishes to advance the document,
  detail those concerns in the write-up.

Some WG members raised issues about how to handle multiple simultaneous
control plane failures. These failures can be handled by the existing
procedures, but are not documented in this I-D. The consensus of the WG was to leave this as it is, and open up a new I-D to show the applicability of these protocol extensions to a variety of failure cases. The alternative of documenting those cases in this I-D was deemed to over-complicate the I-D with second order (or higher) error cases.


5. How solid is the WG consensus behind this document? Does
  it represent the strong concurrence of a few individuals,
  with others being silent, or does the WG as a whole
  understand and agree with it?

Reasonable consensus.


6. Has anyone threatened an appeal or otherwise indicated
  extreme discontent? If so, please summarise the areas of
  conflict in separate email to the Responsible Area
  Director.

No.


7. Have the chairs verified that the document adheres to all
  of the ID Checklist items ?

Yes.


8. Is the document split into normative and informative
  references? Are there normative references to IDs, where
  the IDs are not also ready for advancement or are
  otherwise in an unclear state? (note here that the RFC
  editor will not publish an RFC with normative references
  to IDs, it will delay publication until all such IDs are
  also ready for publication as RFCs.)

All references shown are Normative. This is a correct decision.


9. What is the intended status of the document? (e.g.,
  Proposed Standard, Informational?)

Standards Track


10. For Standards Track and BCP documents, the IESG approval
  announcement includes a write-up section with the
  following sections:

a. Technical Summary

  This document describes extensions to the RSVP Graceful Restart
  mechanisms defined in RFC 3473.  The extensions enable the recovery
  of RSVP signaling state based on the Path message last sent by the
  node being restarted.

  Previously defined Graceful Restart mechanisms, also called recovery
  from nodal faults, permit recovery of signaling state from adjacent
  nodes when the data plane has retained the associated forwarding
  state across a restart.  Those mechanisms do not fully support
  signaling state recovery on ingress nodes or recovery of all RSVP
  objects.

  The extensions defined in this document build on the RSVP Hello
  extensions defined in RFC 3209, and extensions for state recovery on
  nodal faults defined in RFC 3473.  Using these extensions the
  restarting node can recover all previously transmitted Path state
  including the Explicit Route Object and the downstream (outgoing)
  interface identifiers.  The extensions can also be used to recover
  signaling state after the restart of an ingress node.

  The extensions optionally support the use of Summary Refresh, defined
  in RFC 2961, to reduce the number of messages exchanged during the
  Recovery Phase when the restarting node has recovered signaling state
  locally for one or more LSPs.

b. Working Group Summary

The WG consensus process was smooth.

c. Protocol Quality

The extensions are implemented and deployed by a number of optical vendors. This behavior is particularly required in transport networks where data traffic continues to flow even after control plane failures and the control plane must be resynchronized on recovery.

Packet vendors are increasingly interested in "non-stop forwarding" and are also considering MPLS-TE networks as transport networks. Thus, these
features are finding themselves on the roadmaps of packet vendors.

IANA Last Call Comment:

First assignment:

Upon approval of this document, the IANA will make the following assignments
in the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
table named "Class Names, Class Numbers, and Class Types"

TDB1/132 Capability Object [RFC-ccamp-rsvp-restart-ext]
c-type
1 Capability Object

Second Assignment:
Upon approval of this document, the IANA will make the following assignments
in the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
table named "Message Types"
TBD2/30 RecoveryPath [RFC-ccamp-rsvp-restart-ext]

Third Assignement:
Upon approval of this document, the IANA will make the following assignments
in the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
create a new table named "Capability Object values"
with allocation policy of IETF standards action.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RecoveryPath Transmit Enabled (T): 1 bit [RFC-ccamp-rsvp-restart-ext]

RecoveryPath Desired (R): 1 bit [RFC-ccamp-rsvp-restart-ext]

RecoveryPath Srefresh Capable (S): 1 bit [RFC-ccamp-rsvp-restart-ext]

We understand the above to be the only IANA Actions for this document.