On Tue, Feb 4, 2020 at 5:28 PM Sriram, Kotikalapudi (Fed) < [email protected]> 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 <[email protected]> > > Sent: Tuesday, February 4, 2020 5:55 PM > > To: Jakob Heitz (jheitz) <[email protected]> > > Cc: Sriram, Kotikalapudi (Fed) <[email protected]>; Job > Snijders > > <[email protected]>; Nick Hilliard <[email protected]>; John Heasly > > <[email protected]>; [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; Brian Dickson > > <[email protected]> > > 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 >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
