Re: [Idr] Request to adopt draft-heitz-idr-large-community
"Jakob Heitz (jheitz)" <jheitz@cisco.com> Wed, 07 September 2016 22:39 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 E328212B049 for <idr@ietfa.amsl.com>; Wed, 7 Sep 2016 15:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.028
X-Spam-Level:
X-Spam-Status: No, score=-16.028 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 ztmd1s2XRzYr for <idr@ietfa.amsl.com>; Wed, 7 Sep 2016 15:39:40 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35C812B0FB for <idr@ietf.org>; Wed, 7 Sep 2016 15:39:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14200; q=dns/txt; s=iport; t=1473287979; x=1474497579; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2N9oXsQiYjSSUZ6WUFFsqHshW6JlgPiWsZOiutc8fXc=; b=kl7gcnQoMaNf7xfHZ5bkP+7xMQL6Ys63J4UjLyXruUlO2J8D4wuoapjn Qa27PFBKTqciu7f2QiXkUBvmTwUtjHHNM+Q3+d7G9CgF4tc3itvLKLJO1 osM0NONHEU2A37bC+GzBGkdOrTaMxLF127F5cYCfxDAxa4aeo1CnCc6Zd U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DfAQBmltBX/5JdJa1dGQEBAQEBAQEBAQEBgnozAQEBAQEeVy1PjS+mBIUNggMZAQqFeAKBajgUAQIBAQEBAQEBXieEYQEBAQMBAQEBaQIIAwULAgEIGCcHJwsUEQIEDgUUiC4IDrxIAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGL4F4CIJOgSKCcBEBBoNDgi8FlAyFTQGIX4Zdj1tvi2GDegEeNoJjAh6BTXCDW4IfAQEB
X-IronPort-AV: E=Sophos;i="5.30,297,1470700800"; d="scan'208,217";a="144695948"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2016 22:39:38 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u87Mdc59019299 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Sep 2016 22:39:38 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; Wed, 7 Sep 2016 17:39:37 -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; Wed, 7 Sep 2016 17:39:37 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Idr] Request to adopt draft-heitz-idr-large-community
Thread-Index: AQHSCDP+9Gy6rPIW0USt867VcqfiL6BuXmaAgAAfcwCAAAPVgIAABqSAgAAddgD///s9xA==
Date: Wed, 07 Sep 2016 22:39:37 +0000
Message-ID: <D2565063-A1DE-4AB0-9903-65AA2805D0D3@cisco.com>
References: <20160906113919.GC17613@vurt.meerval.net> <F3BDAC77-FA01-4F90-9BC1-9F2F1B7B6029@ecix.net> <CAHxMReZxtHSHfavDaAm=JrBqQ+UHkbJoai52Zt3rFFSKgp=aLA@mail.gmail.com> <CA+b+ER=QOJXZoZaNhRhiHS2SgE88cBaxOb39eRshyA1TxnQXUg@mail.gmail.com> <20160907161113.GG5423@57.rev.meerval.net>, <CA+b+ERmfPrjbsAx42aKH_OVdZnf0WzqS_B1mJ6eTVni7T2s6xg@mail.gmail.com>
In-Reply-To: <CA+b+ERmfPrjbsAx42aKH_OVdZnf0WzqS_B1mJ6eTVni7T2s6xg@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
Content-Type: multipart/alternative; boundary="_000_D2565063A1DE4AB0990365AA2805D0D3ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/3N57GGI7LZCRLPZEZJu9TSqVkek>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] Request to adopt draft-heitz-idr-large-community
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: Wed, 07 Sep 2016 22:39:43 -0000
Here is how I would treat the first 4 octet so of the large community. The community is normally used by an ISP to allow a directly connected customer to express its wishes about how to process the route. In that case, the first four octets and all octets are totally in control of the ISP. The ISP has total control of the definition of the octets. If an ISP is willing to carry communities that are destined to another AS, then it makes sense for everyone to agree on the encoding of the target ASN in the community. I would phrase it like this: The meaning of all octets in the large community is to be defined by mutual agreement between the originating and terminating ASes. However, if a large community is intended to transit an AS, then the ASN of the terminating AS SHOULD be encoded in the first 4 octets of the large community. For example, there is no reason that an invalid ASN (say 0 or 23456) should be disallowed as long as the intended recipients of the community understand the meaning. Thanks, Jakob. On Sep 7, 2016, at 1:57 PM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote: Hi Job, Excellent. And my only point was to add that single sentence to the spec when next rev comes out. Suggestion for the sentence to add into bottom of the section 3: "The Autonomous System number used within the community field is an Autonomous System which understands the encoded meaning of the 8 octets which follow and which is to act on it." ... or something along those lines. Cheers, R. On Wed, Sep 7, 2016 at 6:11 PM, Job Snijders <job@ntt.net<mailto:job@ntt.net>> wrote: Hi Robert, On Wed, Sep 07, 2016 at 05:47:27PM +0200, Robert Raszuk wrote: > I agree with all statements made by Rob S. > > Kay's email however triggered the clarification question to the > current -03 version. > > What is the meaning of explicit AS number listed in the first 4 octets > of the community. I was under impression that originally it was the AS > number in which given community needs to be executed however it seems > that this sentence is no longer in the current version of the draft. The first 4 bytes contain the ASN in which the last 8 bytes have a meaning. Its not about what is executed where. Consider the last 8 bytes, the 'local opaque data', a namespace of sorts, the first 4 bytes indicate who owns that namespace. The owner of the namespace can publicly or privately document what the meaning communities are within his/her namespace. I welcome suggestions to improve the text on this aspect. RFC 1997 had language like "Global Administrator" and "Local Administrator" - but I think that is a somewhat archaic to explain this concept. In -04 we're talking about "Autonomous System Number" and "Local Data". > So it may be unclear if this is AS number inserting this community, if > this is target AS to execute it or perhaps like in the case of Route > Server is it AS acting as proxy for other ASes it peers with ? > > The answer could be none of the above - it's all local significant - but > then shouldn't it rather use a 4:4:4 description. What Kay described is that they today with RFC 1997 communities they are using a horrible kludge because there is not enough space. With Large communities, ECIX (AS 9033) could say "Dear customers, if you attach 9033:XXX:YYY to your prefix, our routeserver will do A", where XXX and YYY are values decided by ECIX. This way, there will never be collisions. What XXX and YYY are is up to ECIX, XXX could be the ASN of a peer on the route server, YYY could be an identifier which triggers an action, such as no-export. Given the above context and what Kay sent to the list: > > As we use 65000:XXX, where XXX is the ASN which should >> not receive the route, this proposal would give us the option to also >> extend the control-mechanisms towards 32-bit ASNs and not just 16-bit >> ASNs anymore. With Large Communities, the above example could be turned into: 9033:65000:XXX, where XXX is the ASN which should not receive the route. Suddenly they aren't overloading a Global Administrator field with a private ASN! :-) ECIX (and other Route Server operators) gain two advantages: There won't be a risk of collision because its in their own namespace, (in ECIX's case '9033'), and XXX can be a 4-byte value, meaning they can target 4-byte ASNs, which is something they cannot do today but clearly want to do for consistency. It is important to recognise that it is up to ECIX to decide how they use the 8 bytes of data available to them. They can put ASNs in there directly, or use a mapping table, or throw a dice and just publish which value means what on their Route Server. It is entirely opaque. Kind regards, Job ps. Large Communities' expiry date will be the moment the IETF starts working on 8-byte ASNs. If that ever happens, we'll hopefully remember this thread. _______________________________________________ Idr mailing list Idr@ietf.org<mailto:Idr@ietf.org> https://www.ietf.org/mailman/listinfo/idr
- [Idr] Request to adopt draft-heitz-idr-large-comm… Job Snijders
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Nick Hilliard
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Jared Mauch
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Van De Velde, Gunter (Nokia - BE)
- Re: [Idr] Request to adopt draft-heitz-idr-large-… marco
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Eduardo Ascenço Reis
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Mark Schouten
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Paul Hoogsteder
- Re: [Idr] Request to adopt draft-heitz-idr-large-… i3D.net - Martijn Schmidt
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Greg Hankins
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Acee Lindem (acee)
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Bertrand Duvivier (bduvivie)
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Barry O'Donovan
- Re: [Idr] Request to adopt draft-heitz-idr-large-… heasley
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Grzegorz Janoszka
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Linda Dunbar
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Marco Davids (IETF IMAP)
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Gaurab Raj Upadhaya
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Teun Vink
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Jeff Tantsura
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Theodore Baschak
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Pier Carlo Chiodi
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Nabeel Cocker
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Dickinson, Ian
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Jan Baggen
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Dunc
- Re: [Idr] Request to adopt draft-heitz-idr-large-… David Farmer
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Job Snijders
- [Idr] Moderating "+1" messages John G. Scudder
- Re: [Idr] Request to adopt draft-heitz-idr-large-… David Farmer
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Randy Bush
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Jakob Heitz (jheitz)
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Henderickx, Wim (Nokia - BE)
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Kay Rechthien
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Stefan Plug
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Rob Shakir
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Robert Raszuk
- Re: [Idr] Request to adopt draft-heitz-idr-large-… heasley
- Re: [Idr] Request to adopt draft-heitz-idr-large-… David Farmer
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Job Snijders
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Adam Davenport
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Robert Raszuk
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Warren Kumari
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Gert Doering
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Thomas King
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Jakob Heitz (jheitz)
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Robert Raszuk
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Jakob Heitz (jheitz)
- Re: [Idr] Request to adopt draft-heitz-idr-large-… bruno.decraene
- Re: [Idr] Request to adopt draft-heitz-idr-large-… bruno.decraene
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Jakob Heitz (jheitz)
- Re: [Idr] Request to adopt draft-heitz-idr-large-… bruno.decraene
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Jakob Heitz (jheitz)
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Mikael Abrahamsson
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Wesley Steehouwer
- Re: [Idr] Request to adopt draft-heitz-idr-large-… brad dreisbach
- Re: [Idr] Request to adopt draft-heitz-idr-large-… niels
- Re: [Idr] Request to adopt draft-heitz-idr-large-… John G. Scudder
- Re: [Idr] Request to adopt draft-heitz-idr-large-… Tom Daly