Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT)

Brian Haberman <brian@innovationslab.net> Fri, 06 March 2015 21:09 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68D21A86F8; Fri, 6 Mar 2015 13:09:50 -0800 (PST)
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] autolearn=ham
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 hEg92AVD_Owu; Fri, 6 Mar 2015 13:09:49 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A801A86F0; Fri, 6 Mar 2015 13:09:49 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 380F388112; Fri, 6 Mar 2015 13:09:49 -0800 (PST)
Received: from Brians-MacBook-Pro.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8CCC313682D7; Fri, 6 Mar 2015 13:09:48 -0800 (PST)
Message-ID: <54FA1795.5000406@innovationslab.net>
Date: Fri, 06 Mar 2015 16:09:41 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: rob.shakir@bt.com, shares@ndzh.com, iesg@ietf.org
References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> <122301d0584e$e8395830$b8ac0890$@ndzh.com> <D11FC3C4.96400%rob.shakir@bt.com>
In-Reply-To: <D11FC3C4.96400%rob.shakir@bt.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="QeWefDnCaIMM71PJMHkGhN1qaeWBGIg2L"
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/v-88ILLakbPwPWj_zzQGTKYBYKM>
Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, idr-chairs@ietf.org
Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 06 Mar 2015 21:09:51 -0000

Hi Rob,

On 3/6/15 3:59 PM, rob.shakir@bt.com wrote:
> Hi Sue,
> 
> You remember correct ‹ there were a number of issues that occurred around
> the time that this document got started (I presented about them at NANOG
> 51 ‹ http://www.slideshare.net/robjs/bgp-error-handling-nanog-51), and I
> also edited the requirements document for this work (which is in GROW ‹
> https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling
> -07). 
> 
> We also wrote up some recommendations based on the original AS4_PATH
> incident (which triggered draft-scudder-idr-optional-transitive) which
> were on NANOG and IDR -
> http://mailman.nanog.org/pipermail/nanog/2009-January/006816.html and
> http://www.ietf.org/mail-archive/web/idr/current/msg03546.html.
> 
> The reason that I think the 2119 wording is in there (and is still
> appropriate) is that there are complexities that are introduced
> operationally with this mechanism that did not occur before. The previous
> behaviour of a failed session makes a bunch of noise, and hence the issue
> can be diagnosed and examined. With the treat-as-withdraw approach it¹s
> critical for operators to be able to determine when malformed UPDATEs are
> being received, and that sufficient information is given to the operator
> to resolve the problem. If we do not have these mechanisms, prefixes are
> being withdrawn via an (otherwise working) session - with the operator
> having no clue this is happening. Needless to say, this would be
> undesirable, and hence to avoid it, these recommendations are made.
> 

The above is quite clear and shows me how I think I misread the second
paragraph.  I read it has saying the operator SHOULD identify the
offending route and trace it back to its ingress into the network.  The
description above sounds like the text is saying the router SHOULD
provide enough information so that the operator knows to trace the
offending route.

Am I interpreting that correctly?

Regards,
Brian