IETF Logo Mail Archive

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

Ben Maddison <benm@workonline.co.za> Tue, 11 October 2016 11:30 UTC

Return-Path: <benm@workonline.co.za>
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 30CB4129473 for <idr@ietfa.amsl.com>; Tue, 11 Oct 2016 04:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.897
X-Spam-Level:
X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, 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 FrAbdaFoad4E for <idr@ietfa.amsl.com>; Tue, 11 Oct 2016 04:30:46 -0700 (PDT)
Received: from ex1.workonline.co.za (ex1.workonline.co.za [197.157.92.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A401294AC for <idr@ietf.org>; Tue, 11 Oct 2016 04:30:39 -0700 (PDT)
Received: from EX2.workonline.co.za ([fe80::8572:d946:2c81:17bb]) by ex1.workonline.co.za ([fe80::f84f:93b7:a923:f286%14]) with mapi id 14.02.0387.000; Tue, 11 Oct 2016 13:30:35 +0200
From: Ben Maddison <benm@workonline.co.za>
To: Nick Hilliard <nick@foobar.org>, "t.petch" <ietfc@btconnect.com>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt
Thread-Index: AQHSG79f4gLPfLBG50exCsj8QwL4bKCTKdYAgANQzs3//+YHAIAAOUPw///npoCAAD/ogIAGEmvK///0cYAAFJAmAAAnwL+AAAelkQAAIVOd/gAX8aMAAEtfbkr///m3AP//3YuQ
Date: Tue, 11 Oct 2016 11:30:34 +0000
Message-ID: <874E439F335FD742B8D1565730E537E0011C10EA21@ex2.workonline.co.za>
References: <147531113077.4216.12599976309263776317.idtracker@ietfa.amsl.com> <20161001085434.GW20697@Vurt.local> <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <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> <57FCC876.5090109@foobar.org>
In-Reply-To: <57FCC876.5090109@foobar.org>
Accept-Language: en-ZA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2c0f:fa90:2000:204:8567:ee20:86a4:b5a3]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RmJgF8V9oWP2Pjyvy-Jmj87wYH0>
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: Tue, 11 Oct 2016 11:30:49 -0000

Hi all,

I'm rather struggling to see the point of this debate. There is a thing about ducks that comes to mind ("if it walks like an ASN...").

Surely what we're really concerned with is on the receiving/interpreting end, where (in the inter-AS scenario) the authority responsible of assigning meaning to a large-comm of the form 64500:X:Y is expected to be the operator of AS64500.

This is already clear to me from section 2:
	"The Global Administrator field is intended to allow different
   	Autonomous Systems to define Large Communities without collision"

Nick is entirely correct that this intention is not enforceable in any meaningful way, so I really don't think it is worth spending additional time and energy defining it more narrowly.

Cheers,

Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office:     +27 (0) 21 200 9000
Mobile:   +27 (0) 82 415 5545
Email:      benm@workonline.co.za
SIP:          benm@workonline.co.za




-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Nick Hilliard
Sent: Tuesday, October 11, 2016 1:10 PM
To: t.petch <ietfc@btconnect.com>
Cc: idr <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

t.petch wrote:
> I want a MUST in there so if anyone does otherwise, we can say No!, 
> not allowed.

If an operator in the far depths of inner Kaboodlestan uses an IPv4 address instead of an ASN, the IETF can disapprove all it wants, and it will make no difference to anyone.

For inter-as signaling, no-one is going to accept anything other than an ASN, but even if they do, it doesn't matter that much.  Communities are not redistributed by default on ebgp sessions, and when they are, the normal operation is to strip off anything not related to the next-hop ASN.  So in practice, the distribution radius for most communities mappings tends to be quite small.

Nick

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email