Customers announcing communities to SP of SP
nanog-post at rsuc.gweep.net
Tue Sep 20 13:06:46 UTC 2016
On Mon, Sep 19, 2016 at 12:00:36PM -0400, Jason Lixfeld wrote:
> 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
"Sometimes" for all of the above; it depends on the network. There are
networs which strip all signalling but their own. There are those who
will strip signalling to their immediate neighbors (expecting customers
to use thri own). There are some which propagate anything and everything.
IME, it is generally good to sanitize an input stream of signalling you
use to reduce unknown/difficult to trace conditions. It is also a good
principle for a sender to be aware of how far their dollars/euros/quatloos
propagate, as that's pretty much the limit of guarantee others will act
on their requests. In your scenario, when SP B changes their communities,
they have no obligation (nor method) to let a downstream of a downstream
know about it...
> - Is this sort of thing really complicated today, but one of the
> goals of draft-heitz-idr-large-community?
It can be complicated - review the various way folks have published
their policies via the compilation up at https://onestep.net/communities/
and you'll see a number of approaches. I can't speak for the authors,
but by my reading draft-heitz-idr-large-community provides two things:
- parity for 32b and 16b use in communities
- the room to clearly express multiple party ASNs distinctly from
'take action' data, which we do not have now
RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG
More information about the NANOG