Most of us have already used some BGP community policy to no-export some routes to some where.
On the majority of IXPs, and most of the Transit Providers, the very common community tell to route-servers and routers “Please do no-export these routes to that ASN” is:
-> 0:
So we could say that this is a de-facto standard.
But the Policy equivalent to “Please, export these routes only to that ASN” is very varied on all the IXPs or Transit Providers.
With that said, now comes some questions:
1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or something like that, that would define 0: as “no-export-to” standard?
2 - What about reserving some 16-bits ASN to use : as “export-only-to” standard?
2.1 - Is important to be 16 bits, because with (RT) extended communities, any ASN on the planet could be the target of that policy.
2.2 - Would be interesting some mnemonic number like 1000 / 10000 or so.
Hi Douglas,
Just FYI I have tried to capture most common use cases of communities and register them as part of a wide-community effort in IANA.
https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02
That draft is pending standardization of wide-communities itself.
You are obviously very welcome to either reuse some of this work or support it 
Kind regards,
R.
The standard already exists… “NO_EXPORT”. Provided ISP’s or exchange points can publish their own local values to match that within their network, I believe they can do whatever they want, since it’s locally-significant. I’m not sure we want to go down the trail of standardizing a “de facto” usage. Just like QoS, it may be doomed as different operators define what it means for them. Mark.
Mark,
The standard already exists… “NO_EXPORT”.
I don’t think this is the ask here.
Today NO_EXPORT takes no parameters. I think it would be of benefit to all to be able to signal NO_EXPORT TO ASN_X in a common (std) way across all of my peers connected to ASN_X. Moreover policy on all vendors could understand it too without you worrying to match YOUR_STRING and translate into some local policy.
That is by no means taking away anything you have at your fingertips … it just adds an option to talk common policy language.
Cheers,
R.
This already happens today, but mostly in a commercial relationship
(customer and provider).
While not technically impossible, I struggle to see operators opening up
their networks to peers they hardly personally (or commercially) know
with such a feature, custom or standardized.
I suppose the bigger question is - can we trust each other, as peers,
with such access to each other's networks?
Mark.
Mark,
This does not require any more trust for say directly connected peers more then today when you publish communities on the web page.
It is not about opening up your network. It is about expressing your policy in a common way in the exact say amount as you would open up your network today.
Notice that in addition to common types there is equal amount of space left for operator’s define types. It is just that the structure of community can take number of arguments used during execution - that’s all.
Thx,
R.
BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish.
How I see the OP’s intent is to create a BCP of what defined communities have what effect instead of everyone just making up whatever they draw out of a hat, simplifying this process for everyone.
Douglas,
Most of us have already used some BGP community policy to no-export some routes to somewhere.
On the majority of IXPs, and most of the Transit Providers, the very common community tell to route-servers and routers "Please do no-export these routes to that ASN" is:
-> 0:<TargetASN>
So we could say that this is a de-facto standard.
But the Policy equivalent to "Please, export these routes only to that ASN" is very varied on all the IXPs or Transit Providers.
With that said, now comes some questions:
1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or something like that, that would define 0:<TargetASN> as "no-export-to" standard?
2 - What about reserving some 16-bits ASN to use <ExpOnlyTo>:<TargetASN> as "export-only-to" standard?
2.1 - Is important to be 16 bits, because with (RT) extended communities, any ASN on the planet could be the target of that policy.
2.2 - Would be interesting some mnemonic number like 1000 / 10000 or so.
Please see:
- https://www.euro-ix.net/en/forixps/large-bgp-communities/
- https://tools.ietf.org/id/draft-adkp-grow-ixpcommunities-00.html
If you use large communities (yes, I know the standard is NOT 100%
unilaterally supported by all vendors just yet).
Using the combination of RS${ASN}:0:0 (Don't announce to any peer) and
RS${ASN}:1:${PEERAS} (Advertise to PEERAS) you can do what you are
asking for. Announcing routes to only select peers.
Most major IXP's will support most of the mentioned large
communities. For ISP's in general. It's thou a different story that is
not mine to speak about.
Using 2-byte communities in today's age of explosive "assignment" of
4-byte ASN's is similar to the price-hike of IPv4 space. In the long
term. Standard BGP communities and IPv4 will not be worth the required
effort/investment (unless you want to "cripple" yourself from the
get-go). And IPv6 and Large BGP Communities is "slowly" gaining traction
as the way to go.
I also get that intent from the OP. However I disagree that there should be a ‘de facto’ standard created for such things. All flavors of BGP community specifications are designed to be flexible so that different networks can design a system that is tailored to their needs.
Having ‘de facto’ standards does not simplify in my opinion. I believe it just creates more work for operators trying to navigate around different opinions of what ‘de facto’ means.
Is there more desire to be flexible because people are snowflakes and their idea is the only way it should be or real, document-able reasons?
Every network is a snowflake already. Everyone has different needs and operational considerations, which will also change over time. My community structure would not fit your needs, and yours would not fit mine. The current structure of regular and extended allows us to come up with something that works well for each of us, which is good.
Exactly Mike!
The Idea would be to define some base levels, to make the creations of route-filtering simpler to everyone in the world.
And what comes beyond that, is in charge of each autonomous system.
It would make the scripting and templates easier and would avoid fat-fingers.
The operators are snowflakes. Are the networks really snowflakes?
Per cidr-report.org, there are almost 70k ASes in the public routing table. I can’t imagine there would be more than 20 different ways those networks should use BGP communities to interface with the outside world. The 95th (maybe even 99th) percentile would probably fit in 1 or 2 ways.
Also, no one’s going to jail for not adopting whatever standard may or may not emerge. Hell, we can’t even get people to police their own traffic (BCP 38).
This does not require any more trust for say directly connected peers
more then today when you publish communities on the web page.
I'd tend to disagree.
Trusting your direct peer to not send you default or to have a 24/7 NOC
to handle connectivity issues is not the same level of trust I'd afford
them to send me a community that told my network what to announce to my
other eBGP neighbors or not.
Of course, I am probably less trusting than most, so I'm not
recommending anyone follow my advice :-).
It is not about opening up your network. It is about expressing your
policy in a common way in the exact say amount as you would open up
your network today.
I can express my policy, publicly. But I can also indicate who has the
power to implement that expression on my side.
Notice that in addition to common types there is equal amount of
space left for operator's define types. It is just that the structure
of community can take number of arguments used during execution -
that's all.
That is all good and well, and works beautifully within an operator's
network, which is the point of the capability.
Extending that to non-customer networks is not technically impossible.
It's just a question of trust.
It's not unlike trusting your customers to send you FlowSpec
instructions. No issues technically, but do you want to do it?
Mark.
Which only matters if you are extending a community outside of your own network to someone else’s. If the communities are to be used internally, then it doesn’t matter what definition an operator uses. Mark.
Indeed.
Consider a new ISP starting operations in Myanmar, with little or no
global peering, having to wade through tons of information to design
their BGP community structure based on a "de facto" standard defined by
a group of ISP's half-way around the world.
What's the real value?
Mark.
Are we saying that what individual operators design for their own networks is “complicated”, and that coalescing around a single “de facto” standard would simplify that? Mark.