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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Mon, 03 October 2016 21:30 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 663E812957D for <idr@ietfa.amsl.com>; Mon, 3 Oct 2016 14:30:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, 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 txhlPDi2xnkS for <idr@ietfa.amsl.com>; Mon, 3 Oct 2016 14:30:38 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2507F129566 for <idr@ietf.org>; Mon, 3 Oct 2016 14:30:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18986; q=dns/txt; s=iport; t=1475530238; x=1476739838; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N1hEgAi9kyRe5duSrZZIEn8VzmPPqLgMFKDL+3rJL8s=; b=ggVjqckB9VLM+zPYLCOkVhfsteIEl/JOCSOUxBIY90AujzDFZ+MuDIVT WBabTk2B8oo1filYnph4NVhPH8s2mIu5tiB41JxMXf9Gt9LjOIyW0UdrD RgB/o28H25l2owSw7hYPrhdSKNbcI8JCdw/qndwlewl5Tq9V8VnW9sBkh c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C4AQBAzfJX/5xdJa1eGgEBAQECAQEBAQgBAQEBgwc2AQEBAQEeV3wHjSuXAIdYhzmFEoIGhh4CHIFPOBQBAgEBAQEBAQFeJ4RhAQEBAwEjCkwFCwIBCBEEAQEBJwMCAgIfERQJCAIEAQ0FCAyIHwMPCK8siRANg1kBAQEBAQEBAQEBAQEBAQEBAQEBAQEchjiEVYJHgjOCToJaBYkZiweFIzUBjHCCeYF1hGaHcYEtiF2EEYN9AR42hQxyAYYUAX8BAQE
X-IronPort-AV: E=Sophos;i="5.31,291,1473120000"; d="scan'208,217";a="331329579"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2016 21:30:37 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u93LUaCU012616 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Oct 2016 21:30:36 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Oct 2016 16:30:35 -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; Mon, 3 Oct 2016 16:30:36 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>, heasley <heas@shrubbery.net>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt
Thread-Index: AQHSG79TGAvzbRTYaUOLNdatGR0q+6CTny8AgALbUg+AAFuDAP//w9BUgABdGYCAAD/ogP//s3BtgABU8wD//7aMOwAKnNYA//+wcOWAAGzyAIAALZQAgABSerA=
Date: Mon, 03 Oct 2016 21:30:36 +0000
Message-ID: <b5de6ce139174bc8a4efbd64c9e0be03@XCH-ALN-014.cisco.com>
References: <005b01d21d58$aaf869e0$4001a8c0@gateway.2wire.net> <20161003095936.GC20697@Vurt.local> <04cf01d21d68$52c656a0$4001a8c0@gateway.2wire.net> <20161003115723.GD20697@Vurt.local> <57F27D3F.7090404@foobar.org> <74D0D4D0-0885-4E11-BDAB-85F9356B4AA1@cisco.com> <20161003161608.GG3127@Vurt.local> <D5115E3C-371A-4397-B8EB-090CE6B5A4F1@cisco.com> <20161003165706.GM20697@Vurt.local> <9C759C3F-0571-45C7-ADB2-618A6A0D78D1@cisco.com> <20161003184216.GU74863@shrubbery.net> <CAH1iCiq-TEdp2hQjb8ZA9sMO+QLotCq4oSeun6ckBchuXVK97w@mail.gmail.com>
In-Reply-To: <CAH1iCiq-TEdp2hQjb8ZA9sMO+QLotCq4oSeun6ckBchuXVK97w@mail.gmail.com>
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: [128.107.151.58]
Content-Type: multipart/alternative; boundary="_000_b5de6ce139174bc8a4efbd64c9e0be03XCHALN014ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/AvUj4m3Xun-4ODkP2NSkEjd9L_E>
Cc: "idr@ietf.org" <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: Mon, 03 Oct 2016 21:30:40 -0000

Fine. It's not that important anyway.

Thanks,
Jakob.

From: Brian Dickson [mailto:brian.peter.dickson@gmail.com]
Sent: Monday, October 03, 2016 2:25 PM
To: heasley <heas@shrubbery.net>
Cc: Jakob Heitz (jheitz) <jheitz@cisco.com>; idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt


On Mon, Oct 3, 2016 at 11:42 AM, heasley <heas@shrubbery.net<mailto:heas@shrubbery.net>> wrote:
Mon, Oct 03, 2016 at 05:12:20PM +0000, Jakob Heitz (jheitz):
> An implementation may give you a match condition for reserved range. I haven't (yet). Private AS has 2 ranges. The match for that is still on my todo list. If it were one range, then it would be done.
>
> One range please.

they aren't arbitrary ranges - they are the reserved ASNs.  Why is it
difficult to match if (field1 == (0|0xffff|0xffffffff))?

> Thanks,
> Jakob.
>
> > On Oct 3, 2016, at 9:57 AM, Job Snijders <job@ntt.net<mailto:job@ntt.net>> wrote:
> >
> >> On Mon, Oct 03, 2016 at 04:53:14PM +0000, Jakob Heitz (jheitz) wrote:
> >> I write code. I watch people write code and test code. It adds to
> >> development time. 3 ranges is not necessary. It's messy.

The problem with *not* reserving all 3 is this: there may be, in future, a new set of "Well-Known Large Communities".

The (best or feasible) choice(s) of WHICH of the 3 reserved values should get used as the range containing WKLCs (and here I presume one of the three MUST be the place for WKLCs), could depend on some number of factors not known to us at this time.

If we attempt to make that decision now, based on zero information about possible unseen consequences, our future selves (or our successors) might be very unhappy.

Reserving all 3 (but not requiring any action on those reservations, per se) costs nothing, and leaves all 3 open for future use as WKLCs.

Reserving all 3 does, however, warn off operators from using any of those, so they don't get some later surprise when an implementation starts interpreting WKLCs that happen to conflict with what the operator has been using.

It is anticipatory principal of least astonishment.


> > As an implementor, you are not supposed to do anything with these
> > ranges0. They are just reserved in the sense that they belong to IANA,
> > not to a single operator. For the moment, operators should avoid using
> > values from these ranges, but implementations shouldn't prohibit them
> > from doing so.
> >
> > This is no different than RFC1997 which reserves the following two:
> >
> >    0x00000000 - 0x0000FFFF
> >    0xFFFF0000 - 0xFFFFFFFF
> >
> > Can you elaborate on whether IOS XR treats RFC1997 values from those
> > ranges in a special way? (aside from the well known communities
> > of course)

I think this illustrates the problem quite well.
It may not be the case that all implementations prevent some operator from using an RFC1997 community in a non-conformist way.
But if the operator does use such a community, and unexpected (to that operator) things happen, well, "caveat emptor".

It would be nice if implementations provided warnings, or even prevented people from shooting themselves in <body part>.
It isn't strictly necessary, and as long as the RFCs provide enough warnings against doing so, that's probably enough.

ICANN/IANA only provide the regulatory frameworks for the public Internet; there are other "internets" that exist, where re-use of assigned IP addresses (outside of RFC1918) is a non-issue.
(And only so long as the networks involved do not attempt to interconnect with "the Internet".)

But, where the intent is that the first 32-bit value is "the public ASN" of the operator (and this should be the case for any Internet-announced NLRIs with this new attribute), we should warn off any "off-label" use.
E.g. advise on the "private use ASNs" available, and on the "reserved values".

That's my $0.02.

Brian