Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Thu, 13 October 2016 23:22 UTC

Return-Path: <jheitz@cisco.com>
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 CF5FE129471 for <idr@ietfa.amsl.com>; Thu, 13 Oct 2016 16:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.517
X-Spam-Level:
X-Spam-Status: No, score=-17.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 gSXE4eb93boQ for <idr@ietfa.amsl.com>; Thu, 13 Oct 2016 16:22:02 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D7C124281 for <idr@ietf.org>; Thu, 13 Oct 2016 16:22:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2485; q=dns/txt; s=iport; t=1476400922; x=1477610522; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e+mKcHf7ExFBV/7o9lHdvieo01mvyft86toogQHn14E=; b=Dz+dReOznl/F4nGEfUJbETxNNf7Fb3eK5xXXnvrzFPplBFAvdBA/7zHX /tAsJ/ErE80ThPCKptqvhQGtuquJbGwVnXoUqgA85LoyqbVHhl93HAQBC EcMOZIfRzGYXF2uNx0hK9+56AmVua5bLSEsTuHN3FJzTxD+6i+9yVlV5N 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ByAQBAFgBY/4YNJK1cGgEBAQECAQEBAQgBAQEBgzwBAQEBAR2BUweNLZcFlDSCCIYiAoIMOBQBAgEBAQEBAQFeJ4RhAQEBBDoyCgMMBAIBCBUBIAkHMhQRAgQBDQUIDIg+w2EBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhj2EVYomBZoCAY91gXWEZ4kgjHmDfgEeNlCEZHKHBIEAAQEB
X-IronPort-AV: E=Sophos;i="5.31,490,1473120000"; d="scan'208";a="333638410"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Oct 2016 23:22:01 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u9DNM1MJ005092 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Oct 2016 23:22:01 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 13 Oct 2016 18:22:00 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 13 Oct 2016 18:22:00 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: "t.petch" <ietfc@btconnect.com>, Julian Seifert <js@dacor.de>, Peter Hessler <phessler@theapt.org>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt
Thread-Index: AQHSG79TGAvzbRTYaUOLNdatGR0q+6CTny8AgALbUg+AAFuDAP//w9BUgABdGYCAAD/ogIAFnPnpgABp4oCAAKSCAIABPgaAgAA9LACAAJUrsoABNP8AgAHlkWKAAFoQgIACgayAgAA/PvOAAOqp8A==
Date: Thu, 13 Oct 2016 23:22:00 +0000
Message-ID: <370dd06bff7c425db78dc82c5bce8907@XCH-ALN-014.cisco.com>
References: <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <00da01d22085$4f0f2ee0$4001a8c0@gateway.2wire.net> <57F78B7D.609@foobar.org> <333030E6-0422-4A34-B07B-90D5F8E9F116@gmail.com> <57F92043.20301@foobar.org> <A9BBA442-361F-444F-9AFC-33FAAF5F6061@gmail.com> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net>, <20161011095417.GL19434@gir.theapt.org> <1476317462333.82977@dacor.de> <00fb01d2252f$700c2360$4001a8c0@gateway.2wire.net>
In-Reply-To: <00fb01d2252f$700c2360$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.162.215]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9n9pnCKBS8cWPTPIYY9yDd8rV1k>
Cc: idr <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt
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: Thu, 13 Oct 2016 23:22:04 -0000

Tom

I understand your issue and I believe every major router vendor
does too.

What to do about it?

The router cannot check if the first word is a valid ASN
or if the ASN is the intended one. Even if the ASN is correct,
The rest of the community could still be junk.

A router vendor can provide tools to make it easier
for operators to be safe with communities, large or regular.

For example, there is a knob 'send-community' that must be
configured before a router will send communities on an ebgp
session. Therefore, an operator who is unaware of the problem
will not spray junk. Another tool is the 'peeras' keyword
that allows you to match the peer's ASN in any field of
the community. This makes it easier to write generic filters
in RPL. Excuse me if I'm tooting my own horn, but I do not
believe that this funcionality is unique to Cisco.
You can match private ASN and your own ASN too.

If anyone can suggest more tools, please do.

Thanks,
Jakob.


> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch
> Sent: Thursday, October 13, 2016 1:55 AM
> Julian
> 
> I believe I understand the need that you express but the BGP protocol
> does not have the mechanics to express it!
> 
> You say
> 'configure with meaning only for me and parties I interact with'
> but BGP has no such mechanism. As Jeff has already explained, an
> optional attribute either gets dropped, which is unlikely to work with
> route reflectors, or it gets passed on and this I-D chooses the option
> that it gets passed on.  So a community that only you and your fellow
> parties understand is let loose on the whole Internet where it is open
> to misinterpretation by everyone else because, e.g., they are expecting
> an ASN and are getting something else that is private to you.
> 
> And the remit of the IETF is to make the Internet as a whole work better
> so in updating the specification of BGP, the IETF has to consider the
> trade off of something that benefits you and the parties you interact
> with versus the risk of causing some level of damage to the Internet.
> 
> Obviously, I hope, I am concerned about the damage; you gain, but
> somewhere else across the globe, someone else's connectivity may fail.
> 
> Of course it is possible to define a more sophisticated system that
> allows communities to go so far and no further but that is not the BGP
> we have.
> 
> Tom Petch