Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

Robert Raszuk <> Fri, 21 April 2017 09:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 433EF129A8D for <>; Fri, 21 Apr 2017 02:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.409
X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QcbYbLa6YWok for <>; Fri, 21 Apr 2017 02:35:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 34D3B1287A5 for <>; Fri, 21 Apr 2017 02:35:08 -0700 (PDT)
Received: by with SMTP id k87so112043414ioi.0 for <>; Fri, 21 Apr 2017 02:35:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Vk1UeNVoKjwtMrSDJ2Oq8zKH47vrsso4s9ZavceVIZI=; b=AG5xkjo3SZ5lRd5R31CY7UgXFbmbaMhDUw53FU/AUdZ17tsgOBpvnfNP8IeB8IGeRr zQr2Gi2gRDUs20frAEsDkcz76c+04Rsr3f8TcSMrWIzNrhjEq3+mPa3rqESK7QV7gGt1 70oG54SxHbZoTjpZTKISKkcvikJwUwEnjaMoZAtThWXaaG+kmaLB4IX41U+sQlYoEONf W2Ea0qhENwlNYn+PJUgoPZ6cUJvSMLOOa6JAfp+fXq3T5yr1w+oDwvpsE+PfS38GRqsE zl6DvojEB05z9d7goP7BFkLmg0mf+LarzmSkLh9LtaB6R/EWZrLSBZOdOkT1c1PA1lBi y0RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Vk1UeNVoKjwtMrSDJ2Oq8zKH47vrsso4s9ZavceVIZI=; b=dIszX8fr0h5ch+sxhu8jaMxkF3GqSHzpYUAqBsnN4/kqXjGtokMwng4+29Imhe58QY ZM75LDoEXUfkHEd33/l4ug9TaSPdmEafEkS9tf5dyxDk+tHFoKtOpbTsfs0E9xfJes5D g/3gtv0drODuqwv03BpFwaWhlejq44AE8dCxLfexQg1EFFbjX3q4/l26lSwJfqOD7xgt rvVzsiSiMbzxSh0dNmgML7LYRZfaKljRCnDX5d8MRtqogmXla5UZFfazSan34YBSlSiw mHnub/exMKR64jYKTeCqEDo6s3FYDdixGWcSGi5Z57lzlWjrhDwaZ0NVFsalG4enyOlP CQeA==
X-Gm-Message-State: AN3rC/7SCigRZiNP9Y9tZHj1QrWyr70kv8ue5914DrY6TyEzMu1MY7Bj cEIOncnmitPwSbsLjXaLZQJnU1ATgA==
X-Received: by with SMTP id h129mr15436226ioh.57.1492767306922; Fri, 21 Apr 2017 02:35:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Apr 2017 02:35:06 -0700 (PDT)
In-Reply-To: <20170421090145.f5yuhimb4qg7knrf@Vurt.local>
References: <> <> <> <> <> <> <> <> <> <28014_1492762849_58F9C0E0_28014_6541_1_53C29892C857584299CBF5D05346208A31CC3773@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421090145.f5yuhimb4qg7knrf@Vurt.local>
From: Robert Raszuk <>
Date: Fri, 21 Apr 2017 11:35:06 +0200
X-Google-Sender-Auth: RccxSqOdo9Fng0_nmhu1aDt4N9Q
Message-ID: <>
To: Job Snijders <>
Cc: "" <>, "" <>
Content-Type: multipart/alternative; boundary="001a1140f5e80fc512054da9f9dc"
Archived-At: <>
Subject: Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
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: Fri, 21 Apr 2017 09:35:10 -0000

​Hi Job,​

> Did you review Alvaro's suggested changes which prompted the third IDR
> consultation on this topic? They are viewable here:
> draft-mauch-bgp-reject/blob/alvaro/draft-ietf-grow-bgp-
> reject-06-from-5.diff.html
Do we really have consensus among all authors of this document (leave alone
rest of IETF) that it should apply to all AFI/SAFIs ?

I personnally would recommend to apply it to only 1/1 and 2/1.

And actually even take those SAFIs your claim that it helps case of
sessions being dropped is very implementation specific ... some
implementation when receiving routes to VRF from CE may first check the
maximum-prefix number as expressed in "neighbor maximum-prefix 30"
then check per VRF then apply say BGP prefix-list.

Does this RFC also enforces that BGP route-map or policy should be the
first consideration in BGP inbound processing ?

explicit configuration of a BGP import and export policy for any
External BGP (EBGP) session such as customers, peers, or
confederation boundaries
*​​for all enabled address families*. When this

- - -

Last ... what's your take on multiple comments regarding build in silency
of this ?

See session will be established just fine ... even incoming prefix count
will be incremented just fine.

Last time I checked until you display bgp table there is no separate
counter in any implementation to indicate in BGP summary how many out of
received paths were best path eligible.