Re: [Idr] AD Review of draft-ietf-idr-bgp-gr-notification-13

Jeffrey Haas <jhaas@pfrc.org> Tue, 10 April 2018 14:18 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 37AC2128954; Tue, 10 Apr 2018 07:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 xTzVIxWKSWvm; Tue, 10 Apr 2018 07:18:09 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9E512895E; Tue, 10 Apr 2018 07:18:09 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 516B81E403; Tue, 10 Apr 2018 10:18:52 -0400 (EDT)
Date: Tue, 10 Apr 2018 10:18:52 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: bruno.decraene@orange.com
Cc: "John G. Scudder" <jgs@juniper.net>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-bgp-gr-notification@ietf.org" <draft-ietf-idr-bgp-gr-notification@ietf.org>
Message-ID: <20180410141851.GA24256@pfrc.org>
References: <CAMMESszAe0avmcX0X95uOwRu29cTvbx_t7ewBwU-Hig20SD9pg@mail.gmail.com> <03AE36E3-F18B-4F34-9A6C-242AA1CAB4EC@juniper.net> <25077_1523005047_5AC73677_25077_122_1_53C29892C857584299CBF5D05346208A47A006C8@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3197C941-3EBD-4BE0-B733-9C72A6B3B5FA@juniper.net> <31660_1523350345_5ACC7B49_31660_129_1_53C29892C857584299CBF5D05346208A47A05A21@OPEXCLILM21.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <31660_1523350345_5ACC7B49_31660_129_1_53C29892C857584299CBF5D05346208A47A05A21@OPEXCLILM21.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/v5QpKgFGuDQpRjIcQOaD6yno6k8>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-gr-notification-13
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 10 Apr 2018 14:18:11 -0000

Bruno,

On Tue, Apr 10, 2018 at 08:52:24AM +0000, bruno.decraene@orange.com wrote:
> In case of Hard Reset “encapsulating” another notification, I had a comment about which Error (sub)Code is to be indicated to the network operator (e.g. in Yang, SNMP, Syslog…) I’m not seeing an answer nor clarification in the draft. (I’m not sure there is a good answer, but I’d prefer a consistent answer from all implementations)
> 

I'm not sure there's something to be consistently done here.

I believe your point is that if you receive a hard reset, you want to make
sure the underlying reason in the tunneled code/subcode is bubbled up the
management layer so you can see the WHY of it.  E.g. max prefix exceeded.
This is a good goal.  However, the implementation issues make trying to
provide normative behavior for this difficult.  

We provide no guidance for display of notifications in syslog in any BGP spec.

The RFC 4273 MIB doesn't provide any access to the notification DATA field.

The BGP MIBv2 work does provide a human readable text string where this
could go, but the contents of this field was intentionally not specified.

The IDR yang module (stale) doesn't have notifications in it.

The openconfig BGP module covers code/subcode, but not any human or machine
readable element for the DATA field.

My employer's implementation will grab the inner code/subcode and provide
that in the UI, but appears to lose the semantics that it was a hard reset.
(Sigh. Minor bug to file.)

The above mostly is intended to agree that there's valid management
considerations to be dealt with, but I don't see a good path forward.

-- Jeff