IETF Logo Mail Archive

[mpls-tp] Alarm Reporting (aka AIS)

"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com> Wed, 08 December 2010 02:04 UTC

Return-Path: <nurit.sprecher@nsn.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 452A13A6848 for <mpls-tp@core3.amsl.com>; Tue, 7 Dec 2010 18:04:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Level:
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 Ed2haKLul0Ou for <mpls-tp@core3.amsl.com>; Tue, 7 Dec 2010 18:04:55 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id BA4E53A681A for <mpls-tp@ietf.org>; Tue, 7 Dec 2010 18:04:54 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oB826Jwg019803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mpls-tp@ietf.org>; Wed, 8 Dec 2010 03:06:19 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oB826I8L023000 for <mpls-tp@ietf.org>; Wed, 8 Dec 2010 03:06:19 +0100
Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Dec 2010 03:05:44 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB967C.6C175A6E"
Date: Wed, 8 Dec 2010 03:05:43 +0100
Message-ID: <077E41CFFD002C4CAB7DFA4386A532640308F66E@DEMUEXC014.nsn-intra.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Alarm Reporting (aka AIS)
Thread-Index: AcuWfGt80MeNI9HgT3GIq0sKBOnFIg==
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>
To: <mpls-tp@ietf.org>
X-OriginalArrivalTime: 08 Dec 2010 02:05:44.0814 (UTC) FILETIME=[6C5A00E0:01CB967C]
Cc: "Zhao, Peng \(NSN - CN/Shanghai\)" <peng.zhao@nsn.com>
Subject: [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 02:04:58 -0000

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

v2.8.7 | Report a Bug | By Email