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

"t.petch" <ietfc@btconnect.com> Wed, 08 December 2010 18:03 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EAA23A696E for <mpls-tp@core3.amsl.com>; Wed, 8 Dec 2010 10:03:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.067
X-Spam-Level:
X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-1.080, BAYES_00=-2.599, FAKE_REPLY_C=2.012, J_CHICKENPOX_63=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDz1y-mgekkf for <mpls-tp@core3.amsl.com>; Wed, 8 Dec 2010 10:03:02 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id 000913A6961 for <mpls-tp@ietf.org>; Wed, 8 Dec 2010 10:03:01 -0800 (PST)
Received: from host81-156-71-67.range81-156.btcentralplus.com (HELO pc6) ([81.156.71.67]) by c2bthomr14.btconnect.com with SMTP id AYJ73583; Wed, 08 Dec 2010 18:04:26 +0000 (GMT)
Message-ID: <005801cb96f9$a1b66760$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" <nurit.sprecher@nsn.com>, <mpls-tp@ietf.org>
Date: Wed, 8 Dec 2010 18:01:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4CFFC89D.01AB, actions=tag
X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4CFFC8AB.00B9, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: "Zhao, Peng \(NSN - CN/Shanghai\)" <peng.zhao@nsn.com>
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Dec 2010 18:03:03 -0000

 At the risk of throwing another spanner in the works, I think that the subject
 line on this e-mail suggests a misunderstanding.  Alarm reporting is the
 reporting of alarms, and is well described in the draft G.8151 recently liaised
 to us for comment.  It includes, for example, reporting of protection switch
 events, something which I would expect to be uncontroversial.

 AIS is quite different; it does appear in that draft, along with hundreds of
 others, as a condition that an adaptation point might report on, but, as has
 been pointed out on this list several times, reflects PDH/SDH technology and it
 is a bit of a stretch to see how it can be mapped in any meaningful way to a
 packet network.

 Tom Petch

> ----- Original Message -----
> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher at nsn.com>
> To: <mpls-tp at ietf.org>
> Cc: "Zhao, Peng (NSN - CN/Shanghai)" <peng.zhao at nsn.com>
> Sent: Wednesday, December 08, 2010 3:05 AM
>
>
> >
> >       Hi,
> >       I have a question about the functionality of Alarm Reporting..
> >       Assuming that there is a failure at a server layer somewhere across
the
> >       network..and the MEP of the server layer identifies it and needs to
> ensure
> >       that Alarm Reporting is sent to all of the MEPs of the client services
> >       that transmit over the failed server.but it may be that some of the
> client
> >       services do not have MEPs..how does the node detecting the server
> failure
> >       knows which client services have MEPs and an Alarm Reporting message
> needs
> >       to be sent to their MEPs and which do not have MEPs and an Alarm
> Reporting
> >       message must not be sent for these client services..(as we would not
> like
> >       to flood the network with unnecessary traffic)..
> >       I hope someone can clarify it to me.
> >       Best regards,
> >       Nurit
> >
> >
>