Re: [Idr] Question about BGP Large Communities

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 05 February 2020 01:43 UTC

Return-Path: <brian.peter.dickson@gmail.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 013291200E7; Tue, 4 Feb 2020 17:43:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 R20j8jtOHewT; Tue, 4 Feb 2020 17:43:18 -0800 (PST)
Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E9A12006E; Tue, 4 Feb 2020 17:43:17 -0800 (PST)
Received: by mail-ua1-x935.google.com with SMTP id y3so273252uae.3; Tue, 04 Feb 2020 17:43:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=afpvOZkNeu5eMwkryo4b6KYw1VzAJKEek0W5yctJGsk=; b=O5PMXagRIhMqvNp5sjIbfpx/tBdfIDjdDkkERiE613yTJcjxip0pOLLu1nBgT3brr0 Cfq6ZVvsKCpIdc0WJO1bAvh0365qYYvdLppBBEnWfjUnc8PzwS2wxxU8NI6tj6+OCzQ7 mIv+5W6XWu4wX9htUcmG3OFYVBFbkcbDeEPUWuAnOXKwEwesURNEvMnPaZIvewqFu2xe yzUyARFH/mopGkYi6zVqxETF5LA4ZATVRtLIweBA09xM4evotP7Gr7u0q9G0sFPElMOt 5iVDNBTZDRSE/1njugGIeLdkVxVwTweaFutN91FvcpvDZG9iRwdXFS+dFseuJ1W+J8ll 9p9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=afpvOZkNeu5eMwkryo4b6KYw1VzAJKEek0W5yctJGsk=; b=XD0PymXrnBcAPmKkOO6ufw0/x5NrAvFNZwghUuyXX/ClY4QTObymyxJ1pWZETiw4gv zIbCs7KE43BOpZqa0Dfb7DNbXcXQuQ2kqDuAcRgEDHEO1pTSvqztz7Xz2zLQ158YaEGr I41PIQ7IZ9SUGuj7VJ9MUCA935txYcGkEWsDprPwsiZa6oAnRgE27c6ifqePaf8wwqlf RCsR+F4SUivLvW64/b+xFCboKa2NauJZBpEETzJ4aJk98ETsw+Zlmvo33O9S2e936bgo I1omGnQol7aIasj0yECWq28taUd+JzojkaadsLd5VmYtqzmjlM6eVqyHIQRxU5ker48C 1wsw==
X-Gm-Message-State: APjAAAXC+7evyxh6T7Z5dJBgmNQx1ZlMaZyyIy6zJuZv7EAn7KroNpV9 8fXNIEsY9JGciPUHwfE+f5ECcQj/4Zg5RWiwoe8=
X-Google-Smtp-Source: APXvYqyxP25FR78tfiYP7Ugf4NbRPm3nJHqjBuxpthzHfwy9bjQO1B4Mnm7wNGi3X4aZdLOTdud2cevtUFcWyUQ7l9k=
X-Received: by 2002:ab0:634c:: with SMTP id f12mr19074905uap.48.1580866996778; Tue, 04 Feb 2020 17:43:16 -0800 (PST)
MIME-Version: 1.0
References: <DM6PR09MB54489301E52DD711E031400984030@DM6PR09MB5448.namprd09.prod.outlook.com> <BN6PR11MB1890AA431F63030DFE310902C0030@BN6PR11MB1890.namprd11.prod.outlook.com> <20200204225458.GB57481@shrubbery.net> <DM6PR09MB544817A892B1F331E972DF9384020@DM6PR09MB5448.namprd09.prod.outlook.com>
In-Reply-To: <DM6PR09MB544817A892B1F331E972DF9384020@DM6PR09MB5448.namprd09.prod.outlook.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 4 Feb 2020 17:43:05 -0800
Message-ID: <CAH1iCioM0L5X2L3RDHE_G-G1VP5p6p0XW=5v02hjwwhOcezkzQ@mail.gmail.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
Cc: John Heasly <heas@shrubbery.net>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c7bddc059dca473b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/VByHtC2etbZwsmhHAUoVVCMd2eE>
Subject: Re: [Idr] Question about BGP Large Communities
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 05 Feb 2020 01:43:20 -0000

On Tue, Feb 4, 2020 at 5:28 PM Sriram, Kotikalapudi (Fed) <
kotikalapudi.sriram@nist.gov> wrote:

> > > Does anyone want to co-author and suggest changes?
> I would also be glad to participate in that effort.
>
> I have looked at the proposals in the two drafts (Jacob and John H).
> There are a few observations I would like to share.
>
> As Alvaro pointed out, RFC 8092 says:
>    This document defines the BGP Large Communities attribute as an
>    optional transitive path attribute of variable length.
>
> That means *all* BGP Large Communities are transitive. Do you agree?
> RFC 8195 seems to be written in that spirit as well.
>

They are, by default, transitive, unless local policy is to either strip
them or filter updates based on the values (or some portion out of the
values, like bits 6-7).


>
> The first 32 bits together are a Global Administrator (GA) ID.
> So, it seems it would not be possible to use any part of it as data.
> Otherwise, collisions (ambiguity) could happen when
> other LCs use 4-octet ASNs in the Global Administrator field. Agree?
>

Only real ASNs have any reasonable expectation of collision protection and
uniqueness, i.e. ASN values <4,000,000,000


> I see Jacob's draft proposes using some portion of the first 32 bits as
> data.
> The draft that John Heasly shared sets the first 32-bits to ASN value 0
> to designate WK-LC;  so no part of the first 32-bits is data.
>
> Another idea to consider:
> Why not request IANA to assign a range of 256 or 1024 or some number (?)
> of 4-byte ASN values to be allocated and used as GA ID for transitive
> WK-LCs?
> A function (e.g., route-leak protection) that requires transitive WK-LC
> will be allocated one these ASN values.
> Then we don't waste any part of the first 32-bits to designate "type" of
> LC.
>

Jakob's proposal is quite reasonable.
The 32-bit ASN RFC (don't recall it offhand) reserves all values
>4,000,000,000 as private values.
Reserving only those that start (binary) 111110 is a very small slice off
that range, near the top but not the very top.
Having an extra 16 bits to play with, for every WKC, plus 2 bits per the T
field, is plenty and very useful.
Only having two 32-bit values is overly limiting, IMHO.

Brian



> That cleanly leaves 64 bits for local data (as RFC 8092 specifies)
> which can accommodate two 4-byte ASNs if needed.
>
> Sriram
>
> > -----Original Message-----
> > From: John Heasly <heas@shrubbery.net>
> > Sent: Tuesday, February 4, 2020 5:55 PM
> > To: Jakob Heitz (jheitz) <jheitz@cisco.com>
> > Cc: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>ov>; Job
> Snijders
> > <job@ntt.net>et>; Nick Hilliard <nick@foobar.org>rg>; John Heasly
> > <heas@shrubbery.net>et>; idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org;
> > grow-chairs@ietf.org; a.e.azimov@gmail.com; Brian Dickson
> > <brian.peter.dickson@gmail.com>
> > Subject: Re: Question about BGP Large Communities
> >
> > Tue, Feb 04, 2020 at 08:45:40PM +0000, Jakob Heitz (jheitz):
> > > A set of well known large communities could be useful.
> > > I have a draft that I never submitted attached to this email.
> > > Does anyone want to co-author and suggest changes?
> >
> > Hey Jacob,
> > I'd work on that with you.  Job, Morrow and I also started a draft for
> > Large WKCs, but we have not submitted anything - nor made any recent
> > progress.
> >
> > IIRC, the direction we were intending to use 0 (zero) as the ASN, then
> > define local data part 1 as WKC itself, and local data part 2 to be a
> > value associated.
> >
> > I've attached that I have written so far.  Job and Morrow may or may not
> > endorse this approach at this point.
> >
> > -heas
>