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

From: "Diego Caviglia" <[email-masked]>
Date: Thu, 24 Mar 2005 09:03:52 +0100

Hi Adrian,
           thanks for taking part to this discussion.

Please find my comments in line.

Regards

Diego

"Adrian Farrel" <[email-masked]> on 23/03/2005 15.58.42

Please respond to "Adrian Farrel" <[email-masked]>

To:    "Diego Caviglia" <[email-masked]>, <[email-masked]>
cc:    <[email-masked]>

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

Hi,

My initial reaction is that this is way out of scope for CCAMP for a bunch
of reasons. In particular order:

- 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?

- Control plane and data plane protection actions need to be carefully
  separated.
[dc] Agreed.

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

- Existing alarm procedures should not be impacted by the use of GMPLS.
[dc] Absolutely agreed

- Data plane technology is not what we do.
[dc] Absolutely agreed

But I'm open to discussion.

Finally, to follow on Sasha's comments, such a draft would probably be
informational.
[dc] Ok for me no problem on that.

Cheers,
Adrian

----- Original Message -----
From: "Diego Caviglia" <[email-masked]>
To: "Sasha Vainshtein <Sasha" <[email-masked]>
Cc: "ccamp <ccamp" <[email-masked]>
Sent: Wednesday, March 23, 2005 2:01 PM
Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio
n

>
> May be Adrian can put come light on the question you raised.
>
> Regards
>
> Diego
>
>
>
> Sasha Vainshtein <[email-masked]> on 23/03/2005 14.44.23
>
> To:    "'Diego Caviglia'" <[email-masked]>
> cc:    ccamp <[email-masked]>
>
> Subject:    RE: Failure definition w.r.t. SONET/SDH and
>        Protection/Restoratio        n
>
>
> Diego,
> I do not see any technical problems with placing such
> a definition in an Internet-Draft.
>
> But there may be problems associated with the IETF process:
>
> 1. Do you want to pursue this activity in the CCAMP WG?
>    I am not sure this is really in the scope as defined
>    by the CCAMP Charter
>
> 2. For interoperability the IETF document should be
>    a Standards Track RFC. On the other hand, CCAMP is in
>    the Routing Area meaning that you need an implementation
>    to publish a Standards Track RFC - but what could be
>    considered as an implementation in this case?
>
> Regards,
>                                   Sasha Vainshtein
> email:                         [email-masked]
<mailto:[email-masked]>
> phone:                       +972-3-7569993 (office)
> fax:                            +972-3-6487779
> mobile:                      +972-52-8674833
>
>
> > -----Original Message-----
> > From: Diego Caviglia [mailto:[email-masked]]
> > Sent: Wednesday, March 23, 2005 3:37 PM
> > To: Sasha Vainshtein
> > Cc: ccamp
> > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > Protection/Restoratio n
> >
> >
> >
> > Hi Sasha,
> >                        I agree with you but in any case for
> > interop issues
> > and for sake of clarity I'd like to have that written in some IETF
> > document.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> >
> >
> > Sasha Vainshtein <[email-masked]> on 23/03/2005 12.23.12
> >
> > To:    "'Diego Caviglia'" <[email-masked]>
> > cc:    [email-masked]
> >
> > Subject:    RE: Failure definition w.r.t. SONET/SDH and
> >        Protection/Restoratio  n
> >
> >
> > Diego and all,
> > IMHO it is reasonable to assume that a failure is
> > a defect that results in sending downstream AIS
> > (and upstream RDI) as consequent action(s).
> >
> > For SDH consecutive actions for each defect
> > are specified in ITU-T G.783.
> >
> > Note also that for some defects the consecutive action
> > can be disabled by configuration. Hence I'd say that
> > the same defect can be a failure in one case and
> > not a failure in another case. The typical example
> > is Trail Identifier Mismatch (TIM).
> >
> > Hopefully this note will help.
> >
> > Regards,
> >                                   Sasha Vainshtein
> > email:                         [email-masked]
> > <mailto:[email-masked]>
> > phone:                       +972-3-7569993 (office)
> > fax:                            +972-3-6487779
> > mobile:                      +972-52-8674833
> >
> >
> > > -----Original Message-----
> > > From: Diego Caviglia [mailto:[email-masked]]
> > > Sent: Wednesday, March 23, 2005 1:06 PM
> > > To: [email-masked]
> > > Subject: Failure definition w.r.t. SONET/SDH and
> > > Protection/Restoration
> > >
> > >
> > > Hi all,
> > >               is it defined somewhere, with respect to
> > > SDH/SONET, which
> > > defect has to be consider as a failure?
> > >
> > > It seems to me that for interoperability could be useful to
> > > have a list of
> > > defect that must be considered as failure, the same applies
> > > for defect that
> > > optionally can be considered as defect.
> > >
> > > May be also a communication between restoration TNEs in order
> > > to agree on
> > > the list could be useful.
> > >
> > > Does anyone agree on that?
> > >
> > > Regards
> > >
> > > Diego
> > >
> > > PS I apologise if the list is defined somewhere but I wasn't
> > > able to find
> > > it.
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 24 Mar 2005 11:53:32 -0000

Hi Diego,

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

> 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