Customers announcing communities to SP of SP
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!
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+nanog@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!
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+nanog@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!
On Mon, Sep 19, 2016 at 12:00:36PM -0400, Jason Lixfeld 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]
"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 Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG
participants (4)
-
i3D.net - Martijn Schmidt -
Jason Lixfeld -
Joe Provo -
Theodore Baschak