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 <> Wed, 26 April 2017 12:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B574F129B5D for <>; Wed, 26 Apr 2017 05:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 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, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dlb9NkFo_Ssr for <>; Wed, 26 Apr 2017 05:00:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DBF8129B6D for <>; Wed, 26 Apr 2017 05:00:47 -0700 (PDT)
Received: by with SMTP id 70so36955153ita.0 for <>; Wed, 26 Apr 2017 05:00:47 -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=PCy0ZvVcVdms1uukxv8o1hP/Q+Qf7wO0OhYy7MePzyw=; b=F9+uBljBMl0oudkPJHqga4CFhX8tQce5Qv515FkmoZkplFbdA28J1H5kupSg7Oy9h0 YQ1vEipUshOES2ckT44rRWEqWPcY3/Y53/MVkJorUAIvTorcFM9Nre6UY6cEaI5RAmTe 9J094+6Yh16ilLLuPwE4W+jvxffBmuMLSlGqD5cYGyp61adINqhLHSPymMECfD4SpCoz tUhSFGuI+WF4xYekWDdaPQcvzhWbfnnoEt3bgLIWYgz+IlCHq0kjSf+H7WMetR2ljxp1 7HoPlmaEUXlTsoR8R05FFVFux953HVusqui/ebRH1myKmAeZdAUU7bY6n4hhLFr7/yHc eMoQ==
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=PCy0ZvVcVdms1uukxv8o1hP/Q+Qf7wO0OhYy7MePzyw=; b=bUzLylxjRP5q2N3qMOeCiUVhzu9hgNIA0LY2AbRaGkpgzPUx0zHyyVdQqAoPJjCYT5 e62mka7uPe79EIKyHxH+ikDUN3zmuw0wSFybPw7MJP0vqHYbqElnWGEuSlqbo+MWql51 yuIISKFNb1a8bbQCKUijmpTBM3nJqAQpDHmpo0ntcL0bU/QkqpSQASuLDRYRqUGFFfRr gOA4t7ypTyg3LUNEar6bYGvTNqjeAu2jqlw1czKYtSmuWPwlI9i6w2+gPk2GRWmwbnut h2+2JFTm3b51r2rX05WTICkG3bo01wWnSikN4CygyGjfc/bSrOEAv1mwe05wTjIBtYcy 6clw==
X-Gm-Message-State: AN3rC/5xMy5f9ZyGuOHtvKRmXFPVu6z/FyiXBb5LxGaSbWbK259uyCqO gRpaC5/IgNRiZk54e0qu1699GHcHHA==
X-Received: by with SMTP id h132mr10673229itb.104.1493208046585; Wed, 26 Apr 2017 05:00:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 26 Apr 2017 05:00:45 -0700 (PDT)
Received: by with HTTP; Wed, 26 Apr 2017 05:00:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <023e01d2be72$031ac180$> <20170426095547.GP25069@Space.Net> <> <>
From: Robert Raszuk <>
Date: Wed, 26 Apr 2017 14:00:45 +0200
X-Google-Sender-Auth: V06QXOUrnrH6F1_rjOzs-3ijH0A
Message-ID: <>
To: Jared Mauch <>
Cc: Gert Doering <>, idr wg <>
Content-Type: multipart/alternative; boundary="001a114252723151d6054e1097ba"
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: Wed, 26 Apr 2017 12:00:54 -0000

Hi Jared,

So let's talk examples ... for my own education.

If you are provider and have 1000 multihomed customers with v4/v6 PI space.

Imagine you want to apply granular policy better then permit all on your

How practically (considering that your customers get address block all the
time) you wilk track and adjust policy o  a daily basis ?

You need offline machinery when unless they log in and inform you their
routes will be denied. Moreover your backend must be able to check if
prefix does not belong to someone else .... Oh wait what if someone else
just sold it to them ?

With PA blocks policy works well ... with PI I think not so.

And if you are customer and have 4 prefixes in BGP table thing are fine. If
you by accident become transit and advertise fulm table around I think we
can do better in BGP to protect from it then mandate policy.


On Apr 26, 2017 7:39 AM, "Jared Mauch" <> wrote:

> On Wed, Apr 26, 2017 at 01:28:49PM +0200, Robert Raszuk wrote:
> > Hi Gert,
> >
> > Unless the result is not lost of connectivity but lost of BGP path
> > redundancy from your AS.
> >
> > It is quite often and in fact good idea to have dual vendors as your
> ASBRs.
> >
> > So unless proper cli is automagically added the problem may only  surface
> > weeks and months after upgrade and in fact far from given ASBR when
> > external link from still operational ASBR breaks.
> >
> > Document should discuss that as well and recommend such auto cli.
>         I've only cited CLI as an example of how others have addressed
> the concerns raised in the thread.  For the purpose of IDR I don't
> wish to mandate that part of a solution, but cite other viable
> operational alternatives.
>         Saying that a BGP operator needs some "auto-cli" to know how
> to do BGP stuff tells me these people should not be trusted with BGP
> outside their own labs.
>         The pollution here is real, when I was at NTT we worked to
> mitigate it via a variety of methods.
>         We also had executive escalations that reached my desk where people
> didn't do their simple homework of "we had two links, redundancy
> didn't work, you took us down big bad $ISP".
>         Once I said "Hi, you are only sending 2/3 of your routes on
> your backup session, do you want to fix that now while I observe" they
> quickly settled down on their escalation issues.
>         Things break, people need to learn how to debug the technologies
> they are using.  We should be working to make it simple, yes but not
> by foregoing an operator developing their own skills to identify problems
> and using their supported vendor paths to triage it.
>         Putting text in the draft that it must take the form of
> "show bgp neighbor 2001:db8::1 " would favor one vendor over another
> and perhaps open the draft up to IPR claims.  I do not welcome these
> suggestions.
>         The reality is many of the operational leaks we see today are
> because of one or multiple failures in the routing ecosystem, be it
> a network link, NLRI filter, AS_PATH filter or otherwise.
>         - Jared
> --
> Jared Mauch  | pgp key available via finger from
> clue++;      |  My statements are only
> mine.