[CCAMP] Comments on draft draft-ietf-ccamp-pc-spc-rsvpte-ext-06

[Alan Elder <[e-mail]>]

ccamp,

The main MP to CP procedure looks good.  It's not clear whether the secondary MP to CP procedure is a core requirement or an optional extra.

I think CP to MP handover has some bugs, relating to when PathTears are sent.  Detailed comments and suggestions below.

Cheers,
Alan.

1)  Is the alternative MP to CP procedure MUST or MAY?  I suggest "MAY"
Section 4 describes "primary" and "alternative" MP to CP procedures.  I suggest we should mark these respectively as MUST and MAY, as indicated in Section 3.  It's good to have a minimal subset of procedures marked as MUST.

A note in section 5 gives both alternatives equal weight.  This doesn't seem right - we don't want some implementations doing one and some doing the other.  I suggest we remove this:
"The full ERO method and the partial/no ERO one do not exclude each other; both methods are required."

If the alternative method MAY be implemented, we need to clarify the error reported by a transit node that does not support the alternative mechanism.  I suggest using a PathErr with the Handover Failed error code, this could be added to Section 4.1.


2)  Where can PathTear flow during CP to MP handover?  I suggest "nowhere"
Section 4.4 states: "...the ingress node MUST NOT send a PathTear message before a Resv message containing the H bit is received."
This is right - a PathTear would transfer resources to the management plane prematurely.  But why does this apply specially to ingress?  A PathTear originated from a transit node would also cause premature transfer of LSP ownership.  I suggest PathTear should not be sent by any node during handover (see text below).


3)  CP to MP handover procedures do not maintain the LSP on failure
The procedure in section 7.2 is good for MP to CP handover.  But for CP to MP handover, sending a PathTear will not achieve the stated objective of keeping the LSP in place and CP owned.  In order to do that, the PathErr/PathTear procedures need to be modified so that the ingress node receives PathErr and resignals the Path with H clear.

I suggest the following as the definition for PathErr/PathTear procedures, covering points (2) and (3).

"While the H bit is set in Path state, a node MUST NOT send a PathTear when a failure is detected.  Instead, the failure is reported upstream using a PathErr.  The only node that can send a PathTear is the ingress node, and it can only do this as a step in the procedures specified in this document. This applies to both MP to CP and CP to MP handover."


4)  Bug in CP to MP procedures, introduced in -05
This was added to Section 4.1 as part of revision -05
" Each LSR that receives a Path message with the H bit set checks to see whether there is any matching Path state.
- If matching Path state is found with the H bit set, this is a Path refresh and should be treated accordingly [RFC3473].
- If matching Path state is found with the H bit clear, this is an error and MUST be treated according to the error case description in Section 4.2.1.1"

This is fine for MP to CP handover.  But CP to MP procedures expect to find matching Path state with the H bit clear.  How can the second bullet be supported without disabling CP to MP procedures?

I suggest this second bullet is updated to indicate that this case is treated according to CP to MP procedures.  If CP to MP handover is not supported on the node then it is treated with PathErr(Handover Failed).


5)  "All nodes along the path MUST support"? This seems unusual.
Section 8 states that "all nodes along the path MUST support the extension defined in this draft".  Otherwise "This may result in an impact on data traffic during the handover procedure."

This is unusual behaviour for a new signaling procedure.  Usually, lack of support for a signaling feature on some LSRs results in a graceful (signaled) failure when the feature is used.  In this case, it results in undetected loss of an LSP.

It is worth clarifying that not all parts of this draft MUST be supported by all nodes - rather just the mandatory parts must be supported.  For example, if some nodes support the optional CP to MP handover and some do not, then CP to MP failure is signalled gracefully using PathErr signalling (see point 4 above).  Also if some nodes support the alternative MP to CP method, and some do not, then MP to CP failure is signalled gracefully (see point 1 above).