Hi Jason, The following reply which I sent to the IDR mailing list might also be helpful for you to understand the way most of these designs currently work - as well as some of the problems we encounter with the existing RFC1997 communities:
http://www.ietf.org/mail-archive/web/idr/current/msg16219.html draft-heitz-idr-large-community should tackle the missing 32-bit ASN feature, but should also resolve the private AS overlapping problem you're describing in [2] since it's a 32:32:32 format rather than 16:16. Best regards, Martijn Schmidt On 09/19/2016 10:28 PM, Theodore Baschak wrote: > In a previous $dayjob at a different ASN I was customers of a large-ish > regional Canadian carrier (at 100M), and also of a small local guy (at 8M) > with only Cogent upstream. I would prepend out the local guy 3x, and then I > also tagged 174:3003 to have cogent prepend 3x more. This worked somewhat > OK to make up for the inbalance in speeds. > > This type of use case is supported by, and works well with > draft-heitz-idr-large-community. As an operator of a 32-bit ASN I have no > ability to use communities with my ASN in them like 16-bit ASN operator > could, and I have expressed so on the IETF IDR list. > > > > Theodore Baschak - AS395089 - Hextet Systems > https://ciscodude.net/ - https://hextet.systems/ > http://mbix.ca/ > > > On Mon, Sep 19, 2016 at 11:00 AM, Jason Lixfeld <jason+na...@lixfeld.ca> > wrote: > >> Hi, >> >> Consider the following scenario: >> >> - Customer A is a customer of SP A >> - SP A is a customer of SP B >> - SP B has a traffic engineering community implementation >> >> With regards to using BGP communities for TE: >> >> - Does SP A write their own community implementation that maps to (some >> portion of) the community implementation of SP B? >> - Does SP A write their own community implementation that has no mappings >> at all to the community implementation of SP B; any TE that is required to >> be pushed to SP B is done by some dialog and coordination between Customer >> A and SP A? >> - Does SP A allow Customer A to announce prefixes tagged with SP B’s >> communities[1][2] >> - Is this sort of thing really complicated today, but one of the goals of >> draft-heitz-idr-large-community? >> >> [1] Customer A has knowledge of SP A’s upstream SP B >> [2] This opens up a can of worms where SP A or SP B implements some >> communities prefixed with reserved ASes, so we’ll assume that SP A >> implements some method of allowing communities prefixed with ASes of SP A >> and SP B only. >> >> Thanks!
