Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 23 Mar 2005 15:01:48 +0100

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: Wed, 23 Mar 2005 14:58:42 -0000

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.
- Control plane and data plane protection actions need to be carefully
  separated.
- Decisions that trigger control plane protection actions are
fundamentally
  implementation choices. 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.
- Existing alarm procedures should not be impacted by the use of GMPLS.
- Data plane technology is not what we do.

But I'm open to discussion.

Finally, to follow on Sasha's comments, such a draft would probably be
informational.

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