Re: [Mpls-interop] Local and Remote

[Huub van Helvoort <[e-mail]>]

Hi Kam,

You wrote;

> */Malcolm,/*
>
> */I agree in general with your approach./*

This is indeed a good approach.
Note that the draft rosetta stone already contains the
definitions for (primary) defect, fault and failure.
These are in line with the definitions in G.806.

So only consequential defect needs to be defined.

Regards, Huub.


> */Please see inline below./*
> 
> */Regards,/*
> 
> */Kam/*
>  
> 
>>  -----Original Message-----
>>  From: [e-mail] [mailto:[e-mail]]
>>  On Behalf Of Malcolm Betts
>>  Sent: Thursday, May 07, 2009 11:39 AM
>>  To: Adrian Farrel; Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls-
>>  [e-mail]
>>  Subject: Re: [Mpls-interop] Local and Remote
>>
>>  All, first apologies for my behaviour on the MEAD team call on Tuesday,
>>  showing frustration is not an acceptable way of holding a technical
>>  discussion.
>>
>>  Looking at the chain of email I see signs of convergence but no easy way
>>  to simple text.  I saw a comment from Sasha on the network management
>>  requirements draft:
>>
>>  "Section 5.5.2 deals with alarm suppression and defined a MUST
>>  requirement to suppress "superfluous alarms". However, the notion of the
>>  superfluous alarm" is not defined (neither directly in the draft nor by
>>  reference to other sources). Taking into account that there are more
>>  than 50 messages discussing AIS/FDI on this list, it seems that the
>>  superfluosity of an alarm is in the eye of the beholder..."
>>
>>  That triggered a thought that perhaps we have better way to describe the
>>  problem:
>>
>>  Since we have very different backgrounds first some basic definitions:
>>
>>  Fault:  An unintended event that impacts a network.  Examples: hardware
>>  failure; software bug; configuration error.
>>
>>  Defect:  The observed perturbation of a signal. e.g. Loss of CC
>>  messages:  Loss of light (following a cable cut fault).
>
> */[Lam, Hing-Kam (Kam)] G.806 already has the definitions for Fault and 
> Defect. We should reuse (base on) them as much as possible. The key 
> point here is the differentiation of primary and consequential./* 
> 
>>  Primary defect:  The first defect that is observed as the result of a
>>  fault.
>>
>>  Consequential defect:  Any other defect that is caused by the same
>>  fault.
>>
>>  As an example consider a node that has a 40G OTN interface carrying
>>  4xODU2, one ODU2 carrying GFP mapped MPLS-TP LSPs,  some MPLS-TP LSPs
>>  transit a switch/crossconnect function and leave the node; Others
>>  terminate locally on a PW end point.
>>
>>  If the fiber carrying the 40G signal is cut adjacent to the node:
>>
>>  The primary defect would be Loss of optical signal.
>>  Loss of OTU frame, loss of ODU, loss of CC messages on the terminated
>>  LSP, loss of CC messages on the terminated PW are all be consequential
>>  defects observed in this "local" node.
>>
>>  At some (remote) node the LSP's and the PW's that transited the node
>>  adjacent to the fiber cut will be terminated.  Assuming no
>>  recovery/repair action has taken place, then a loss of CC defect will be
>>  observed for both the LSP and PW at this (remote) node.  These are
>>  consequential defects.
>>
>>  So perhaps we could (in the OAM requirements document) include a
>>  requirement that states:
>>
>>  It MUST be possible to differentiate between primary and consequentia
>>  defects.  The OAM toolkit MUST support mechanisms to support this
>>  differentiation.
>
> */[Lam, Hing-Kam (Kam)] Agree./*
> 
>>  Comments:
>>  1) This includes an implicit requirement that defect information is
>>  passed from a server layer to a client layer within a node.
>
> */[Lam, Hing-Kam (Kam)] Agree. The challenge here is, e.g. how the 
> client layer MIP further passes the information to the client MEP./*
> 
>>  2) The (simple) example about is only to illustrate the concepts, many
>>  other scenarios will need to be analyzed to determine if a proposed
>>  solution adequately addresses the requirement.
>>  3) If we take this approach do we need definitions for fault,
>>  primary/consequential defect.
> 
> */[Lam, Hing-Kam (Kam)] Define primary/consequential defects, but based 
> on the G.806 definitions of fault and defect. /*
> 
>>  In the NM requirements we could state:
>>
>>  It MUST be possible to suppress alarms that result from consequential
>>  defects.
> 
> */[Lam, Hing-Kam (Kam)] Agree to have such a requirement in the NM 
> requirement document. However, if the OAM tookit supports mechanisms to 
> support this differentiation and suppression in the DP, that will make 
> the life of the MP much easier. Otherwise the poor MP will need to 
> perform root cause analysis to find out which/where is primary (root 
> cause) and which are consequential./*>
>
>>  Hope this helps.
>>
>>  Malcolm Betts
>>  Nortel Networks
>>  Phone: [phone] (ESN 393)
>>  email: [e-mail]

-- 
================================================================
Always remember that you are unique...just like everyone else...