Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements)

From: George Swallow <[email-masked]>
Date: Fri, 01 May 2009 16:55:01 -0400

> On 4/30/09 9:15 AM, "George Newsome" <[email-masked]> wrote:
> 
>> Lam, Hing-Kam (Kam) wrote:
>>> > All I can say is that the impact of this proposed change is very
>>> > serious.
>>> > Doesn't MPLS-TP suppose to meet the ITU-T transport requirements instead
>>> > of changing the ITU-T transport requirements?
>>> >
>>> >
>> Hi Kam,
>> 
>> AIS, which we are so very comfortable with, is a solution to a rather
>> poorly stated requirement. The requirement is to distinguish between
>> local faults (things that can be fixed here) and remote faults (things
>> that have to be fixed elsewhere).

<Snipped>

George -

Being new to the transport world, I have a question. Is the function of AIS
solely to do with Local vs Remote or does it also have to do with layering?

Consider the following scenario:

Topology is A-B-C

LSP1 goes A-B-C

Now if the xconnect at node B for LSP1 is corrupted by an operator error or
some bug, how is this handled?  Node B will see nothing wrong.  CC will fail
on LSP1 but the failure will be remote to both endpoints (A and C).  So is
no alarm supposed to be raised?  Just report the LSP Down?

Of course if you used AIS to suppress alarms, you would alarm since B would
have no reason to send AIS.

...George

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 3 May 2009 11:20:39 +0300

George and all,
I must admit I am equally (or so I think:-) confused regarding the problem AIS is going to solve...

 1.  One approach suggests that it helps to distinguish between local vs. remote faults.
    *   As George's message has shown, the very notion of local vs. remote fault is somewhat vague
    *   George's example (a faulty XC) is applicable also to SONET/SDH, and, to the best of my understanding, AIS would not help in this scenario either
 2.  Another approach suggests that it helps to suppress unnecessary client alarms and even to disable/postpone clients' protection actions in the presence of a server failure discovered using AIS
    *   This approach seems to require that an MPLS-TP server is explicitly aware of all its clients. I have already expressed my concern about compatibility of this approach with the (abstract) MPLS data plane as described in RFC 3031
    *   Usefulness of AIS to prevent the clients' protection action seems highly problematic in any case:
       *   In order to deliver reasonable service disruption times (50 ms is mentioned in the MPLS-TP requirements draft), these actions have to be triggered by "fast" fault detection (say, 10s of milliseconds)
       *   It is not clear, how fast packet-based AIS can be detected. If we take ATM F4/F5 AIS as the example, it is sent once/second... so there is a pretty chance it will take something like that to detect AIS - by far too late to prevent any protection action.

IMHO and FWIW, AIS has been born a clever hack killing several birds with one stone in TDM-based co-cs networks. But its consequent "promotion" to a fundamental architectural concept of transport networks does not look justified.

My 2c,
     Sasha Vainshtein

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of George Swallow
Sent: Friday, May 01, 2009 11:55 PM
To: George Newsome; Lam, Hing-Kam (Kam)
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements)

Hi Kam,

<Snipped>

George -

Being new to the transport world, I have a question. Is the function of AIS solely to do with Local vs Remote or does it also have to do with layering?

Topology is A-B-C

LSP1 goes A-B-C

Now if the xconnect at node B for LSP1 is corrupted by an operator error or some bug, how is this handled?  Node B will see nothing wrong.  CC will fail on LSP1 but the failure will be remote to both endpoints (A and C).  So is no alarm supposed to be raised?  Just report the LSP Down?

Of course if you used AIS to suppress alarms, you would alarm since B would have no reason to send AIS.

...George