Re: [mpls-tp] Alarm Reporting (aka AIS)

[<[e-mail]>]

Hi Huub,

The trite answer is that whoever wrote, and keeps promulgating, this myth does not properly understand the networking situation....I suspect it is folks purely from the PDH/SDH world and/or those who want to promote TCM.  I can dismiss it immediately by the observation that the Internet and the PSTN (which are fairly major and important networks!) don't rely on this.  If you think about my observations that you snipped here then the logic is irrefutable, ie the client has moved (and the server must not even be party to knowing this)!

Each layer network must be able to look after itself.

Even if we have the restricted case where AIS might have some value (ie co-cs and permanent client/server bindings) we can still observe that CV/BDI alone are all one needs to identify the offending source layer of a problem and deal with most real-world cases of defect detection/handling....with the tapping off of E2E CV/PM flows on the *rare* occasions we might need this for rogue paths....we for sure do not need TCM.  I can take you through the logic if you need me too, but I would hope most folks can figure all this out.

regards, Neil  

> -----Original Message-----
> From: Huub van Helvoort [mailto:[e-mail]] 
> Sent: 09 December 2010 10:51
> To: Harrison,N,Neil,DKQ7 R
> Cc: [e-mail]
> Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)
> 
> Hello Neil,
> 
> You wrote:
> 
> > The key points are:
> > - AIS is technically not necessary for any pkt-based
>  > technologies at all.....
> 
> Then how should we resolve this requirement:
> == "A defect event in a given layer network should not
>      cause multiple alarm events to be raised, nor cause
>      unnecessary corrective actions to be taken in any
>      higher level client-layer networks." ==
> 
> Regards, Huub.
> 
> 
> --
> *****************************************************************
>                           我爱外点一七三一
>