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
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  since it's a 32:32:32 format rather than 16:16.
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/
> On Mon, Sep 19, 2016 at 11:00 AM, Jason Lixfeld <jason+na...@lixfeld.ca>
>> 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
>> - Is this sort of thing really complicated today, but one of the goals of
>>  Customer A has knowledge of SP A’s upstream SP B
>>  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.