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

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 23 Mar 2005 13:23:12 +0200

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: "Diego Caviglia" <[email-masked]>
Date: Wed, 23 Mar 2005 14:36:59 +0100

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,

Regards,
                                  Sasha Vainshtein

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 23 Mar 2005 16:41:47 +0100

Stephen,
                    for me is ok to have a reference to the ITU-T doc in a
IETF doc.

The point is that seems there is no reference to that in any IETF ID/RFC.

So if your proposal is to add a reference to ITU-T in some already existing
IETF draft that is ok for me.

Regards

Diego

Stephen J Trowbridge <[email-masked]> on 23/03/2005 16.26.47

To:    Sasha Vainshtein <[email-masked]>
cc:    "'Diego Caviglia'" <[email-masked]>, ccamp
       <[email-masked]>

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

Sasha and Diego,
IMHO, it is a very bad idea to have two "normative" places where something
is
standardized.
You already have the SDH standards in ITU-T documents (G.707, G.783, etc.)
and
the SONET standards in ATIS OPTXS (formerly T1X1) documents (mostly the
T1.105
series). There is no reason that standards track RFCs cannot make normative
references to these documents where needed. It would be inappropriate for
IETF
to attempt to replicate these documents as RFCs.
Regards,
Steve

On 3/23/2005 6:44 AM, Sasha Vainshtein wrote:
> 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
>>Sent: Wednesday, March 23, 2005 3:37 PM
>>To: Sasha Vainshtein
>>Cc: ccamp

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Wed, 23 Mar 2005 10:10:25 -0600

Not sure the context of your question Diego? ITU provides the
definitions allowing interop. And CCAMP does have documents referencing
- CCAMP's recovery documents (terminology, analysis, functional,
signaling). CCAMP's documents were based on the approach as Steve
described - terminology alignment with ITU/T1X1 (e.g. defect, failure,
SF, SD) and references to the T1X1/ITU documents (T1.105, G.806, G.783,
G.841/842, G.808.1). These ITU documents also include differences
between SONET and SDH. If you have questions on specific
defects/failures (eg TIM), suggest sending mail on the ITU's SG15 q9
exploder.

Deborah 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen J Trowbridge
Sent: Wednesday, March 23, 2005 10:27 AM
To: Sasha Vainshtein
Cc: 'Diego Caviglia'; ccamp
Subject: Re: Failure definition w.r.t. SONET/SDH and
Protection/Restoratio n

Sasha and Diego,
IMHO, it is a very bad idea to have two "normative" places where
something is
standardized.
You already have the SDH standards in ITU-T documents (G.707, G.783,
etc.) and
the SONET standards in ATIS OPTXS (formerly T1X1) documents (mostly the
T1.105
series). There is no reason that standards track RFCs cannot make
normative
references to these documents where needed. It would be inappropriate
for IETF
to attempt to replicate these documents as RFCs.
Regards,
Steve