Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Diego,

 

>> - The GMPLS control plane does not necessarily want to define data
>>   plane failures. Rather, it wants to signal (report) errors and allow
>>   the control plane state (and data plane state) to remain in place.
> [dc] Agreed and that was my initial point.  Which kind of data plane (e.g.
> SDG) defects have to advertised to control plane to trigger restoration? 

> Given that control plane is concerned in restore the data plane it should

> also define what is a failure.  It is a fiber break or we have also to

> consider other defects? Of course we have.  What happens if one

> restoration TNE consider as failure only Loss Of Light (LOS) while the

> other starts restoration even if there is a e.g. Loss Of Pointer?  Is

> that acceptable?

 

Let's look at two things.

 

First, the trigger for protection switchover. If you look at section 6.2 of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt (currently in working group last call, so please comment now!) you will see...

 

   To co-ordinate the switchover between end-points, an end-to-end
   switchover request is needed since a failure affecting one the LSPs
   results in both end-points switching to the other LSP (resulting in
   receiving traffic from the other LSP) in their respective
   directions. This is done using the Notify message with a new Error
   Code indicating "Working LSP Failure (Switchover Request)".

This clearly indicates that the objective is not to report a failure, but to request a switchover.

 

Which takes us to your second point: which data plane errors should be reported to the control plane to trigger switchover signaling, and would it matter if different transport nodes applied different policies?

 

My contention is that this is entirely an implementation issue. I think it would be a wise implementation that included some degree of configurability to this function, but that is not in CCAMP's scope. If two "TNEs" have different trigger thresholds I do not see that any harm will be done, it might even be desirable.

 

>> - Decisions that trigger control plane protection actions are
>>   fundamentally implementation choices.
> [dc] Here we are.  This is the point.  IMHO CCAMP should provide some
> guidance on this.
>
>>   Maybe we should make a statement that this type
>>   of thing SHOULD be configurable so that there is some sort of
>>   consistency within a network.
> [dc] Something like "..control plane restoration mechanism SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1).

 

But why?

 

It is not enough to know that this is a difficult question for an implementaiton to answer.

 

Why is it not enough to say that the Data Plane should trigger control plane recovery action when the data plane deems that there is a fault from which it determines that recovery is required and from which it is unable or unwilling to recover on its own?

 

If you can show that there is a need to make a more definitive statement then we can consider it.

Cheers,

Adrian