Private ASNs are 4,200,000,000 upwards. I am requesting a block just below that > 4,000,000,000.
Regards, Jakob. From: Brian Dickson <[email protected]> Sent: Tuesday, February 4, 2020 5:43 PM To: Sriram, Kotikalapudi (Fed) <[email protected]> Cc: John Heasly <[email protected]>; Jakob Heitz (jheitz) <[email protected]>; [email protected]; [email protected] Subject: Re: Question about BGP Large Communities On Tue, Feb 4, 2020 at 5:28 PM Sriram, Kotikalapudi (Fed) <[email protected]<mailto:[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]<mailto:[email protected]>> > Sent: Tuesday, February 4, 2020 5:55 PM > To: Jakob Heitz (jheitz) <[email protected]<mailto:[email protected]>> > Cc: Sriram, Kotikalapudi (Fed) > <[email protected]<mailto:[email protected]>>; Job > Snijders > <[email protected]<mailto:[email protected]>>; Nick Hilliard > <[email protected]<mailto:[email protected]>>; John Heasly > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; Brian Dickson > <[email protected]<mailto:[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
