Re: [Idr] Question about BGP Large Communities

[Brian Dickson <[e-mail]>]

On Tue, Feb 4, 2020 at 5:28 PM Sriram, Kotikalapudi (Fed) <
[e-mail]> 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 <[e-mail]>
> > Sent: Tuesday, February 4, 2020 5:55 PM
> > To: Jakob Heitz (jheitz) <[e-mail]>
> > Cc: Sriram, Kotikalapudi (Fed) <[e-mail]>; Job
> Snijders
> > <[e-mail]>; Nick Hilliard <[e-mail]>; John Heasly
> > <[e-mail]>; [e-mail]; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; Brian Dickson
> > <[e-mail]>
> > 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
>