Subject: RE: [Fwd: draft-ietf-pwe3-control-protocol-02.txt]

From: [email-masked]
Date: Thu, 20 Mar 2003 22:31:20 -0000

David Allan wrote 20 March 2003 21:55

I'll reiterate a general observation made at the PWE3 meeting mike. 
The draft currently uses label withdraw as a fault notification mechanism.
It would be useful if the text stated that this was a MUST only in the
absence of other fault notification mechanisms. 
Data plane notification would be particularly useful for physical circuits,
PVCs etc. things that do not go away on failure. IMHO withdrawing a label
may introduce a lot of overhead for somthing that may need to be promptly
put back (circuit flapping). Data plane notification that simply leaves the
label in place could be a whole lot simpler. esp. if associated stats need
to be journalled when labels are withdrawn.
cheers 
Dave 

NH=> I agree with this view.  It's generally not good architectural practice
to couple data-plane fault notifications and (a specific instance of) the
control-plane behaviour.  There are many reasons for this (some people have
already discovered some of these I believe wrt RSVP-TE LSPs, ie don't use
the control-plane to proxy for detecting data-plane failures).  Dave has
pointed out a further reason above.  Others related issues here are:
-	you want the *same* data-plane mechanisms/behaviour irrespective of
which signalling protocol intantiated the LSP......including the case of
'none', ie static provisioned;
-	the above is also a requirement in order to allow independent
development (ie add-new/change/sunset-old) the data-plane and control-plane
protocols;
-	failures of the control-plane should not impact long-holding
data-plane topological constructs.......VPNs are an example of a potentially
long holding data-plane constructs here;
-	some failure modes will only be detectable using data-plane
mechanisms, eg mismatch/mismerge....so since detection is required within
the data-plane itself, it makes sense that appropriate actions (which may
vary dependent on the specific defect) are taken within the data-plane.  One
can use the data-plane detection to then invoke actions in the control-plane
(and assuming signalling is used, and this should apply to *any* signalling
protocol, not just 1 instance) such as protection-switching, and where as
Dave observes "(the LSP) needs to be promptly put back"......but clearly it
still depends on data-plane detection in the 1st place, and data-plane
verification that any corrective actions like prot-sw have been successful.

regards, Neil