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

["Daniele Ceccarelli" <[e-mail]>]

Hi Alan,
 
yes, i think the discussion must be kept public on the mailing list but i simply made a mistake pressing Reply, instead of Reply to All.
 
Just few further comments to conclude our discussion:
 
- Bullets 2) and 3): I think you're right. I hope it is still possible to modify the ID. If so i'll introduce the piece of text you suggest.
 
"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." 
 
- Bullet 4): Last time i said you were right, an indeed you wuold be if the sentence you're referring to was not inside section 4.1:



4.1.  MP to CP handover: LSP Ownership Transfer From Management Plane To


      Control Plane
 
so it is correct that it only refers to MP to CP handover and not to CP to MP :-)
 
Thank you once again for you comments
 
BR
Daniele

________________________________

From: Alan Elder [mailto:[e-mail]] 
Sent: venerdì 22 gennaio 2010 18.00
To: Daniele Ceccarelli
Subject: RE: [CCAMP] Comments on draft draft-ietf-ccamp-pc-spc-rsvpte-ext-06


Hi Daniele,
 
Thanks for your comments  - see answers to your specific questions in-line [ADE].  I would summarise my comments as:
 
CP to MP handover has some bugs with regard to handover failure.  The principle for how this should work as described in the draft (failure results in state returning to how it was before the handover) is good - the bugs just need ironing out.
 
>From your comments below it looks like you agree with this.
 
 
I'm new to CCAMP, so am not quite up with procedures yet - should we be having this discussion on the mailing list?
 
Cheers,
 
Alan
 

________________________________

From: Daniele Ceccarelli [mailto:[e-mail]] 
Sent: 21 January 2010 16:43
To: Alan Elder
Subject: RE: [CCAMP] Comments on draft draft-ietf-ccamp-pc-spc-rsvpte-ext-06


Hi Alan,
 
please find my answers inline [DC].
 
Best regards
Daniele

________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of Alan Elder
Sent: martedì 19 gennaio 2010 13.32
To: [e-mail]
Subject: [CCAMP] Comments on draft draft-ietf-ccamp-pc-spc-rsvpte-ext-06



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.  

[DC] The utilization of the full ERO is considered as an optional from the WG consensus. This is why both procedures are required.

 

 

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

[DC] Could you please provide an example? In which case a transit LSR sends a PathTear after the Handover procedure is in progress? (i.e. Path message with R, H and D flags already processed) 

[ADE] See the attached diagram.  This failure mode is similar to that described in section 4.2.2.1 of the draft for MP to CP handover. The cause of the failure could be, for example, an upstream interface failure.    

 

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

[DC] you're probably right, i was wondering if this changes legacy RSVP behavior. Does it?    

[ADE] I'm only proposing changing PathTear/PathErr processing when the H bit is set - so this does not affect legacy RSVP behaviour.  How RSVP behaves for transit nodes sending PathTears is described in http://tools.ietf.org/html/rfc3473#section-4.4.

 

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

[DC] you're right. 

 

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.  

[DC] All the nodes of the LSP must support the handover procedure because in case of CP to MP the node not supporting the handover procedure would delete the 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).