Re: [Idr] Review of draft-ietf-grow-bgp-reject-05

"Alvaro Retana (aretana)" <> Wed, 19 April 2017 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35FCA1274D0; Wed, 19 Apr 2017 06:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5zKicn2F-AWo; Wed, 19 Apr 2017 06:53:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8A18127B60; Wed, 19 Apr 2017 06:53:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2082; q=dns/txt; s=iport; t=1492610026; x=1493819626; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=asJ+ucvZcynrAWgPlP4rcYrEgnQYjnP21YTokBaWDfo=; b=Oydz7dThLs8fNwEuJtxGihrgTcAVN3yfQrXD7sV9XM3f7IYiD6Ja102X U8BcXytcRMCPVE4gNUwGfgIKQkxdW9NIm+ZcX892gA1Jl2LT9SdgLpi9U V2LECHYX+Rg3zNt1IqF6oEejZYjqcX96ODArvbpmi+OtUBDIYQPeb1xjv 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.37,221,1488844800"; d="scan'208";a="414601773"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 13:53:45 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v3JDrjTt029900 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Apr 2017 13:53:45 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Apr 2017 08:53:45 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 19 Apr 2017 08:53:45 -0500
From: "Alvaro Retana (aretana)" <>
To: "John G. Scudder" <>
CC: "" <>, Chris Morrow <>, "" <>, "" <>
Thread-Topic: [Idr] Review of draft-ietf-grow-bgp-reject-05
Thread-Index: AQHSuETpEi5RDG0LC02mWBjlM+E8lKHNBG8A///EggA=
Date: Wed, 19 Apr 2017 13:53:45 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Idr] Review of draft-ietf-grow-bgp-reject-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Apr 2017 13:53:48 -0000



My bigger issue with 9.1.1 is that it is the first step of the decision process – the intent, as I understand it, is for the routes not to even reach that point.

If the text in 9.1.1. is interpreted as “MUST NOT” (which is not what it says!), then there is probably more work to be done (in the conceptual model), but it would be ok.  However, I really have a hard time changing Normative language…

Thanks for chiming in.


On 4/19/17, 9:26 AM, "John G. Scudder" <> wrote:

On Apr 18, 2017, at 9:08 AM, Alvaro Retana (aretana) <> wrote:
>Note that 9.1.1. says that if “the route is ineligible, the route MAY NOT serve as an input to the next phase of route selection”.  IOW, even if routes are “ineligible” they can still be used (because of the MAY), which is not what is wanted.

Oh cool, MAY NOT is actually not a special term defined in RFC 2119. It doesn't have any special meaning despite the ALL CAPS. I think the plain English of it is clear in context -- the authors meant MUST NOT in 2119-speak. 

I think this is actually an erratum against 4271. To make matters worse, there is one other occurrence of MAY NOT in 4271, and in that case the intent is clearly the other way around -- in 4271, section 5, we have "Others are discretionary and MAY or MAY NOT be sent in a particular UPDATE message".

I'll plan to open errata against 4271 for these.

IMO the language in draft-ietf-grow-bgp-reject-05 is OK.