If I understand it correctly, the proposed mechanism in Jakob's draft requires to change the encoding of Global Administrator in Large community. In general I like this change, it gives LC a structural encoding, which may be useful for future use cases. OTOH, this change typically would require new code and upgrade of devices, which may not meet the requirement mentioned in Brian's mail...
Best regards, Jie > -----Original Message----- > From: GROW [mailto:[email protected]] On Behalf Of Sriram, > Kotikalapudi (Fed) > Sent: Wednesday, February 5, 2020 9:29 AM > To: John Heasly <[email protected]>; Jakob Heitz (jheitz) <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [GROW] Question about BGP Large Communities > > > > 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. > > 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? > 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. > 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
