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

[<neil.2.harrison@bt.com>]

You are quite correct Amit.  What you need is proper client/server
functional decoupling between the layer networks involved.  The ideas of
a 'common' control-plane (esp routing) from IP to Optics is rather a
nonsence in our view.....not just technically either, you need this to
provide the key 'network builder service' capability in commercial
relationships between operators.

Historically things have worked OK in practice because there has been a
common-sense approach about how the 3 networking modes of co-cs, co-ps
and cl-ps have been nested (there are 9 possible client/server
relationships here are there are no formal rules governing how many
up/down transitions are allowed in some end-end reference
architecture...and remember, a client layer network will inherit the
performance of its server layer network, and this is recursive to the
duct).  PWE3 stuff is turning this on its head wrt XoverY relationships
(not that these even ensure the key requirement of client/server
independence/transparency anyway)....hopefully most operator folks
should have the common sense to see the problems and avoid the pitfalls.

In the 2 co modes the defect handling MUST be done in the data-plane and
it MUST be unidirectional.  There is an OAM requirement to send a signal
called FDI (Forward Defect Indication...sometimes know as AIS in co-cs
technologies) which is intended to suppress alarm storms (which would
otherwise occur in all higher client co mode networks).  Has to be like
this, esp in the co-cs mode as the control/management-plane is forced to
run OOB and it must work the *same* for all methods of trail
set-up....be this by signalling protocols X, Y or Z of via management
provisioning.

regards, neil

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Amit 70405
> Sent: 25 March 2005 08:23
> To: Diego Caviglia
> Cc: Adrian Farrel <adrian; Igor Bryskin <i_bryskin; ccamp; Sasha
> Subject: Re: Failure definition w.r.t. SONET/SDH and 
> Protection/Restoration
> 
> 
> Hi Diego,
>    Its not only the case with MSP protection.
>    For that matter any Multilayer protection will have the 
> interworking issues.
>    According to me lower layer restoration should be 
> mandatorily independant of higher layer restoration.
>    And let the Network operator be aware of the 
> consequences(mainly some unutilised resources).
>    
>    This is the point which I feel that CCAMP should clarify.
> 
> Regards,
> Amit.
> 
> 
> 
> ----- Original Message -----
> From: Diego Caviglia <Diego.Caviglia@marconi.com>
> Date: Friday, March 25, 2005 3:25 pm
> Subject: Re: Failure definition w.r.t. SONET/SDH and 
> Protection/Restoration
> 
> > Hi Amit,
> >               actally for link/span protection I don't see any
> > problem 
> > with control plane restoration and data plane protection 
> interworking.
> > 
> > It is sufficient to hide protection resourse to control plane.
> > 
> > I see a lot of problems (there are SPs opened in the ITU-T
> > documents about 
> > that) when you want an MS-SPRing protected ring to interwork with 
> > GMPLS 
> > restoration.
> > 
> > Actually I'm not sure if that topic is in the charter of the CCAMP
> > (Adrian 
> > what is your feeling about this?) but in any case it is a problem.
> > 
> > Regards
> > 
> > Diego
> > 
> > 
> > To:     Adrian Farrel <adrian@olddog.co.uk>, Igor Bryskin 
> > <i_bryskin@yahoo.com>cc:     Diego Caviglia 
> > <Diego.Caviglia@marconi.com>, ccamp@ops.ietf.org,
> > Sasha@AXERRA.com 
> > 
> > Subject:        Re: Failure definition w.r.t. SONET/SDH and 
> > Protection/Restoration
> > 
> > Hi Adrian & Igor,
> >   But there is one issue with this multilayer protection.
> >   Say in the case if the link gets broken, and the lower layer
> > protection 
> > has succeeded.
> >   In this case, should the control plane(higher layer) be 
> > notified by the 
> > lower layer of link??
> > 
> >   If yes than it has following consequences:
> >   - As control plane is unaware of any failure, control plane
> > will 
> > continue to setup new connections on the failed.
> >   - This may not be a good thing to do.
> >   - Some means may be needed to avoid this link in Path computation.
> > 
> >   If no than following are the consequences:
> >   - Control plane too will go ahead with its protection mechanism.
> > 
> >   Let me know your view.
> > Regards,
> > Amit.
> > 
> > 
> > ----- Original Message -----
> > From: Adrian Farrel <adrian@olddog.co.uk>
> > Date: Thursday, March 24, 2005 7:40 pm
> > Subject: Re: Failure definition w.r.t. SONET/SDH and
> > Protection/Restoration
> > 
> > > Hi Amit,
> > >
> > > >    Do you mean to say that Data plane & Control plane protection
> > > shouldbe independant of each other??
> > >
> > > No, I mean that they MAY be independent.
> > > In particular, if you are using the control plane *and* the data 
> > > plane to manage protection on the same set of resources you are 
> > > bound to get in a
> > > horrible mess.
> > >
> > > Seems more reasonable that you would apply data plane protection 
> > > first and then apply control plane protection at a higher level.
> > >
> > > >    If so, in case of MSP protection in SDH,
> > > >     Control plane should not have any control over the
> > resource pool
> > > >      used for MSP switch.
> > > >    This may lead to lot of unused resource in the network.
> > >
> > > It is certain that each layer of protection that you install MAY 
> > > result in unused resources. Building multiple layers of 
> protection 
> > > will, therefore,potentially build up more and more unused 
> resources. 
> > > It is the job of
> > > CCAMP to produce the tools that allow operators to build the
> > > protectionschemes that they want. It's not really our business to
> > > tell them which
> > > schemes to build and when.
> > >
> > > Cheers,
> > > Adrian
> > >
> > >
> > 
> > 
> > 
> > 
> 
> 
>