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 17:03 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 7563F129522 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 10:03:46 -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 v-CxuoHWLum6 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 10:03:44 -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 63B1312944D for <idr@ietf.org>; Fri, 21 Oct 2016 10:03:43 -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)); Fri, 21 Oct 2016 19:03:37 +0200
To: Robert Raszuk <robert@raszuk.net>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <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>
From: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Message-ID: <caa5e4f9-7cc0-b9f2-d48b-17189e263717@i3d.net>
Date: Fri, 21 Oct 2016 19:03:22 +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+ERn6dG+R8+UV-jaRXAV7eWQBygqEQp4VY4x1yKukpVKhTA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------66B14E4A2CFEC51A753F2932"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/IUPdmw-KfCW2U_-GA1s-MsPZpIY>
Cc: IETF IDR WG <idr@ietf.org>, Peter Hessler <phessler@theapt.org>
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 17:03:46 -0000

Hey Robert,

I see that you stated the first field would be filled in automatically
by the "local-as" value defined in your BGP config. That means we'll be
back to two user-customizable fields, so action communities sent between
ASN's are effectively going to collide again and we're back to the same
old RFC1997 problem. It's not an option.

I'll get back to the other part of your message in a minute, so I can
include the discussion you've already had with Job.

Best regards,
Martijn


On 10/21/2016 06:29 PM, Robert Raszuk wrote:
> Martijn,
>
> > I think you're missing the point.
>
> I don't think it's me :)
>
> > Peter already explained that not every ASN we're trying to signal is
> necessarily a direct neighbor. 
>
> I never made any such assumption. 
>
> > So you've suggested to take a look at the BGP table instead to see if
> the ASN appears in any AS_PATH which is in the table. 
>
>
> Nope ... not at all. 
>
> 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. 
>
> For stub ASes we could treat their AS_NUMBERS in LCs exactly in the
> same way we treat them in AS_PATH today. 
>
> Cheers,
> R.
>
>
>
>
>
> On Fri, Oct 21, 2016 at 6:21 PM, i3D.net - Martijn Schmidt
> <martijnschmidt@i3d.net <mailto:martijnschmidt@i3d.net>> wrote:
>
>     Hi Robert,
>
>     I think you're missing the point. Peter already explained that not
>     every ASN we're trying to signal is necessarily a direct neighbor.
>     So you've suggested to take a look at the BGP table instead to see
>     if the ASN appears in any AS_PATH which is in the table. But many
>     routers participating in the DFZ don't carry a full table, only a
>     default route, so that information is not available to them.
>     Nevertheless operators of those default-only networks frequently
>     send communities to their upstream for inbound routing
>     manipulation (prepends, localpref, RTBH, etc) to achieve a variety
>     of goals; your suggestion would severely limit the draft's usefulness.
>
>     Summarizing, any restrictions which can not be enforced don't
>     belong in the IDR document because they're irrelevant to
>     implementors. Arguing about it doesn't change the fact that such
>     recommendations belong in a BCP/GROW document. It is that simple.
>
>     Best regards,
>     Martijn
>
>
>     On 10/21/2016 06:03 PM, Robert Raszuk wrote:
>>     Peter,
>>
>>     Who you control (who is the target of LC - can be expressed in
>>     the second 4 octets). And as such at least original discussions
>>     were about it. 
>>
>>     So if you inject a large community it would have format:
>>     SRC_ASN:DST_ASN:ACTION
>>
>>     In your specific case it would be: 1234:5678:ACTION
>>
>>     The comment was made that there is no way for implementation to
>>     insert valid SRC_ASN .. well it clearly is.
>>
>>     But I am not suggesting spec should enforce it as it does limit
>>     use cases for LC by not allowing to overload first 4 octets. On
>>     the other hand it does provide more responsibility to whoever is
>>     injecting LCs so does improve on BGP clarity and stability from
>>     protocol point of view.
>>
>>     Fixing on meaning on first 4 octets also provides very good tool
>>     to policy filtering rules as you know what to expect there. For
>>     example you may have policy allowing to pass any LC where first 4
>>     octets contain any ASN also listed in your AS_PATH - otherwise
>>     drop it. That may effectively help to support LC global
>>     deployment much easier including the N-hops away destinations. 
>>
>>     Thx,
>>     r.
>>
>>
>>     On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler
>>     <phessler@theapt.org <mailto:phessler@theapt.org>> wrote:
>>
>>         On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk
>>         wrote:
>>         :Hi Martijn,
>>         :
>>         :> Secondly, there's literally no way for the vendor to check
>>         whether an
>>         :> ASN belongs to "the entity that defines the meaning of the
>>         rest of the
>>         :> Large Community"
>>         :
>>         :Why not ?
>>         :
>>         :If you do not make those 4 octets configurable by spec and
>>         always fill it
>>         :with AS number defined in your BGP instance you will have
>>         assurance it
>>         :is ASN of the entity that defines the rest 8 octets of the
>>         LC as otherwise
>>         :you will likely not establish any EBGP sessions to your peers.
>>         :
>>         :So there is very easy way to enforce it today in any BGP
>>         implementation.
>>
>>         Say I am AS 1234, and I want to control AS 5678.  My transit
>>         ISP is AS
>>         9876.
>>
>>         If I set
>>
>>         local-as 1234
>>         peer-as 9876
>>         set large-community 5678:666:1
>>
>>         How is the implementation supposed to know to allow it?
>>
>>         Limitations in the implementation completely defeat the
>>         purpose of this
>>         spec.
>>
>>
>>         :However the question is should it be enforced at all ?
>>         :
>>
>>         MUST NOT is a very important part of this spec, and is
>>         enforced a few
>>         times in the document.
>>
>>
>>         :Best,
>>         :R.
>>         :
>>
>>
>>
>>
>>         --
>>         The moving cursor writes, and having written, blinks on.
>>
>>
>>
>>
>>     _______________________________________________
>>     Idr mailing list
>>     Idr@ietf.org <mailto:Idr@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/idr
>>     <https://www.ietf.org/mailman/listinfo/idr>
>     -- 
>     Met vriendelijke groet / Kindest regards, Martijn Schmidt
>     i3D.net performance hosting 	
>     *Martijn Schmidt | Network Architect* Email:
>     martijnschmidt@i3d.net <mailto://martijnschmidt@i3d.net> | Tel:
>     +31 10 8900070 <tel:%2B31%2010%208900070> *i3D.net B.V. | Global
>     Backbone AS49544* Van Nelleweg 1, 3044 BC Rotterdam, The
>     Netherlands VAT: NL 8202.63.886.B01 Website
>     <http://www.i3d.net/?utm_source=emailsignature&utm_medium=email&utm_campaign=home>
>     | Case Studies
>     <http://www.i3d.net/partners/?utm_source=emailsignature&utm_medium=email&utm_campaign=case-studies>
>     | LinkedIn <https://www.linkedin.com/company/i3d-net>
>     	
>
>     _______________________________________________ Idr mailing list
>     Idr@ietf.org <mailto:Idr@ietf.org>
>     https://www.ietf.org/mailman/listinfo/idr
>     <https://www.ietf.org/mailman/listinfo/idr> 
>