Re: [Idr] Post-Last Call Shepherd Comments for draft-ietf-idr-error-handling (was Re: Last Call Expired: <draft-ietf-idr-error-handling-18.txt>)

Alia Atlas <> Thu, 12 March 2015 16:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 505E61A872F; Thu, 12 Mar 2015 09:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 74fPtOENJido; Thu, 12 Mar 2015 09:01:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8DC61A1B20; Thu, 12 Mar 2015 09:01:49 -0700 (PDT)
Received: by oibg201 with SMTP id g201so15356490oib.10; Thu, 12 Mar 2015 09:01:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wDwErzk2Bu5ysN5FYVdvSfb1n94p+wBuX5IQB6bQLIk=; b=CLzBy/eKpGdumtj/WZ95Md+W0jEb7DH5krRemg+z9C4CK1YYJcD2t4MYHS1crFjC7f 5E6KF4Ae2DOOKQohqVKH/doWewoDPtRaul/CMjzWzWGBEGfENqjYkuDuafmaEy/4fxYU yaYyhEbcEg35Kmj4trl4sR4RLK558WwBc0V9U9ucmtTK3DJYGfhvvp0FO59bla6evVLK 0nAbxqKH4BA7BTQaitLtTTHWpOPQAyoNl0AwiSXvLLOqErGlGbCMzI9b4rvo/GRsbFNN q0QPE/q6FuXCk0SHbe0sdw9kjN1NwBYkFXbwe5JlNrOKbngVsbHMsCiUJMQ+mGE2kyL3 rPUw==
MIME-Version: 1.0
X-Received: by with SMTP id z8mr34609253oew.13.1426176109281; Thu, 12 Mar 2015 09:01:49 -0700 (PDT)
Received: by with HTTP; Thu, 12 Mar 2015 09:01:49 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 12 Mar 2015 12:01:49 -0400
Message-ID: <>
From: Alia Atlas <>
To: Rob Shakir <>
Content-Type: multipart/alternative; boundary="089e0111d7ca618726051119807d"
Archived-At: <>
Cc: "idr@ietf. org" <>, Rob Shakir <>,, "" <>,
Subject: Re: [Idr] Post-Last Call Shepherd Comments for draft-ietf-idr-error-handling (was Re: Last Call Expired: <draft-ietf-idr-error-handling-18.txt>)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Mar 2015 16:01:57 -0000

I'm not convinced that we can use 2119 SHOULD language to put requirements
on humans.
I do agree about what the operators should do but without the SHOULD...


On Thu, Mar 12, 2015 at 7:26 AM, Rob Shakir <> wrote:

> > On 12 Mar 2015, at 07:08, DraftTracker Mail System <
>> wrote:
> >
> > I-D: <draft-ietf-idr-error-handling-18.txt>
> > ID Tracker URL:
> >
> > IETF Last Call has ended, and the state has been changed to
> > Waiting for AD Go-Ahead.
> Folks, Authors,
> Keeping track of the IESG comments on this draft, and some of the other
> feedback that’s been received from directorate reviews:
> * gen-art provided some comments (you can find them at [0]) that it would
> be good to address.
> * Stephen Farrell’s review raised a few nits (some of which are duplicate
> from the gen-art review.
> * multiple comments about §6 of the document and particularly the rfc2119
> wording have been raised. Can I suggest that we restructure this section
> slightly:
>    Although the "treat-as-withdraw" error-handling behavior defined in
>    Section 2 makes every effort to preserve BGP's correctness, we note
>    that if an UPDATE received on an iBGP session is subjected to this
>    treatment, inconsistent routing within the affected Autonomous System
>    may result.  The consequences of inconsistent routing can include
>    long-lived forwarding loops and black holes.  While lamentable, this
>    issue is expected to be rare in practice, and, more importantly, is
>    seen as less problematic than the session-reset behavior it replaces.
>    The treat-as-withdraw mechanism is different from discarding an UPDATE
>    message. The latter violates the basic BGP principle of
>    incremental UPDATE, and causes invalid routes to be kept.
>    Since treat-as-withdraw may result in such inconsistent routing within
>    an AS, complete un-reachability or sub-optimal routing for the
>    destinations whose routes are carried in an affected UPDATE message, a
>    BGP speaker MUST provide debugging facilities to permit issues caused
>    by a malformed UPDATE to be diagnosed. At a minimum, such facilities
>    include logging an error listing the NLRI involved, and containing the
>    entire malformed UPDATE message.
>    When such an error is logged, it is recommended that an operator
>    SHOULD analyse the logged UPDATE message, and SHOULD investigate the
> root cause.
>    Where there source of the erroneous UPDATE message is external to the
>    autonomous system, or administrative domain, of the operator - we
>    RECOMMEND that an operator traces the erroneous UPDATE message to the
>    ingress router which sourced the routes, or received the routes
>    externally - and applies a filter to prevent the routes being announced.
>    This helps to maintain routing consistency in the network.
>    Section 8 mentions that attribute discard should not be used in cases
>    where “the attribute in question has or may have an effect on route
>    selection.” Although all cases that specify attribute discard in this
>    document do not affect route selection by default, in principle,
>    routing policies could be written that affect selection based on such
>    an attribute. Operators SHOULD take care when writing such policies
>    to consider the possible consequences of attribute discard. (In general,
>    as long as such policies are only applied to external BGP sessions,
>    correctness issues are not expected to arise.)
>   Hopefully this makes reasonable use of RFC2119 wording too. I think that
> if we are saying that the implementation MUST/SHOULD do something to
> maintain correctness then we should say that the operator SHOULD do
> something too! I think structuring the section into these two elements
> (box-behaviours followed by people-behaviours) adds some clarity.
>   * Stephen also raised a point about security considerations - this
> seemed (to me) to relate more to security considerations of
> treat-as-withdraw when used as a behaviour within BGPSEC. My (personal
> opinion) is that this concern would be better covered in the BGPSEC
> documents - since this document (at the moment) does not update any
> document related to BGPSEC.
>   * Our esteemed new AD reviewed too — thanks Alvaro. The review can be
> found at [1].
>         * 1 & 2 - there is a request to have a summary of what RFCs are
> updated and how in the document. Potentially this could be added as an
> appendix?
>         * In the security considerations section, Alvaro observes that
> remote withdrawal could be a new attack vector that is introduced. We
> should mention this, but raise the consideration that rather than causing
> session tear-down (which might result in isolation of an ASN).
> Thanks for all the work thus far on this document — I look forward to this
> doc progressing further!
> r.
> [0]:
> [1]: