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

["Diego Caviglia" <Diego.Caviglia@marconi.com>]

May be Adrian can put come light on the question you raised.

Regards

Diego



Sasha Vainshtein <Sasha@AXERRA.com> on 23/03/2005 14.44.23

To:    "'Diego Caviglia'" <Diego.Caviglia@marconi.com>
cc:    ccamp <ccamp@ops.ietf.org>

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:                         sasha@axerra.com <mailto:sasha@axerra.com>
phone:                       +972-3-7569993 (office)
fax:                            +972-3-6487779
mobile:                      +972-52-8674833


> -----Original Message-----
> From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> 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 <Sasha@AXERRA.com> on 23/03/2005 12.23.12
>
> To:    "'Diego Caviglia'" <Diego.Caviglia@marconi.com>
> cc:    ccamp@ops.ietf.org
>
> 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:                         sasha@axerra.com
> <mailto:sasha@axerra.com>
> phone:                       +972-3-7569993 (office)
> fax:                            +972-3-6487779
> mobile:                      +972-52-8674833
>
>
> > -----Original Message-----
> > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> > Sent: Wednesday, March 23, 2005 1:06 PM
> > To: ccamp@ops.ietf.org
> > 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.
> >
> >
> >
> >
>
>
>
>
>
>