Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

"i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net> Sat, 22 October 2016 10:57 UTC

Return-Path: <martijnschmidt@i3d.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 3C28C1295EA for <idr@ietfa.amsl.com>; Sat, 22 Oct 2016 03:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Level:
X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 XgSIbfs31arB for <idr@ietfa.amsl.com>; Sat, 22 Oct 2016 03:57:56 -0700 (PDT)
Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AE6129551 for <idr@ietf.org>; Sat, 22 Oct 2016 03:57:55 -0700 (PDT)
X-Footer: aTNkLm5s
Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for idr@ietf.org; Sat, 22 Oct 2016 12:57:50 +0200
References: <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <20161020215938.GE1074@Vurt.local> <adb00bcd7b8e45db857eae7019c646fc@XCH-ALN-014.cisco.com> <ae5da282-201c-f745-9f26-67ce73826bd5@i3d.net> <CA+b+ERkV2PBtzzx=uoygDzvTyJzunROCNX=0Y4phvGdn=oK5Xw@mail.gmail.com> <20161021154958.GR27221@gir.theapt.org> <CA+b+ERmrzCtFLP98D0YzRc-BJNbBWp3Ce6yKZr2cg1_QS0Oz5w@mail.gmail.com> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <CA+b+ERn6dG+R8+UV-jaRXAV7eWQBygqEQp4VY4x1yKukpVKhTA@mail.gmail.com> <20161021164241.GC32387@Vurt.local> <CA+b+ERkAJDFPwmiNr7_UiaKfRQnt=8h9d9JM6B4oFgU_P1S1cQ@mail.gmail.com> <711ba725-7304-5122-cfb2-2a40c2d76ca9@i3d.net> <CA+b+ERmrEtSYTc2PN8fu3VogbMPK7yQR_GM3yJwuFF-zeO0u0Q@mail.gmail.com> <c3fc9f46-fb66-76a0-0efd-9669207729b9@i3d.net> <CA+b+ERnbUxrY6hgocQNBxL9PppuGMcf4f1Zzhu0P-ekj1R0GyQ@mail.gmail.com>
Cc: idr wg <idr@ietf.org>
From: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Organization: i3D.net
Message-ID: <fb9ebe1b-fb78-b21f-e23c-4fd99a328a0f@i3d.net>
Date: Sat, 22 Oct 2016 12:57:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CA+b+ERnbUxrY6hgocQNBxL9PppuGMcf4f1Zzhu0P-ekj1R0GyQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------33CAEA60E5474577E6C18FE7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dfzU7g4ebsZ0d9ka3xak0r5Fh2s>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 22 Oct 2016 10:57:57 -0000

Hi Robert,

I completely agree that one should be able to filter LC's, but please
treat that filtering the way RFC1997 already does today and leave the
policy of what (not) to filter up to the operators instead of trying to
hard-code policy into the protocol. That is what I said, nothing more,
nothing less.

Brian has provided an excellent answer to your question, so please
consider this as my +1 for his message.

Best regards,
Martijn

On 10/21/2016 09:51 PM, Robert Raszuk wrote:
>
>     Please let operators worry about their own filtering policies (or
>     lack thereof) and leave such recommendations to the BCP/GROW document.
>
> ‚ÄčThis is IETF WG and I find such comment inappropriate. This
> discussion is about extending BGP protocol and we all should be
> worried how to apply effective policy on something which is being
> defined here. 
>
> So triggered by the above let me ask a very simple question. You and
> others expressed very clearly that LCs should traverse N-ASes and be
> executed somewhere remotely. Great.
>
> Let's also assume that you talk to everyone in the path and convince
> them to let your LC go through. 
>
> Question: 
>
> If you choose to inject LC in the format TARGET_ASN:ACTION:PARAMETER
> based on what field is anyone in the BGP propagation path supposed to
> let's your LCs go and stop all other 1000s of LCs injected by anyone
> else ? 
>
> Today RFC1997 don't go far as they have no way to apply per their
> originator permit or deny statements. 
>
> Thx,
> R.