IETF Logo Mail Archive

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

John E Drake <jdrake@juniper.net> Mon, 13 December 2010 16:31 UTC

Return-Path: <jdrake@juniper.net>
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 F2BBF3A6CB5 for <mpls-tp@core3.amsl.com>; Mon, 13 Dec 2010 08:31:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.776
X-Spam-Level:
X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=-4.225, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 T2T6PjKpEXV2 for <mpls-tp@core3.amsl.com>; Mon, 13 Dec 2010 08:31:02 -0800 (PST)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 0E20C3A6DDC for <mpls-tp@ietf.org>; Mon, 13 Dec 2010 08:31:00 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTQZKmi8bmkIvzcsWUpGzBsH6snKvQZcU@postini.com; Mon, 13 Dec 2010 08:32:38 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 13 Dec 2010 08:32:02 -0800
From: John E Drake <jdrake@juniper.net>
To: "neil.2.harrison@bt.com" <neil.2.harrison@bt.com>, "huubatwork@gmail.com" <huubatwork@gmail.com>, "wei.hongbo@zte.com.cn" <wei.hongbo@zte.com.cn>
Date: Mon, 13 Dec 2010 08:33:34 -0800
Thread-Topic: =?gb2312?B?W21wbHMtdHBdILTwuLQ6IFJlOiAgQWxhcm0gUmVwb3J0aW5nIChha2EgQQ==?= =?gb2312?B?SVMp?=
Thread-Index: Acuar4KT/wLlAk8gTAGZiiDxRcsxFgAHuXxQAAUvLHA=
Message-ID: <5E893DB832F57341992548CDBB33316398C5B7D7C8@EMBX01-HQ.jnpr.net>
References: <OFA4FEC52B.FF865E94-ON482577F5.00019D35-482577F5.00026E0F@zte.com.cn> <4D05F39D.60901@gmail.com> <6D3D47CB84BDE349BC23BF1C94E316E4400E13F459@EMV62-UKRD.domain1.systemhost.net>
In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E4400E13F459@EMV62-UKRD.domain1.systemhost.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "mpls-tp@ietf.org" <mpls-tp@ietf.org>
Subject: Re: [mpls-tp] =?gb2312?b?tPC4tDogUmU6ICBBbGFybSBSZXBvcnRpbmcgKGFrYSBB?= =?gb2312?b?SVMp?=
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: Mon, 13 Dec 2010 16:31:03 -0000

Huub,

A bis update to the RFC, indicating that upon further refection the requirement was ill-considered, can always be issued.

Thanks,

John 

Sent from my iPhone


> -----Original Message-----
> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
> Behalf Of neil.2.harrison@bt.com
> Sent: Monday, December 13, 2010 6:29 AM
> To: huubatwork@gmail.com; wei.hongbo@zte.com.cn
> Cc: mpls-tp@ietf.org
> Subject: Re: [mpls-tp] 答复: Re: Alarm Reporting (aka AIS)
> 
> Huub wrote 13 December 2010 10:21
> 
> > Hello Steven,
> >
> > You wrote:
> >
> > > I think we need to listen to the views of Neil on AIS.
> > >
> > > This is just a purely technical discussion, isn't it?
> >
> > Yes it is, I am *not* trying to shoot the messenger.
> >
> > My concern is that we have a requirement in RFC5860.
> > A solution (for AIS) is provided in draft-ietf-mpls-tp-fault.
> >
> > How will the current discussion affect the progress of this draft?
> 
> NH=> I guess a key issue here is trying to figure out which, if any,
> operators still want AIS.  Perhaps those operators did not previously
> understand that:
> -	is it a redundant technical function (for reasons I have
> explained previously), and
> -	it is a potential source of further problems in itself, as OAM
> messages have to be constructed/configured (the always-on defect
> detection needs to be as simple/sparse as possible since it must be
> significantly more reliable than the network it is monitoring, and thus
> all unnecessary sources of defects/configuration-errors should be
> minimised).
> 
> Perhaps those operators who may have originally supported the
> requirement for AIS in packet-switched networks did not properly
> understood these issues before?
> 
> In any case, it is important that for those operators who have properly
> understood what AIS is to be able to have this function disabled in
> their networks.
> 
> regards, Neil
> 
> >
> > Regards, Huub.
> >
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp

v2.8.7 | Report a Bug | By Email