IETF Logo Mail Archive

Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

"Van De Velde, Gunter (Nokia - BE)" <gunter.van_de_velde@nokia.com> Wed, 25 May 2016 10:05 UTC

Return-Path: <gunter.van_de_velde@nokia.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A4B12D60D for <idr@ietfa.amsl.com>; Wed, 25 May 2016 03:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_LWexDvLkBU for <idr@ietfa.amsl.com>; Wed, 25 May 2016 03:05:27 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2544612DA68 for <idr@ietf.org>; Wed, 25 May 2016 03:04:35 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 5D2CBAD36F435; Wed, 25 May 2016 10:04:31 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4PA4XM7008364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 May 2016 10:04:33 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4PA4UNR032517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 May 2016 12:04:32 +0200
Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.27]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 25 May 2016 12:04:30 +0200
From: "Van De Velde, Gunter (Nokia - BE)" <gunter.van_de_velde@nokia.com>
To: Randy Bush <randy@psg.com>, Gunter Van De Velde <guntervandeveldecc@icloud.com>
Thread-Topic: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)
Thread-Index: AQHRtmzTn5LkPObdZkaQFH2DakgGoA==
Date: Wed, 25 May 2016 10:04:29 +0000
Message-ID: <7A74147C-9988-40DE-A458-6F6F7609FF7D@alcatel-lucent.com>
References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <3F1E4C52-A3EF-48E0-A1F9-E5A3A71658B5@alcatel-lucent.com> <m2vb22qyvd.wl%randy@psg.com> <73AB7C41-FA1D-42AB-9D5E-CE7BB37413BB@icloud.com> <m2twhmqxml.wl%randy@psg.com>
In-Reply-To: <m2twhmqxml.wl%randy@psg.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="utf-8"
Content-ID: <A369FC63BB549F4EBCE767DED478140A@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/JlEirw4Carilou4zJYmQSXb69zo>
Cc: idr wg list <idr@ietf.org>
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 May 2016 10:05:29 -0000

Indeed, nothing on protocol level. Apologies for the confusion.

I was thinking about an operational message and something similar as last paragraph of chapter 4.1 from draft-ietf-grow-ops-reqs-for-bgp-error-handling-07… 

“”
Since the Non-Critical error handling required within this section
   results in no NOTIFICATION message being transmitted, the fact that
   an error has occurred, and there may be inconsistency between the
   local and remote BGP speaker MUST be flagged to the network operator
   through standard operational interfaces (e.g., SNMP, syslog).  The
   information highlighted MUST include the NLRI identified to be
   contained within the error message, and SHOULD contain a exact copy
   of the received message for further analysis.

“”

G/

On 25/05/16 11:45, "Idr on behalf of Randy Bush" <idr-bounces@ietf.org on behalf of randy@psg.com> wrote:

>>>> Section 5 – par1: When using the more liberal policy, I believe it
>>>> would make sense to indicate a message that an extended message was
>>>> received while it was not expected at all
>>> 
>>> please be specific.  by "indicate a message" are you suggesting a new
>>> "you sent a surprise" response message?
>> 
>> Yes, indeed… something in a syslog or so that the peer sent some
>> unexpected packet to alert the ops team to look into it.
>
>so you do not mean a bgp message, but rather that errors should be
>logged and maybe an snmp trap raised.  so, if we start to add a short
>sentence or paragraph on this to the end of section 5, how far do you
>want to go?  is there something to which we could point?
>
>randy
>
>_______________________________________________
>Idr mailing list
>Idr@ietf.org
>https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email