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 <> Thu, 20 April 2017 13:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BAF8913145D for <>; Thu, 20 Apr 2017 06:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 3DqyTX8eFu2H for <>; Thu, 20 Apr 2017 06:51:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8554E12954D for <>; Thu, 20 Apr 2017 06:51:02 -0700 (PDT)
Received: by with SMTP id r16so68714840ioi.2 for <>; Thu, 20 Apr 2017 06:51:02 -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=Dfi7mK78OXuR9Cg4pHA/R56ooHMurMaRiyhYjBechGE=; b=GwOHRz9jynkO8pxDah/ooLXd6zom8SZU1zsUYIA3Zt0peyqpFc8Zc7z15vdizk2BIP 0UMVHFm5qv8LAwk9ONvyW7cuXJ5yZl3DQp3qgKEQR0QJl1uls0YHTXLA9UbdSKB1XG6m CA0mXKpl8F14rLbi8ruGMK/wwJ0gbK9Kpd32ZYzms9gYhlm+w8MJt/09j8GzejXnh3aB hDmMUOzY9VdVqtcsmjOOhRok0indLDaB/f7W7icPeAHmt+FRj9Z0wXmPhBLKOh+L/yzJ 21iQxlupuayAYQ4efLBAdlYl6WHuCKNs6BAVAUO7jv7ccQ+rmjLLW45Y4up8UVsurfsX dT1g==
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=Dfi7mK78OXuR9Cg4pHA/R56ooHMurMaRiyhYjBechGE=; b=G3dq6v/h3ShWYixITmtXS/SiKhZ7WufrnHX6THAusqwirIZrx0cTrvw9v15mdIGPli jPhI5Xhz1JKTCCFnQkW811QEjDisZXnLCrvdcLHIE4zbFsDyuVh6eAhuJo5Ng7Ls9JB7 +ROrCvWe14gFHp88iRsbsbuZIET0oQVusIVCOck2Xj7C/T85J5Yo/UUx9BqzLEYZlORv 2XbcKO+VQnrHpmSoZkhzT0/T8/+A5Rh7DXAtbRvubc5pbkCsHCXHOAkjlOOVRVs0P0Of S74KerX9ZIUhKBwxNO5uJfbec/kUYt6UgldgNbBBivhqiyhC6p3M5pC+uO/RyV1Q20RC Qy2A==
X-Gm-Message-State: AN3rC/4XBswe9eFt1x3JCTNDQpy2Lwus8NxFQisEOCwtlx6nengtLv8Z v75ip4o0HI0xMOusfkJu4mbB4Q8xifc+
X-Received: by with SMTP id q143mr3665009itq.25.1492696256053; Thu, 20 Apr 2017 06:50:56 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 20 Apr 2017 06:50:55 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Robert Raszuk <>
Date: Thu, 20 Apr 2017 15:50:55 +0200
X-Google-Sender-Auth: KcuSridEZsJVmnVb97Y6zOin-5Y
Message-ID: <>
To: Jared Mauch <>
Cc: Keyur Patel <>, "Acee Lindem (acee)" <>, Hares Susan <>, "" <>
Content-Type: multipart/alternative; boundary="001a1140b16019ae67054d996e8a"
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: Thu, 20 Apr 2017 13:51:04 -0000


- Vendors can take the N+1.x and N+2.x release strategy, where in N and N+1
> they generate their equivalent of IOS-XR and the "bgp unsafe-ebgp-policy”
> policy to prevent their customers from breaking
> - In a release N+2(or more) that would become the “default”.

​In the past things like that were also actually solved within single
release by automatically generating this line of "missing" configs if no
other policy was configured. However for this specific case I am not sure
what does it buy you in practice. Maybe consistency across BGP
implementations.  ​

> At least doing it as part of OPEN msg will be immediately indicated to
> both ends.
> This is you promoting a different draft, I recommend another thread for
> that draft.

​Well if both drafts can solve the same problem maybe there is a room to
discuss it and pick one to go forward with.