Re: [bess] Point #3 on draft-ietf-grow-bgp-reject

Robert Raszuk <> Sat, 06 May 2017 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0F98120454; Sat, 6 May 2017 10:12:42 -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 eMD4anhkFjkU; Sat, 6 May 2017 10:12:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4A9C126C26; Sat, 6 May 2017 10:12:40 -0700 (PDT)
Received: by with SMTP id e65so23276671ita.1; Sat, 06 May 2017 10:12:40 -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=VS5DFREwGEiCguH1KngNs+5MG2VnDQO9ZfxWR01m7Y8=; b=NMvicBOkAyHZUdac7/DfgFsGTJIjOsB37NmHQjmjiL9HFdNcA/CTQ0ZbMDResN6du5 KR9z3FXo+eF3ermpITEv/O5ULfAzzlDJ9SflL96yZFTUZNtuGHVjVFbYkCmQZEmFmD7Y UkFW2Blkp392Bermj1EXdL+hoCnY6VCYWz9ven4+h1G6Wskj84Zh2Bb5Hiagpojvdu3C LAyf7kX7bk5ni2b3J2gIGWJWI6XaT6aSkk6hfrxwmWYynlB10GiTPaE4Ns9dXvMPvP29 J0mksNB7HHarMUCiH5LgPFujubYE1YI9du4Z/+3R2zio/dLIpHpbfHZYoMXhOmOLrKfu +F8Q==
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=VS5DFREwGEiCguH1KngNs+5MG2VnDQO9ZfxWR01m7Y8=; b=XxkskQkWv6ge2v74K7JT21CoK+lMedUdc6PfCe6vpEwEWhiR3d90VVPGx3qkONN+4l slBfL0/6GCmWIvfZNk0BIdzs9Bi2TNRSFv/Yq8gjABX8UvbgqHrWw6ZfsKIMPLxMpyF7 0rHvF/sG8NMOOtCPRpbD67ea+NhzX1BkvgYCNvKzuKf5z2CB7qTQB5/Gtf8FULSOTeJc ulliivGubye2Mxq402oq4RciVIlY4nGQj2YF57N0/67D8WqJN6DKcw37PVNVH9LPAabh rSpDAWDjsJP1H0jGVvqTrsk890KWyr7X4yRdAm4yqBP97tfWHMnY3mDYts5urICf56qF kdqw==
X-Gm-Message-State: AN3rC/4MHkD+qAhhAqJj1vUwITUbph/Apc4+5JlnctmyKr8R3u2qXZLr XmhTOwjTENOUo/dYVVmHAHlmZIdK2HxI8Yc=
X-Received: by with SMTP id c71mr13353072itc.18.1494090760026; Sat, 06 May 2017 10:12:40 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 6 May 2017 10:12:39 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Robert Raszuk <>
Date: Sat, 06 May 2017 19:12:39 +0200
X-Google-Sender-Auth: ocv_l_lDLQip1BYI66ulnD1Lf8k
Message-ID: <>
To: idr wg <>, "" <>
Cc: Warren Kumari <>, "Alvaro Retana (aretana)" <>
Content-Type: multipart/alternative; boundary="001a1140574e038d29054ede1da5"
Archived-At: <>
Subject: Re: [bess] Point #3 on draft-ietf-grow-bgp-reject
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 May 2017 17:12:43 -0000

Sorry one typo:

s/to make all receive routes ineligible for best path/to make all receive
routes eligible for best path/


On Sat, May 6, 2017 at 7:10 PM, Robert Raszuk <> wrote:

> Dear IDR and BESS WGs members,
> As you have either participated or seen from other email exchanges there
> is ongoing communication about change in eBGP specification to mandate by
> default use of policy in order to make all receive routes ineligible for
> best path and to suppress sending them to your peers. And that in spite of
> different opinions of the authors itself at this point is to apply to all
> existing and future AFI/SAFIs.
> John S. summarized this point as stated below:
> *"3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to
> apply only to Internet routing and not other applications?Pro: the
> motivation section of the document calls out the Internet use caseCon:
> there's no clear, unambiguous way to actually specify this (AFI/SAFI 1/1
> can be used in a VPN context, e.g.). different defaults for different
> AFI/SAFI is confusing for the user and the extra complexity not required."*
> So first let me observe that technically it is very clear to know that
> under vrf in a VPN context (towards CEs or inter-as ASBR in option A)
> address family ipv4 or ipv6 unicast is configured. There is no disambiguity
> of it of any sort. Likewise it is also very clear when address family vpnv4
> or vpnv6 is configured over eBGP Inter-AS option B or C sessions.
> During IDR discussion 4 individual contributors where opposed to make this
> proposal applicable to any eBGP AFI/SAFI and recommended to make it only
> for IPv4 and IPv6 existing address families. While in the same time only
> voice of 1 with reference to past discussion in GROW WG had taken place
> expressed otherwise. Well this reference to GROW list in 2016 results in
> one voice against, one pro and author concluding that this is pro all AFs.
> I think on that point if there is rough consensus at all it is really
> against that.
> Now why I am bringing this specific point up ...
> * There are numerous SAFIs in use today that even authors of this proposal
> fail to produce any valid in or out policy other then "send all/accept
> all". So even with good will operator will be simply forced to add those
> lines to the configuration. Now fun starts when an implementation code does
> not allow for it in some specific AFI/SAFIs or that manual policy would
> overwrite RTC or ORF based for L2VPN or L3VPN. That effectively means that
> to be complaint to this proposal implementations must change.
> * This draft is to update RFC4271 that means that now any newly defined
> AFI/SAFI will also have to define a set of policies to be used to enable it
> over eBGP sessions both in the draft/rfc and in the code. That clearly
> makes it harder for everyone with no gain.
> * There are address families today which are opaque to best path and are
> applied when received .. examples BGP-LS or Flow-spec. At most best path is
> run only when sending it out (if at all). The current spec does not limit
> reception of the information but does limit its eligibility for best path
> computation. I think there is room for large number of surprising
> behaviors with that for those SAFIs which carry opaque information to core
> BGP.
> * As the spec (as it is written today) applies to all eBGP sessions what
> happens if BGP UPDATE message contains in new SAFI no MP_REACH attribute at
> all and does not carry "routes" ? Would it be explicitly allowed ?
> (Example: draft-ietf-idr-operational-message-00).
> *  As the spec (as it is written today) applies to all "routes" received
> or to be sent over eBGP sessions it actually fails to define what is a
> "route" Within MP_REACH we have a concept of NLRI which for different
> address families have been redefined and departed long time back from pure
> definition of ip route.
> * If BGP UPDATE message carries only MP_UNREACH attribute .. so
> effectively routes to be withdrawn .. are those still subject to proposed
> policy or not ?
> Therefor I would like to ask members of both working groups to express
> clear opinion if this proposal and update to RFC4271 specification should
> apply only IPv4 and IPv6 unicast (AFI/SAFI 1/1 & 2/1) or should be extended
> to all AFI/SAFIs we have today and we are going to invent in the future.
> If the majority of WG members would choose to have this change applicable
> to all AFI/SAFIs I do ask authors to address in the document all of the
> above points before proceeding forward.
> Kind regards,
> Robert.