Re: [Idr] Request to adopt draft-heitz-idr-large-community

Job Snijders <job@ntt.net> Wed, 07 September 2016 16:11 UTC

Return-Path: <job@ntt.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 5FB2512B37D for <idr@ietfa.amsl.com>; Wed, 7 Sep 2016 09:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.443
X-Spam-Level:
X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_SOFTFAIL=0.665] 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 SlPvWeifLDve for <idr@ietfa.amsl.com>; Wed, 7 Sep 2016 09:11:18 -0700 (PDT)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F10012B37A for <idr@ietf.org>; Wed, 7 Sep 2016 09:11:18 -0700 (PDT)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1bhfRU-0007LO-0X (job@us.ntt.net); Wed, 07 Sep 2016 16:11:16 +0000
Date: Wed, 07 Sep 2016 18:11:13 +0200
From: Job Snijders <job@ntt.net>
To: Robert Raszuk <robert@raszuk.net>
Message-ID: <20160907161113.GG5423@57.rev.meerval.net>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+b+ER=QOJXZoZaNhRhiHS2SgE88cBaxOb39eRshyA1TxnQXUg@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.0 (2016-08-17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/C6FuH6pIcYXMtUgOGsbYctIuSqI>
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 16:11:20 -0000

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.