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

Job Snijders <job@ntt.net> Thu, 20 April 2017 17:37 UTC

Return-Path: <job@ntt.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182271314A3 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 10:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw6mekC7FaEJ for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 10:36:58 -0700 (PDT)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C45129B3A for <idr@ietf.org>; Thu, 20 Apr 2017 10:36:54 -0700 (PDT)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <job@ntt.net>) id 1d1G0k-0002QH-2u (job@us.ntt.net) for idr@ietf.org; Thu, 20 Apr 2017 17:36:54 +0000
Received: by mail-wr0-f172.google.com with SMTP id c55so40342570wrc.3 for <idr@ietf.org>; Thu, 20 Apr 2017 10:36:53 -0700 (PDT)
X-Gm-Message-State: AN3rC/7jlNGjtvD/at+FIWQyXZHvNvRO6EDPC6d3P54xz7b3geMxetXd rqPo4DOSva65VQL6TXLpv3Nojf8+zw==
X-Received: by 10.223.148.199 with SMTP id 65mr8539819wrr.37.1492709812694; Thu, 20 Apr 2017 10:36:52 -0700 (PDT)
MIME-Version: 1.0
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <abe393d3-d1e4-7841-4620-38dab751765b@cisco.com> <68B29403-9AD9-4F06-9FE4-3F077E793D9F@puck.nether.net> <275cf744-1f64-bcbc-dabe-a47479921230@cisco.com> <20170420154142.lacvtplusepy3qcf@hanna.meerval.net> <b57162ec-f806-6e86-7713-58608f72c468@cisco.com> <20170420164314.av26kcxvxglg4oet@hanna.meerval.net> <3b681e50-bf6d-df75-eb61-86be79a2fbb8@cisco.com> <20170420165757.safd32x2xu5awwxp@hanna.meerval.net> <CA+b+ER=4gRPGf6rZRvwmB8SX51Pfq5CDQE3p2z=2akFRdettLg@mail.gmail.com> <20170420172904.GD25069@Space.Net>
In-Reply-To: <20170420172904.GD25069@Space.Net>
From: Job Snijders <job@ntt.net>
Date: Thu, 20 Apr 2017 17:36:41 +0000
X-Gmail-Original-Message-ID: <CACWOCC-2HfeN4mANmXMxts_ReyR61Utey=pMTiyr9M6x72Q5Ag@mail.gmail.com>
Message-ID: <CACWOCC-2HfeN4mANmXMxts_ReyR61Utey=pMTiyr9M6x72Q5Ag@mail.gmail.com>
To: Gert Doering <gert@space.net>, Robert Raszuk <robert@raszuk.net>
Cc: Hares Susan <shares@ndzh.com>, Job Snijders <job@ntt.net>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0d2266238fca054d9c96fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/e9EncizFXG3ks5MoiXbK6rIvBi8>
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-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Apr 2017 17:37:00 -0000

On Thu, 20 Apr 2017 at 19:29, Gert Doering <gert@space.net> wrote:

> On Thu, Apr 20, 2017 at 07:15:07PM +0200, Robert Raszuk wrote:
> > *A* Must it be per neighbor ? Can it be per VRF/table/bRIB  ?
>
> per neighbour, or per peer-group/neighbour-group



The purpose is per neighbor. Questioning this aspect makes me suspect you
might not grok the concept and problem space at all.


> *B* Does enabling BGP Origin Validation should be considered as such
> policy
> > or not ?
>
> certainly not for egress.
>
> for ingress, it *is* a policy, so I'd see it as "good enough"



BGP origin validation in itself is not a policy, but a database against
which you can lodge lookups. An operator has to configure the device to
drop or accept RPKI invalids. If the operator has formulated that policy
and associated it with the session, you have a policy.


> *C* Should received routes still reside in Adj_RIB_In ? Should BMP still
> > send all routes to collector even if those would be considered not
> > complaint with RFC ?
>


Alvaro suggested text to that extend.


> *D* If we do eBGP auto discovery in IX env of peers would that overwrite
> > such RFC ?



Why would it?

>

> *E* If someone does LLDP based eBGP peer discovery on p2p would that also
> > be exempt from such enforcement ?



Why would it?


Kind regards,

Job