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 16:21 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 3F23012965F for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 09:21:56 -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 5mllSjAecAq5 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 09:21:53 -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 88B991297CD for <idr@ietf.org>; Fri, 21 Oct 2016 09:21:51 -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 18:21:47 +0200
To: Robert Raszuk <robert@raszuk.net>, Peter Hessler <phessler@theapt.org>
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>
From: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Organization: i3D.net
Message-ID: <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net>
Date: Fri, 21 Oct 2016 18:21:48 +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+ERmrzCtFLP98D0YzRc-BJNbBWp3Ce6yKZr2cg1_QS0Oz5w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------4EB5B720F67DE0BFB6E17689"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kNWBKqRpTxMEyOgheOzu5PjDJFM>
Cc: IETF IDR WG <idr@ietf.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 16:21:56 -0000

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
> 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

*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>