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

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Wed, 08 December 2010 10:03 UTC

Return-Path: <Alexander.Vainshtein@ecitele.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 974C63A6809 for <mpls-tp@core3.amsl.com>; Wed, 8 Dec 2010 02:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.456
X-Spam-Level:
X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.142, 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 bVKcXmg6HE2N for <mpls-tp@core3.amsl.com>; Wed, 8 Dec 2010 02:03:07 -0800 (PST)
Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id CB5D63A67FD for <mpls-tp@ietf.org>; Wed, 8 Dec 2010 02:03:05 -0800 (PST)
X-AuditID: 93eaf2e7-b7b0bae000000a12-6a-4cff5831ff13
Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 2A.0D.02578.1385FFC4; Wed, 8 Dec 2010 12:04:33 +0200 (IST)
Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 8 Dec 2010 12:05:48 +0200
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Maarten Vissers <maarten.vissers@huawei.com>
Date: Wed, 8 Dec 2010 12:05:47 +0200
Thread-Topic: [mpls-tp] Alarm Reporting (aka AIS)
Thread-Index: AcuWfGt80MeNI9HgT3GIq0sKBOnFIgAK1C+AAAC80JA=
Message-ID: <A3C5DF08D38B6049839A6F553B331C76D6B7A93FA3@ILPTMAIL02.ecitele.com>
References: <077E41CFFD002C4CAB7DFA4386A532640308F66E@DEMUEXC014.nsn-intra.net> <002a01cb96a7$e4552040$acff60c0$%vissers@huawei.com>
In-Reply-To: <002a01cb96a7$e4552040$acff60c0$%vissers@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D6B7A93FA3ILPTMAIL02eci_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: AAAAARbkEiQ=
Cc: "'Zhao, Peng \(NSN - CN/Shanghai\)'" <peng.zhao@nsn.com>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>
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 10:03:12 -0000

Maarten,
Could you please point to specific statements in the already published, or approved for publication MPLS-TP standards that confirm this statement?

Until now, I have been under the impression (possibly, a wrong one) that setting up MEPs at the end point of the transport entities is at the discretion of the operator.  And, at the very least, that nothing prevents the operator from disabling these MEPs.

BTW, this is one more example of the differences between the SONET/SDH-based traffic networks (where the OAM headers are inherently generated and terminated for each transport entity) and packet-based networks where OAM uses dedicated packets which would not be transmitted until somebody explicitly injects them into the traffic path, and can be silently discarded upon reception if you decided to do that.

Regards,
     Sasha

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers
Sent: Wednesday, December 08, 2010 9:17 AM
To: 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; mpls-tp@ietf.org
Cc: 'Zhao, Peng (NSN - CN/Shanghai)'
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)

Nurit,

In MPLS-TP all transport paths are monitored and will have MEPs.

Regards,
Maarten

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: 8 December 2010 03:06
To: mpls-tp@ietf.org
Cc: Zhao, Peng (NSN - CN/Shanghai)
Subject: [mpls-tp] Alarm Reporting (aka AIS)

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