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> Fri, 21 October 2016 18:01 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 08872129470 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 11:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lndno8X1qVSa for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 11:01:47 -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 96B87127058 for <idr@ietf.org>; Fri, 21 Oct 2016 11:01:45 -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; Fri, 21 Oct 2016 20:01:40 +0200
To: idr@ietf.org
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>
From: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Message-ID: <711ba725-7304-5122-cfb2-2a40c2d76ca9@i3d.net>
Date: Fri, 21 Oct 2016 20:01:25 +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+ERkAJDFPwmiNr7_UiaKfRQnt=8h9d9JM6B4oFgU_P1S1cQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------B7C30382FEC6680A8D48940D"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/DMq8kpoJp6GHKEZUIvpCzvUBkpE>
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: Fri, 21 Oct 2016 18:01:54 -0000

Hi Robert,

Briefly continuing the earlier discussion for originating routers - stub
networks which exclusively receive a default route from my full table
router don't have complete AS_PATH information. That means the device
won't be able to determine whether or not the configured GA field
corresponds to an ASN in the DFZ.

If we decide (on a protocol level) to filter the LC information on the
receiving LC-speaking BGP router instead of the originating router you'd
limit the transitivity and therefore the usefulness of the Large
Community feature. Let's say that AS65500 wants to send a community via
AS49544 to AS2914. Upon receipt of the BGP_UPDATE, the AS49544 router
will check the Large Community attribute and notice that 2914:x:y is
attached while AS2914 is not in the AS_PATH. It would then have to strip
the Large Community and AS2914 would never receive the Large Community
attribute.

Simply stating that "implementations MUST allow the operator to specify
any value for the Global Administrator field" is the correct way
forward, the suggested SHOULD wording either can't be enforced by
vendor-side checks (and therefore belongs in a BCP/GROW document), or is
- in the way you've suggested it - in direct conflict with the intended
use of the Global Administrator field.

Best regards,
Martijn

On 10/21/2016 06:49 PM, Robert Raszuk wrote:

> Hey Job,
>
> That's what I thought ... but if so I do not get why there are so many
> discussions of any MUSTs/SHOULDs/MAYs operators are expected to follow
> on in the fields LCs provides. 
>
> If they are opaque that means there is zero structure in place and
> everyone is free to put whatever he/she likes in it .. even hex
> encoded Morse (https://goo.gl/rHcGeV)
>
> We either allow all opaque and free style or we structure fields such
> that for example they may be used in simple parametrized BGP in/out
> policy example I provided. 
>
> And the excuses type "oh we can not structure it as there is no way to
> insert valid ASN" are wrong as there is a way as proven :)
>
> Cheers,
> R.
>
>
>
> On Fri, Oct 21, 2016 at 6:42 PM, Job Snijders <job@instituut.net
> <mailto:job@instituut.net>> wrote:
>
>     On Fri, Oct 21, 2016 at 06:29:46PM +0200, Robert Raszuk wrote:
>     > The policy example was nothing to do with BGP table. If I am
>     receiving
>     > BGP_UPDATE it comes with AS_PATH and may contain LC. So if I
>     want very
>     > simple policy to filter trash of LCs I can set it to match first 4
>     > octets to any ASN present in the same UPDATE MSG AS_PATH
>     attribute. If
>     > it there I do not drop LC.
>
>     A clever trick, but not a good fit for Large BGP Communities.
>     Large BGP
>     Communities are opaque, by definition and design.
>
>     We want routing policy in which networks can send 2914:X:Y to us,
>     and we
>     can send 2914:A:B to them - very much like RFC 1997 communities. The
>     Global Administator field does not necessarily contain the ASN of the
>     sending party.
>
>     Kind regards,
>
>     Job
>
>     _______________________________________________
>     Idr mailing list
>     Idr@ietf.org <mailto:Idr@ietf.org>
>     https://www.ietf.org/mailman/listinfo/idr
>     <https://www.ietf.org/mailman/listinfo/idr>
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr