BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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:<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. -- Douglas Fernando Fischer Engº de Controle e Automação
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-0... 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. On Tue, Sep 8, 2020 at 5:58 PM Douglas Fischer via NANOG <nanog@nanog.org> wrote:
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:<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.
-- Douglas Fernando Fischer Engº de Controle e Automação
On 8/Sep/20 17:55, Douglas Fischer via NANOG wrote:
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:<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.
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. On Tue, Sep 8, 2020 at 6:23 PM Mark Tinka via NANOG <nanog@nanog.org> wrote:
On 8/Sep/20 17:55, Douglas Fischer via NANOG wrote:
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:<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.
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.
On 8/Sep/20 18:41, Robert Raszuk wrote:
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.
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. On Tue, Sep 8, 2020 at 8:10 PM Mark Tinka <mark.tinka@seacom.com> wrote:
On 8/Sep/20 18:41, Robert Raszuk wrote:
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.
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.
On 8/Sep/20 20:15, Robert Raszuk wrote:
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.
Mark, On last point yes. The entire idea behind flow spec is to work inter-as to mitigate DDoS as close to a source as possible. And if you validate against advertising reachability what's the problem ? And as far as wide they just let you structure your community in a common way. It is both to customers or to others as you choose. Nothing there is about trust. It is all about mechanics how you pass embedded instructions. Best, R. On Wed, Sep 9, 2020, 06:25 Mark Tinka <mark.tinka@seacom.com> wrote:
On 8/Sep/20 20:15, Robert Raszuk wrote:
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.
On 9/Sep/20 09:15, Robert Raszuk wrote:
On last point yes. The entire idea behind flow spec is to work inter-as to mitigate DDoS as close to a source as possible.
Indeed, that is the original intention. Any reason why we don't see it happening in this way, today?
And as far as wide they just let you structure your community in a common way. It is both to customers or to others as you choose. Nothing there is about trust. It is all about mechanics how you pass embedded instructions.
Again, no technical or mechanical limitations at all with trying to get this done. What I am saying is that the element of trust gets in the way, for better or worse. But while on the OP's intent - if you were to provide communities to peers to signal forwarding in your network, you can simply publish those communities on your web site. They don't need to follow any standard. At the same time, if the industry were to agree on standard communities to signal typical forwarding decisions within our networks, those would work too, and I dare say that operators would publish them on their web sites either way, for the avoidance of doubt. Moreover, anyone implementing those communities would probably double-check with the intended operator to make sure that what they are going to signal as an-agreed global standard is supported and will work. Just like how solar PV inverters are meant to disconnect from the grid in the case of a utility outage, line workers will still, as a matter of course, always check the line to see if it's live or not, before performing any repairs. That line workers can simply trust that PV inverters are doing the right thing in the event of a grid failure is not practical. Checking to see if the line is live does not impose any inconvenience on standard operating procedures. So if we are able to provide support for remote signaling of forwarding within our networks to off-net peers via communities, be it with standard or dis-aggregated community values, either facility is available and technically feasible today. The better question to ask would be why this hasn't taken shape outside of provider-customer relationships. Mark.
On Wed, 9 Sep 2020 at 06:25, Mark Tinka via NANOG <nanog@nanog.org> wrote:
It's not unlike trusting your customers to send you FlowSpec instructions. No issues technically, but do you want to do it?
Why not? As a service offering, it makes total sense. Thou, generally I agree with you. Trust, but verify any received announcement conforms to a base-set of expectations. Discard non-conforming. -- Chriztoffer
Chriztoffer Hansen via NANOG Sent: Wednesday, September 9, 2020 1:29 PM
On Wed, 9 Sep 2020 at 06:25, Mark Tinka via NANOG <nanog@nanog.org> wrote:
It's not unlike trusting your customers to send you FlowSpec instructions. No issues technically, but do you want to do it?
Why not? As a service offering, it makes total sense.
Thou, generally I agree with you. Trust, but verify any received announcement conforms to a base-set of expectations. Discard non- conforming.
Yeah right, like you all are limiting max length of as_path, dropping boggon ASNs, or limiting max number of communities or striping unused/unsupported attributes on ingress to your AS... Or otherwise test what happens to your border edge (or internet-plane route-reflectors/ iBGP infrastructure for that matter) if exposed to these. adam
On Sep 8, 2020, at 9:22 AM, Mark Tinka via NANOG <nanog@nanog.org> wrote:
On 8/Sep/20 17:55, Douglas Fischer via NANOG wrote:
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:<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.
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.
To the extent that communities are standardized, they’re supposed to be ASN:Community, so 0:<TargetASN> seems like a bad convention to begin with. Further, many of the things people claim they want from odd-ball techniques trying to cram things into 32-bit communities are actually standardized and easily implemented (without hackery) using either Extended Communities, or Large Communities, with the advantage that you can also accommodate 4-octet ASNs without stupid router tricks. Please consider looking at existing standards before making up new ones. Thanks, Owen
BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish. On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG <nanog@nanog.org> wrote:
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:<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.
-- Douglas Fernando Fischer Engº de Controle e Automação
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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Tom Beecher via NANOG" <nanog@nanog.org> To: "Douglas Fischer" <fischerdouglas@gmail.com> Cc: "NANOG" <nanog@nanog.org> Sent: Tuesday, September 8, 2020 1:30:19 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish. On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > wrote: 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:<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. -- Douglas Fernando Fischer Engº de Controle e Automação
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. On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett <nanog@ics-il.net> wrote:
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.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------ *From: *"Tom Beecher via NANOG" <nanog@nanog.org> *To: *"Douglas Fischer" <fischerdouglas@gmail.com> *Cc: *"NANOG" <nanog@nanog.org> *Sent: *Tuesday, September 8, 2020 1:30:19 PM *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish.
On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG <nanog@nanog.org> wrote:
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:<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.
-- Douglas Fernando Fischer Engº de Controle e Automação
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? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Tom Beecher" <beecher@beecher.cc> To: "Mike Hammett" <nanog@ics-il.net> Cc: "NANOG" <nanog@nanog.org>, "Douglas Fischer" <fischerdouglas@gmail.com> Sent: Tuesday, September 8, 2020 3:02:37 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' 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. On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett < nanog@ics-il.net > wrote: 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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Tom Beecher via NANOG" < nanog@nanog.org > To: "Douglas Fischer" < fischerdouglas@gmail.com > Cc: "NANOG" < nanog@nanog.org > Sent: Tuesday, September 8, 2020 1:30:19 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish. On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > wrote: <blockquote> 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:<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. -- Douglas Fernando Fischer Engº de Controle e Automação </blockquote>
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. On Tue, Sep 8, 2020 at 4:06 PM Mike Hammett <nanog@ics-il.net> wrote:
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?
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------ *From: *"Tom Beecher" <beecher@beecher.cc> *To: *"Mike Hammett" <nanog@ics-il.net> *Cc: *"NANOG" <nanog@nanog.org>, "Douglas Fischer" < fischerdouglas@gmail.com> *Sent: *Tuesday, September 8, 2020 3:02:37 PM *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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.
On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett <nanog@ics-il.net> wrote:
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.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------ *From: *"Tom Beecher via NANOG" <nanog@nanog.org> *To: *"Douglas Fischer" <fischerdouglas@gmail.com> *Cc: *"NANOG" <nanog@nanog.org> *Sent: *Tuesday, September 8, 2020 1:30:19 PM *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish.
On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org> wrote:
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:<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.
-- Douglas Fernando Fischer Engº de Controle e Automação
The operators are snowflakes. Are the networks really snowflakes? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Tom Beecher" <beecher@beecher.cc> To: "Mike Hammett" <nanog@ics-il.net> Cc: "NANOG" <nanog@nanog.org>, "Douglas Fischer" <fischerdouglas@gmail.com> Sent: Tuesday, September 8, 2020 3:36:22 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' 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. On Tue, Sep 8, 2020 at 4:06 PM Mike Hammett < nanog@ics-il.net > wrote: 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? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Tom Beecher" <beecher@beecher.cc> To: "Mike Hammett" < nanog@ics-il.net > Cc: "NANOG" < nanog@nanog.org >, "Douglas Fischer" < fischerdouglas@gmail.com > Sent: Tuesday, September 8, 2020 3:02:37 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' 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. On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett < nanog@ics-il.net > wrote: <blockquote> 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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Tom Beecher via NANOG" < nanog@nanog.org > To: "Douglas Fischer" < fischerdouglas@gmail.com > Cc: "NANOG" < nanog@nanog.org > Sent: Tuesday, September 8, 2020 1:30:19 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish. On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > wrote: <blockquote> 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:<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. -- Douglas Fernando Fischer Engº de Controle e Automação </blockquote> </blockquote>
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). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett via NANOG" <nanog@nanog.org> To: "Tom Beecher" <beecher@beecher.cc> Cc: "NANOG" <nanog@nanog.org> Sent: Tuesday, September 8, 2020 5:56:22 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' The operators are snowflakes. Are the networks really snowflakes? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Tom Beecher" <beecher@beecher.cc> To: "Mike Hammett" <nanog@ics-il.net> Cc: "NANOG" <nanog@nanog.org>, "Douglas Fischer" <fischerdouglas@gmail.com> Sent: Tuesday, September 8, 2020 3:36:22 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' 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. On Tue, Sep 8, 2020 at 4:06 PM Mike Hammett < nanog@ics-il.net > wrote: 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? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Tom Beecher" <beecher@beecher.cc> To: "Mike Hammett" < nanog@ics-il.net > Cc: "NANOG" < nanog@nanog.org >, "Douglas Fischer" < fischerdouglas@gmail.com > Sent: Tuesday, September 8, 2020 3:02:37 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' 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. On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett < nanog@ics-il.net > wrote: <blockquote> 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. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Tom Beecher via NANOG" < nanog@nanog.org > To: "Douglas Fischer" < fischerdouglas@gmail.com > Cc: "NANOG" < nanog@nanog.org > Sent: Tuesday, September 8, 2020 1:30:19 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish. On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG < nanog@nanog.org > wrote: <blockquote> 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:<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. -- Douglas Fernando Fischer Engº de Controle e Automação </blockquote> </blockquote>
In my comments, it’s more about avoiding de facto “standards” in favor of having actual “standards” or following existing actual “standards”. There are RFCs that cover what the OP wants. There is an IANA well-known Communities registry that can be expanded to record any additional functionality OP wants from communities without creating de facto standards. The problem with so-called “de facto standards” is that there’s an open question of who decides what the standard is and how much credibility they have and/or can maintain over time. There’s also the problem that nothing prevents someone who doesn’t like someone else’s “de facto standard” from creating one of their own. In some cases, everyone yawns and ignores the new standard. In other cases, the old standard fades in favor of the new. In most cases, the community fractures, both standards gain some traction and neither standard wins creating more chaos than standard in the end. IMHO, that’s a real document-able reason. YMMV. Owen
On Sep 8, 2020, at 1:06 PM, Mike Hammett via NANOG <nanog@nanog.org> wrote:
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?
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com <http://www.ics-il.com/>
Midwest-IX http://www.midwest-ix.com <http://www.midwest-ix.com/>
From: "Tom Beecher" <beecher@beecher.cc <mailto:beecher@beecher.cc>> To: "Mike Hammett" <nanog@ics-il.net <mailto:nanog@ics-il.net>> Cc: "NANOG" <nanog@nanog.org <mailto:nanog@nanog.org>>, "Douglas Fischer" <fischerdouglas@gmail.com <mailto:fischerdouglas@gmail.com>> Sent: Tuesday, September 8, 2020 3:02:37 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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.
On Tue, Sep 8, 2020 at 2:35 PM Mike Hammett <nanog@ics-il.net <mailto:nanog@ics-il.net>> wrote: 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.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com <http://www.ics-il.com/>
Midwest-IX http://www.midwest-ix.com <http://www.midwest-ix.com/>
From: "Tom Beecher via NANOG" <nanog@nanog.org <mailto:nanog@nanog.org>> To: "Douglas Fischer" <fischerdouglas@gmail.com <mailto:fischerdouglas@gmail.com>> Cc: "NANOG" <nanog@nanog.org <mailto:nanog@nanog.org>> Sent: Tuesday, September 8, 2020 1:30:19 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
BGP Large Communities ( https://tools.ietf.org/html/rfc8195 <https://tools.ietf.org/html/rfc8195> ) already provides for anyone to define the exact handling you wish.
On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote: 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:<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.
-- Douglas Fernando Fischer Engº de Controle e Automação
On 8/Sep/20 22:02, Tom Beecher via NANOG wrote:
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.
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.
How is that any different than any other network with minimal connectivity (say a non-ISP such as a school, medium business, local government, etc.)? Also, it would likely help that new ISP in Myanmar learn their limited upstream's communities if there were a standard. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka via NANOG" <nanog@nanog.org> To: nanog@nanog.org Sent: Tuesday, September 8, 2020 11:28:48 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' On 8/Sep/20 22:02, Tom Beecher via NANOG wrote:
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.
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.
On 9/Sep/20 13:41, Mike Hammett wrote:
How is that any different than any other network with minimal connectivity (say a non-ISP such as a school, medium business, local government, etc.)?
Because the existing flexibility of dis-aggregated BGP community design can be done without any need to be in concert with the rest of the world, and your network won't blow up. There are far more pressing things to consider when launching a new network.
Also, it would likely help that new ISP in Myanmar learn their limited upstream's communities if there were a standard.
There used to be a very large global transit network that did not support BGP communities for their customers or peers. I'm not sure if that is still their position in 2020, but back then, it did not stop them from growing quite well. Mark.
Exactly. There are far more pressing things when launching a new network than coming up with a BGP community scheme from scratch, learning everyone else's BGP community scheme, etc. If networks used a standard, then there is a very minimal ramp-up. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" <mark.tinka@seacom.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org Sent: Wednesday, September 9, 2020 6:47:13 AM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' On 9/Sep/20 13:41, Mike Hammett wrote: How is that any different than any other network with minimal connectivity (say a non-ISP such as a school, medium business, local government, etc.)? Because the existing flexibility of dis-aggregated BGP community design can be done without any need to be in concert with the rest of the world, and your network won't blow up. There are far more pressing things to consider when launching a new network. <blockquote> Also, it would likely help that new ISP in Myanmar learn their limited upstream's communities if there were a standard. </blockquote> There used to be a very large global transit network that did not support BGP communities for their customers or peers. I'm not sure if that is still their position in 2020, but back then, it did not stop them from growing quite well. Mark.
Well, the proposed de facto standard is only useful for what we need to signal outside of the AS. Since an operator will still need to design for communities used internal to the AS (which will have nothing to do with the outside world, and be of a higher number), they can accomplish both tasks in one sitting; in lieu of first designing for internal use, and then trying to design again for the external standard. At any rate, as Nick said yesterday, if it's taken us over 2 decades to agree on the well-known communities we have today, perhaps the industry should go ahead and standardize this proposal anyway, and then see what happens. If history has taught us anything, folk will do what they want for 23 or so years, and even then, it might not turn out the way we hoped. If it were me, I'd spend my time on other things. I can design internal operator-specific communities that also do the right thing externally, if needed. Heck, it's what I've done already. My customers are happy and I have little incentive to fix that. But that's just me :-). Mark. On 9/Sep/20 14:47, Mike Hammett wrote:
Exactly. There are far more pressing things when launching a new network than coming up with a BGP community scheme from scratch, learning everyone else's BGP community scheme, etc. If networks used a standard, then there is a very minimal ramp-up.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------------------------------------------------ *From: *"Mark Tinka" <mark.tinka@seacom.com> *To: *"Mike Hammett" <nanog@ics-il.net> *Cc: *nanog@nanog.org *Sent: *Wednesday, September 9, 2020 6:47:13 AM *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
On 9/Sep/20 13:41, Mike Hammett wrote:
How is that any different than any other network with minimal connectivity (say a non-ISP such as a school, medium business, local government, etc.)?
Because the existing flexibility of dis-aggregated BGP community design can be done without any need to be in concert with the rest of the world, and your network won't blow up. There are far more pressing things to consider when launching a new network.
Also, it would likely help that new ISP in Myanmar learn their limited upstream's communities if there were a standard.
There used to be a very large global transit network that did not support BGP communities for their customers or peers. I'm not sure if that is still their position in 2020, but back then, it did not stop them from growing quite well.
Mark.
More operators don't use communities internally than the number of operators that do. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" <mark.tinka@seacom.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org Sent: Wednesday, September 9, 2020 7:59:55 AM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' Well, the proposed de facto standard is only useful for what we need to signal outside of the AS. Since an operator will still need to design for communities used internal to the AS (which will have nothing to do with the outside world, and be of a higher number), they can accomplish both tasks in one sitting; in lieu of first designing for internal use, and then trying to design again for the external standard. At any rate, as Nick said yesterday, if it's taken us over 2 decades to agree on the well-known communities we have today, perhaps the industry should go ahead and standardize this proposal anyway, and then see what happens. If history has taught us anything, folk will do what they want for 23 or so years, and even then, it might not turn out the way we hoped. If it were me, I'd spend my time on other things. I can design internal operator-specific communities that also do the right thing externally, if needed. Heck, it's what I've done already. My customers are happy and I have little incentive to fix that. But that's just me :-). Mark. On 9/Sep/20 14:47, Mike Hammett wrote: Exactly. There are far more pressing things when launching a new network than coming up with a BGP community scheme from scratch, learning everyone else's BGP community scheme, etc. If networks used a standard, then there is a very minimal ramp-up. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" <mark.tinka@seacom.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org Sent: Wednesday, September 9, 2020 6:47:13 AM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' On 9/Sep/20 13:41, Mike Hammett wrote: <blockquote> How is that any different than any other network with minimal connectivity (say a non-ISP such as a school, medium business, local government, etc.)? Because the existing flexibility of dis-aggregated BGP community design can be done without any need to be in concert with the rest of the world, and your network won't blow up. There are far more pressing things to consider when launching a new network. <blockquote> Also, it would likely help that new ISP in Myanmar learn their limited upstream's communities if there were a standard. </blockquote> There used to be a very large global transit network that did not support BGP communities for their customers or peers. I'm not sure if that is still their position in 2020, but back then, it did not stop them from growing quite well. Mark. </blockquote>
On 9/Sep/20 15:06, Mike Hammett wrote:
More operators don't use communities internally than the number of operators that do.
Do you have some empirical data on that? I don't know if it's more, or less. But as Charlton Heston said in "True Lies": <poke> "So far this is not blowing my skirt up, gentlemen. Don't you have anything remotely substantial, Harry? Do you have any HARD DATA?" </poke> https://youtu.be/-KHkltl22V4?t=73 :-)... Mark.
No, but most network operators also aren't NANOG members, attend NANOG shows, subscribe to NANOG lists. They're small outfits where there's between 1 - 5 total networking people. Circling back to earlier where I said there are almost 70k ASNs in use on the public Internet. Most of those operators don't have complex configurations. I'd be surprised if less than half of them had anything more than the most minimal default route configuration. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" <mark.tinka@seacom.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org Sent: Wednesday, September 9, 2020 8:13:32 AM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' On 9/Sep/20 15:06, Mike Hammett wrote: More operators don't use communities internally than the number of operators that do. Do you have some empirical data on that? I don't know if it's more, or less. But as Charlton Heston said in "True Lies": <poke> "So far this is not blowing my skirt up, gentlemen. Don't you have anything remotely substantial, Harry? Do you have any HARD DATA?" </poke> https://youtu.be/-KHkltl22V4?t=73 :-)... Mark.
On 9/Sep/20 17:52, Mike Hammett wrote:
No, but most network operators also aren't NANOG members, attend NANOG shows, subscribe to NANOG lists.
They're small outfits where there's between 1 - 5 total networking people.
Yeah, I'll steer clear of that one :-)...
Circling back to earlier where I said there are almost 70k ASNs in use on the public Internet. Most of those operators don't have complex configurations. I'd be surprised if less than half of them had anything more than the most minimal default route configuration.
I don't know. If they are here, they can chime in. Mark.
On Wed, Sep 9, 2020 at 11:05 AM Mark Tinka via NANOG <nanog@nanog.org> wrote:
Circling back to earlier where I said there are almost 70k ASNs in use on the public Internet. Most of those operators don't have complex configurations. I'd be surprised if less than half of them had anything more than the most minimal default route configuration. I don't know. If they are here, they can chime in.
Hey Mark, I am here. At 10364 we have 7 network people, 3 of whom have an understanding of BGP deeper than surface level. We have 3 peers and 2 transit providers total. When we go to implement external-facing BGP policy, the #1 concern is "What are most people doing?". When we turn up a session with a peer or provider (which we will be doing much more frequently in the near future), it would be really wonderful if they could say "We support RFCXXXX-style communities" and we would know what that means. And if RFCXXXX exists then we will implement it when it's needed, just like we do no-export. I don't spend all day on BGP and so I like to defer to people who have learned from the "school of hard knocks" where possible. The last thing we want to do is to have a nonstandard or difficult-to-understand policy or configuration, because there are only 3 total people who could possibly understand it, and all of us have many, many other job responsibilities so we basically have to "page it back in" every time we go to look at it. The ideal situation is that we can google "RFCXXXX-compliant config" and get something that helps us get in line with best practices as smoothly as possible. -- Hunter Fuller (they) Router Jockey VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering
On 11/Sep/20 20:58, Hunter Fuller wrote:
Hey Mark, I am here. At 10364 we have 7 network people, 3 of whom have an understanding of BGP deeper than surface level. We have 3 peers and 2 transit providers total.
When we go to implement external-facing BGP policy, the #1 concern is "What are most people doing?". When we turn up a session with a peer or provider (which we will be doing much more frequently in the near future), it would be really wonderful if they could say "We support RFCXXXX-style communities" and we would know what that means. And if RFCXXXX exists then we will implement it when it's needed, just like we do no-export. I don't spend all day on BGP and so I like to defer to people who have learned from the "school of hard knocks" where possible.
The last thing we want to do is to have a nonstandard or difficult-to-understand policy or configuration, because there are only 3 total people who could possibly understand it, and all of us have many, many other job responsibilities so we basically have to "page it back in" every time we go to look at it. The ideal situation is that we can google "RFCXXXX-compliant config" and get something that helps us get in line with best practices as smoothly as possible.
So if your peer or provider sent you a link to a web site where they published all of their support BGP communities, you'd find that onerous to deploy across them? Mark.
On Wed, Sep 30, 2020 at 4:43 AM Mark Tinka <mark.tinka@seacom.com> wrote:
So if your peer or provider sent you a link to a web site where they published all of their support BGP communities, you'd find that onerous to deploy across them?
I'd find it to require more effort than just applying the same route-maps we already applied to the other peers/providers, and thus, less desirable. -- Hunter Fuller (they) Router Jockey VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering
If history has taught us anything, everything we do will be ignored by those that most need it. :-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" <mark.tinka@seacom.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org Sent: Wednesday, September 9, 2020 7:59:55 AM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' Well, the proposed de facto standard is only useful for what we need to signal outside of the AS. Since an operator will still need to design for communities used internal to the AS (which will have nothing to do with the outside world, and be of a higher number), they can accomplish both tasks in one sitting; in lieu of first designing for internal use, and then trying to design again for the external standard. At any rate, as Nick said yesterday, if it's taken us over 2 decades to agree on the well-known communities we have today, perhaps the industry should go ahead and standardize this proposal anyway, and then see what happens. If history has taught us anything, folk will do what they want for 23 or so years, and even then, it might not turn out the way we hoped. If it were me, I'd spend my time on other things. I can design internal operator-specific communities that also do the right thing externally, if needed. Heck, it's what I've done already. My customers are happy and I have little incentive to fix that. But that's just me :-). Mark. On 9/Sep/20 14:47, Mike Hammett wrote: Exactly. There are far more pressing things when launching a new network than coming up with a BGP community scheme from scratch, learning everyone else's BGP community scheme, etc. If networks used a standard, then there is a very minimal ramp-up. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" <mark.tinka@seacom.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org Sent: Wednesday, September 9, 2020 6:47:13 AM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' On 9/Sep/20 13:41, Mike Hammett wrote: <blockquote> How is that any different than any other network with minimal connectivity (say a non-ISP such as a school, medium business, local government, etc.)? Because the existing flexibility of dis-aggregated BGP community design can be done without any need to be in concert with the rest of the world, and your network won't blow up. There are far more pressing things to consider when launching a new network. <blockquote> Also, it would likely help that new ISP in Myanmar learn their limited upstream's communities if there were a standard. </blockquote> There used to be a very large global transit network that did not support BGP communities for their customers or peers. I'm not sure if that is still their position in 2020, but back then, it did not stop them from growing quite well. Mark. </blockquote>
Great excuse ;-) Regards, Jeff
On Sep 9, 2020, at 15:16, Mike Hammett via NANOG <nanog@nanog.org> wrote:
If history has taught us anything, everything we do will be ignored by those that most need it. :-)
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
From: "Mark Tinka" <mark.tinka@seacom.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org Sent: Wednesday, September 9, 2020 7:59:55 AM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Well, the proposed de facto standard is only useful for what we need to signal outside of the AS.
Since an operator will still need to design for communities used internal to the AS (which will have nothing to do with the outside world, and be of a higher number), they can accomplish both tasks in one sitting; in lieu of first designing for internal use, and then trying to design again for the external standard.
At any rate, as Nick said yesterday, if it's taken us over 2 decades to agree on the well-known communities we have today, perhaps the industry should go ahead and standardize this proposal anyway, and then see what happens. If history has taught us anything, folk will do what they want for 23 or so years, and even then, it might not turn out the way we hoped.
If it were me, I'd spend my time on other things. I can design internal operator-specific communities that also do the right thing externally, if needed. Heck, it's what I've done already. My customers are happy and I have little incentive to fix that.
But that's just me :-).
Mark.
On 9/Sep/20 14:47, Mike Hammett wrote: Exactly. There are far more pressing things when launching a new network than coming up with a BGP community scheme from scratch, learning everyone else's BGP community scheme, etc. If networks used a standard, then there is a very minimal ramp-up.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
From: "Mark Tinka" <mark.tinka@seacom.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org Sent: Wednesday, September 9, 2020 6:47:13 AM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
On 9/Sep/20 13:41, Mike Hammett wrote: How is that any different than any other network with minimal connectivity (say a non-ISP such as a school, medium business, local government, etc.)?
Because the existing flexibility of dis-aggregated BGP community design can be done without any need to be in concert with the rest of the world, and your network won't blow up. There are far more pressing things to consider when launching a new network.
Also, it would likely help that new ISP in Myanmar learn their limited upstream's communities if there were a standard.
There used to be a very large global transit network that did not support BGP communities for their customers or peers. I'm not sure if that is still their position in 2020, but back then, it did not stop them from growing quite well.
Mark.
Well, the proposed de facto standard is only useful for what we need to signal outside of the AS.
That's not quite true. See the entire idea behind defining a common mechanism for signalling policy in communities in a flexible way for both intra and inter-domain use is to help you to use the same encoding acros policy engines of many vendors. I would actually risk to say that it could be even more applicable intra-domain then inter-domain. See the crux of the thing is that this is not just about putting bunch of type-codes into IANA reg. It is much more about uniform encoding for your actions with optional parameters across vendors. In fact the uphill on the implementation side is not because signalling new value in BGP is difficult to encode ... it is much more about taking those values and translating those to the run time policies in a flexible way. Thx, R.
On 9/Sep/20 15:25, Robert Raszuk wrote:
That's not quite true.
See the entire idea behind defining a common mechanism for signalling policy in communities in a flexible way for both intra and inter-domain use is to help you to use the same encoding acros policy engines of many vendors.
I would actually risk to say that it could be even more applicable intra-domain then inter-domain.
See the crux of the thing is that this is not just about putting bunch of type-codes into IANA reg. It is much more about uniform encoding for your actions with optional parameters across vendors.
In fact the uphill on the implementation side is not because signalling new value in BGP is difficult to encode ... it is much more about taking those values and translating those to the run time policies in a flexible way.
But how does that scale for vendors? Let me speak up for them on this one :-). We are now giving them extra work to write code to standardize communities for internal purposes. What extra benefit does that provide in lieu of the current method where Juniper send 1234:9876 to Cisco, and Cisco sees 1234:9876? Should a vendor be concerned about what purpose an internal community serves, as long as it does what the Autonomous System wants it to do? Unless I am totally misunderstanding your goal. Mark.
It's not about numbers ... it's about ability to uniformly express policy with chain of arguments. See even with large communities you can define a policy with an unstructured parameter and single action then you need to put it on all of your boxes to act upon. Is it possible to perhaps express it there to do what you need today or what you think is possible today. Imagine if you would be sending BGP updates between your internal peers and tell each peer how to read the encoding ... Doable - sure. Good idea - not quite. R. On Wed, Sep 9, 2020 at 5:19 PM Mark Tinka <mark.tinka@seacom.com> wrote:
On 9/Sep/20 15:25, Robert Raszuk wrote:
That's not quite true.
See the entire idea behind defining a common mechanism for signalling policy in communities in a flexible way for both intra and inter-domain use is to help you to use the same encoding acros policy engines of many vendors.
I would actually risk to say that it could be even more applicable intra-domain then inter-domain.
See the crux of the thing is that this is not just about putting bunch of type-codes into IANA reg. It is much more about uniform encoding for your actions with optional parameters across vendors.
In fact the uphill on the implementation side is not because signalling new value in BGP is difficult to encode ... it is much more about taking those values and translating those to the run time policies in a flexible way.
But how does that scale for vendors? Let me speak up for them on this one :-).
We are now giving them extra work to write code to standardize communities for internal purposes. What extra benefit does that provide in lieu of the current method where Juniper send 1234:9876 to Cisco, and Cisco sees 1234:9876?
Should a vendor be concerned about what purpose an internal community serves, as long as it does what the Autonomous System wants it to do?
Unless I am totally misunderstanding your goal.
Mark.
On 9/Sep/20 17:42, Robert Raszuk wrote:
It's not about numbers ... it's about ability to uniformly express policy with chain of arguments.
See even with large communities you can define a policy with an unstructured parameter and single action then you need to put it on all of your boxes to act upon.
Is it possible to perhaps express it there to do what you need today or what you think is possible today.
Imagine if you would be sending BGP updates between your internal peers and tell each peer how to read the encoding ... Doable - sure. Good idea - not quite.
I see your logic. I'm not sure I want to put that much faith in vendors, to be honest. Just look at how the RPKI communities were cocked up in not-so-recent releases of Junos. Would vendor code shipping with pre-defined, more well-known communities make life easier? Sure, in theory. Do I want that and still seek a 3AM snooze when the team decide to run a revision update? Based on my experience, probably not. But, if vendors (and enough operators) are horny for this kind of thing, best thing to do would be to build it and see how it actually fares in the field. Mark.
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. Em ter., 8 de set. de 2020 às 15:35, Mike Hammett <nanog@ics-il.net> escreveu:
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.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------ *From: *"Tom Beecher via NANOG" <nanog@nanog.org> *To: *"Douglas Fischer" <fischerdouglas@gmail.com> *Cc: *"NANOG" <nanog@nanog.org> *Sent: *Tuesday, September 8, 2020 1:30:19 PM *Subject: *Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
BGP Large Communities ( https://tools.ietf.org/html/rfc8195 ) already provides for anyone to define the exact handling you wish.
On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG <nanog@nanog.org> wrote:
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:<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.
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Douglas Fernando Fischer Engº de Controle e Automação
On 8/Sep/20 23:22, Douglas Fischer via NANOG wrote:
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.
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.
Mark, Nope .. it is the other way around. It is all easy if you look from your network centric view. But if I am connected to 10 ISPs in each POP I have to build 10 different egress policies, each embedding custom policy, teach NOC to understand it etc... I think if there is a defined way to express prepend N times to my ISP peers across all uplinks or lower local pref in my ISP network in a same way to group of ISPs I see the value. Best Regards, R. On Wed, Sep 9, 2020, 06:36 Mark Tinka via NANOG <nanog@nanog.org> wrote:
On 8/Sep/20 23:22, Douglas Fischer via NANOG wrote:
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.
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.
On 9/Sep/20 09:21, Robert Raszuk wrote:
Nope .. it is the other way around.
It is all easy if you look from your network centric view.
But if I am connected to 10 ISPs in each POP I have to build 10 different egress policies, each embedding custom policy, teach NOC to understand it etc...
Well, yes and no. We, for example, connect to more than one transit provider in at least one of our PoP's. The outbound policies are exactly the same. The only difference is the differences in naming for each policy, and how we signal RTBH into the transit network. Everything else is the same. Rinse an repeat for all the exchange points we have connected to a single router, in a single PoP. I get that no two BGP routing policies are the same between operators, but I'm not certain standardizing on communities is going to make things any less complicated than we currently assume they are.
I think if there is a defined way to express prepend N times to my ISP peers across all uplinks or lower local pref in my ISP network in a same way to group of ISPs I see the value.
These kinds of policies are generally do-and-forget. When you spend time turning up a new provider, you are dedicating time to setting them up on your end. An extra 3 minutes to configure communities they have published is not overly complex, I believe. Moreover, it's not something you are likely to revisit outside of a communicated change on their end, or troubleshooting on your end. I'm all for making many things as standard as possible, but if our goal is to make signaling of external communities simpler than it is today, I don't quite see how standardizing said communities will simplify that process in a practical sense, on a global basis. As always, I could be wrong... Mark.
Sounds like you need a template based configuration management system and better automation more than you need to inflict an ad-hoc standardization of additional communities on the world. Owen
On Sep 9, 2020, at 12:21 AM, Robert Raszuk via NANOG <nanog@nanog.org> wrote:
Mark,
Nope .. it is the other way around.
It is all easy if you look from your network centric view.
But if I am connected to 10 ISPs in each POP I have to build 10 different egress policies, each embedding custom policy, teach NOC to understand it etc...
I think if there is a defined way to express prepend N times to my ISP peers across all uplinks or lower local pref in my ISP network in a same way to group of ISPs I see the value.
Best Regards, R.
On Wed, Sep 9, 2020, 06:36 Mark Tinka via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote:
On 8/Sep/20 23:22, Douglas Fischer via NANOG wrote:
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.
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.
On 8/Sep/20 20:35, Mike Hammett via NANOG wrote:
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.
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.
I don't think the OP cares about what you do internally. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka via NANOG" <nanog@nanog.org> To: nanog@nanog.org Sent: Tuesday, September 8, 2020 11:26:43 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' On 8/Sep/20 20:35, Mike Hammett via NANOG wrote: 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. 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.
Yes, but with large communities, that’s called RFC-8092 and in general, RFC-8642 has some good data. There’s also BGP extended communities (RFC-7153 and the IANA registry it creates). Creating an ad hoc BCP vs. using the existing RFC process seems ill-advised. Owen
On Sep 8, 2020, at 11:35 AM, Mike Hammett via NANOG <nanog@nanog.org> wrote:
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.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
From: "Tom Beecher via NANOG" <nanog@nanog.org> To: "Douglas Fischer" <fischerdouglas@gmail.com> Cc: "NANOG" <nanog@nanog.org> Sent: Tuesday, September 8, 2020 1:30:19 PM Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
BGP Large Communities ( https://tools.ietf.org/html/rfc8195 <https://tools.ietf.org/html/rfc8195> ) already provides for anyone to define the exact handling you wish.
On Tue, Sep 8, 2020 at 11:57 AM Douglas Fischer via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote: 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:<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.
-- Douglas Fernando Fischer Engº de Controle e Automação
Douglas, On Tue, 8 Sep 2020 at 17:55, Douglas Fischer via NANOG <nanog@nanog.org> wrote:
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. -- Cheers, Chriztoffer
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.
There are no 2-octet communities. There have never been 2-octet communities. Minimum 4 octets, which allows for a 2-octet ASN and a 2-octet community identifier. Owen
Douglas On 08.09.2020 17:55, Douglas Fischer via NANOG wrote:
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:<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.
you may want to have a look at https://www.euro-ix.net/en/forixps/large-bgp-communities/ Cheers Arnold -- Keep calm, keep distance, keep connected! Arnold Nipper email: arnold@nipper.de mobile: +49 172 2650958
I don’t agree with the use of reserved ASNs, let alone making it BCP, cause it defeats the whole purpose of the community structure. Community is basically sending a message to an AS. If I want your specific AS to interpret the message I set it in format YOUR_ASN:<community value>, your AS in the first part of the community means that your rules of how to interpret the community value apply. Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of communities (or any other attribute for that matter) just doesn’t sit right with me (what’s next? multicast-ASNs that we can subscribe to?). All the examples in Robert’s draft or wide community RFC, all of them use an example AS# the community is addressed to (not some special reserved AS#). Also should something like this become standard it needs to be properly standardized and implemented as a well-known community by most vendors (like RFCs defining the wide communities or addition to standard communities like no_export/no_advertise/…). This would also eliminate the adoption friction from operators rightly claiming “my AS my rules”. adam From: NANOG <nanog-bounces+adamv0025=netconsultings.com@nanog.org> On Behalf Of Douglas Fischer via NANOG Sent: Tuesday, September 8, 2020 4:56 PM To: NANOG <nanog@nanog.org> Subject: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' 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:<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. -- Douglas Fernando Fischer Engº de Controle e Automação
I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example of “ab”use of ASN0 is a de-facto artifact (unfortunate one). My goal would be to provide a viable source of information to someone who is setting up a new ISP and has a very little clue as where to start. Do’s and don’t’s wrt inter-domain communities use. I really enjoyed the difference RFC7938 (Use of BGP for Routing in Large-Scale Data Centers) made, literally 100s of companies have used it to educate themselves/ implemented their DC networking. Cheers, Jeff
On Sep 9, 2020, at 10:04, adam via NANOG <nanog@nanog.org> wrote: I don’t agree with the use of reserved ASNs, let alone making it BCP, cause it defeats the whole purpose of the community structure. Community is basically sending a message to an AS. If I want your specific AS to interpret the message I set it in format YOUR_ASN:<community value>, your AS in the first part of the community means that your rules of how to interpret the community value apply. Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of communities (or any other attribute for that matter) just doesn’t sit right with me (what’s next? multicast-ASNs that we can subscribe to?). All the examples in Robert’s draft or wide community RFC, all of them use an example AS# the community is addressed to (not some special reserved AS#).
Also should something like this become standard it needs to be properly standardized and implemented as a well-known community by most vendors (like RFCs defining the wide communities or addition to standard communities like no_export/no_advertise/…). This would also eliminate the adoption friction from operators rightly claiming “my AS my rules”.
adam
From: NANOG <nanog-bounces+adamv0025=netconsultings.com@nanog.org> On Behalf Of Douglas Fischer via NANOG Sent: Tuesday, September 8, 2020 4:56 PM To: NANOG <nanog@nanog.org> Subject: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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:<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.
-- Douglas Fernando Fischer Engº de Controle e Automação
And use of BGP without IGP left and right when even today bunch of DCs can do just fine with current IGPs scaling wise is IMO not a good thing. Thx R. On Wed, Sep 9, 2020, 10:55 Jeff Tantsura via NANOG <nanog@nanog.org> wrote:
I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example of “ab”use of ASN0 is a de-facto artifact (unfortunate one). My goal would be to provide a viable source of information to someone who is setting up a new ISP and has a very little clue as where to start. Do’s and don’t’s wrt inter-domain communities use.
I really enjoyed the difference RFC7938 (Use of BGP for Routing in Large-Scale Data Centers) made, literally 100s of companies have used it to educate themselves/ implemented their DC networking.
Cheers, Jeff
On Sep 9, 2020, at 10:04, adam via NANOG <nanog@nanog.org> wrote:
I don’t agree with the use of reserved ASNs, let alone making it BCP, cause it defeats the whole purpose of the community structure.
Community is basically sending a message to an AS. If I want your specific AS to interpret the message I set it in format YOUR_ASN:<community value>, your AS in the first part of the community means that your rules of how to interpret the community value apply.
Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of communities (or any other attribute for that matter) just doesn’t sit right with me (what’s next? multicast-ASNs that we can subscribe to?).
All the examples in Robert’s draft or wide community RFC, all of them use an example AS# the community is addressed to (not some special reserved AS#).
Also should something like this become standard it needs to be properly standardized and implemented as a well-known community by most vendors (like RFCs defining the wide communities or addition to standard communities like no_export/no_advertise/…). This would also eliminate the adoption friction from operators rightly claiming “my AS my rules”.
adam
*From:* NANOG <nanog-bounces+adamv0025=netconsultings.com@nanog.org> *On Behalf Of *Douglas Fischer via NANOG *Sent:* Tuesday, September 8, 2020 4:56 PM *To:* NANOG <nanog@nanog.org> *Subject:* BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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:<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.
--
Douglas Fernando Fischer Engº de Controle e Automação
Robert, This is not whether you should do it, but, should you have decided to, how to do it in the best possible way, without making mistakes someone else has made and learnt from. Regards, Jeff
On Sep 9, 2020, at 11:40, Robert Raszuk <robert@raszuk.net> wrote:
And use of BGP without IGP left and right when even today bunch of DCs can do just fine with current IGPs scaling wise is IMO not a good thing.
Thx R.
On Wed, Sep 9, 2020, 10:55 Jeff Tantsura via NANOG <nanog@nanog.org> wrote: I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example of “ab”use of ASN0 is a de-facto artifact (unfortunate one). My goal would be to provide a viable source of information to someone who is setting up a new ISP and has a very little clue as where to start. Do’s and don’t’s wrt inter-domain communities use.
I really enjoyed the difference RFC7938 (Use of BGP for Routing in Large-Scale Data Centers) made, literally 100s of companies have used it to educate themselves/ implemented their DC networking.
Cheers, Jeff
On Sep 9, 2020, at 10:04, adam via NANOG <nanog@nanog.org> wrote:
I don’t agree with the use of reserved ASNs, let alone making it BCP, cause it defeats the whole purpose of the community structure.
Community is basically sending a message to an AS. If I want your specific AS to interpret the message I set it in format YOUR_ASN:<community value>, your AS in the first part of the community means that your rules of how to interpret the community value apply.
Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of communities (or any other attribute for that matter) just doesn’t sit right with me (what’s next? multicast-ASNs that we can subscribe to?).
All the examples in Robert’s draft or wide community RFC, all of them use an example AS# the community is addressed to (not some special reserved AS#).
Also should something like this become standard it needs to be properly standardized and implemented as a well-known community by most vendors (like RFCs defining the wide communities or addition to standard communities like no_export/no_advertise/…). This would also eliminate the adoption friction from operators rightly claiming “my AS my rules”.
adam
From: NANOG <nanog-bounces+adamv0025=netconsultings.com@nanog.org> On Behalf Of Douglas Fischer via NANOG Sent: Tuesday, September 8, 2020 4:56 PM To: NANOG <nanog@nanog.org> Subject: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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:<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.
--
Douglas Fernando Fischer Engº de Controle e Automação
My advice to “someone who is setting up a new ISP and has a very little clue as where to start” would be just don’t and instead hire someone who’s well versed in this topic. But I see what you mean, RFC7938 was a good food for thought. But at the same time I’m sceptical, for instance would it help if BCP38 was an RFC? Would be nice for instance if the community could put together a checklist of things to consider for ISPs (could be in no particular order) (and actually there are such lists albeit concentrated around security) adam From: Jeff Tantsura <jefftant.ietf@gmail.com> Sent: Wednesday, September 9, 2020 9:52 AM To: adamv0025@netconsultings.com Cc: nanog@nanog.org Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example of “ab”use of ASN0 is a de-facto artifact (unfortunate one). My goal would be to provide a viable source of information to someone who is setting up a new ISP and has a very little clue as where to start. Do’s and don’t’s wrt inter-domain communities use. I really enjoyed the difference RFC7938 (Use of BGP for Routing in Large-Scale Data Centers) made, literally 100s of companies have used it to educate themselves/ implemented their DC networking. Cheers, Jeff On Sep 9, 2020, at 10:04, adam via NANOG <nanog@nanog.org <mailto:nanog@nanog.org> > wrote: I don’t agree with the use of reserved ASNs, let alone making it BCP, cause it defeats the whole purpose of the community structure. Community is basically sending a message to an AS. If I want your specific AS to interpret the message I set it in format YOUR_ASN:<community value>, your AS in the first part of the community means that your rules of how to interpret the community value apply. Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of communities (or any other attribute for that matter) just doesn’t sit right with me (what’s next? multicast-ASNs that we can subscribe to?). All the examples in Robert’s draft or wide community RFC, all of them use an example AS# the community is addressed to (not some special reserved AS#). Also should something like this become standard it needs to be properly standardized and implemented as a well-known community by most vendors (like RFCs defining the wide communities or addition to standard communities like no_export/no_advertise/…). This would also eliminate the adoption friction from operators rightly claiming “my AS my rules”. adam From: NANOG <nanog-bounces+adamv0025=netconsultings.com@nanog.org <mailto:nanog-bounces+adamv0025=netconsultings.com@nanog.org> > On Behalf Of Douglas Fischer via NANOG Sent: Tuesday, September 8, 2020 4:56 PM To: NANOG <nanog@nanog.org <mailto:nanog@nanog.org> > Subject: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' 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:<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. -- Douglas Fernando Fischer Engº de Controle e Automação
BCP38 is an RFC, 2827. It is a grand advise if you can: -find someone who is actually well versed -afford that someone. Personally - when in early 2000s I had to write complete community tagging design for a multi country network, I wish I had a “how to” Regards, Jeff
On Sep 9, 2020, at 15:35, adamv0025@netconsultings.com wrote:
My advice to “someone who is setting up a new ISP and has a very little clue as where to start” would be just don’t and instead hire someone who’s well versed in this topic. But I see what you mean, RFC7938 was a good food for thought. But at the same time I’m sceptical, for instance would it help if BCP38 was an RFC? Would be nice for instance if the community could put together a checklist of things to consider for ISPs (could be in no particular order) (and actually there are such lists albeit concentrated around security)
adam
From: Jeff Tantsura <jefftant.ietf@gmail.com> Sent: Wednesday, September 9, 2020 9:52 AM To: adamv0025@netconsultings.com Cc: nanog@nanog.org Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example of “ab”use of ASN0 is a de-facto artifact (unfortunate one). My goal would be to provide a viable source of information to someone who is setting up a new ISP and has a very little clue as where to start. Do’s and don’t’s wrt inter-domain communities use.
I really enjoyed the difference RFC7938 (Use of BGP for Routing in Large-Scale Data Centers) made, literally 100s of companies have used it to educate themselves/ implemented their DC networking.
Cheers, Jeff
On Sep 9, 2020, at 10:04, adam via NANOG <nanog@nanog.org> wrote:
I don’t agree with the use of reserved ASNs, let alone making it BCP, cause it defeats the whole purpose of the community structure. Community is basically sending a message to an AS. If I want your specific AS to interpret the message I set it in format YOUR_ASN:<community value>, your AS in the first part of the community means that your rules of how to interpret the community value apply. Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of communities (or any other attribute for that matter) just doesn’t sit right with me (what’s next? multicast-ASNs that we can subscribe to?). All the examples in Robert’s draft or wide community RFC, all of them use an example AS# the community is addressed to (not some special reserved AS#).
Also should something like this become standard it needs to be properly standardized and implemented as a well-known community by most vendors (like RFCs defining the wide communities or addition to standard communities like no_export/no_advertise/…). This would also eliminate the adoption friction from operators rightly claiming “my AS my rules”.
adam
From: NANOG <nanog-bounces+adamv0025=netconsultings.com@nanog.org> On Behalf Of Douglas Fischer via NANOG Sent: Tuesday, September 8, 2020 4:56 PM To: NANOG <nanog@nanog.org> Subject: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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:<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.
-- Douglas Fernando Fischer Engº de Controle e Automação
Reg the BCP38 vs RFC I guess is point in case (standard or best practice, the adoption is still low) Reg the community tagging design, Well it’s daily job of architects/designers to come up with new designs, standards and frameworks that can then be adopted by engineering/ops or automation system workflows or the business as a whole. Now would it be useful to have a reference design for various L2VPN options, or RR infrastructures, hub-spoke RT allocations, community tagging designs, or BGP input sanity checking, if nothing else like food for thought, sure… adam From: Jeff Tantsura <jefftant.ietf@gmail.com> Sent: Wednesday, September 9, 2020 6:01 PM To: adamv0025@netconsultings.com Cc: nanog@nanog.org Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' BCP38 is an RFC, 2827. It is a grand advise if you can: -find someone who is actually well versed -afford that someone. Personally - when in early 2000s I had to write complete community tagging design for a multi country network, I wish I had a “how to” Regards, Jeff On Sep 9, 2020, at 15:35, adamv0025@netconsultings.com <mailto:adamv0025@netconsultings.com> wrote: My advice to “someone who is setting up a new ISP and has a very little clue as where to start” would be just don’t and instead hire someone who’s well versed in this topic. But I see what you mean, RFC7938 was a good food for thought. But at the same time I’m sceptical, for instance would it help if BCP38 was an RFC? Would be nice for instance if the community could put together a checklist of things to consider for ISPs (could be in no particular order) (and actually there are such lists albeit concentrated around security) adam From: Jeff Tantsura <jefftant.ietf@gmail.com <mailto:jefftant.ietf@gmail.com> > Sent: Wednesday, September 9, 2020 9:52 AM To: adamv0025@netconsultings.com <mailto:adamv0025@netconsultings.com> Cc: nanog@nanog.org <mailto:nanog@nanog.org> Subject: Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example of “ab”use of ASN0 is a de-facto artifact (unfortunate one). My goal would be to provide a viable source of information to someone who is setting up a new ISP and has a very little clue as where to start. Do’s and don’t’s wrt inter-domain communities use. I really enjoyed the difference RFC7938 (Use of BGP for Routing in Large-Scale Data Centers) made, literally 100s of companies have used it to educate themselves/ implemented their DC networking. Cheers, Jeff On Sep 9, 2020, at 10:04, adam via NANOG <nanog@nanog.org <mailto:nanog@nanog.org> > wrote: I don’t agree with the use of reserved ASNs, let alone making it BCP, cause it defeats the whole purpose of the community structure. Community is basically sending a message to an AS. If I want your specific AS to interpret the message I set it in format YOUR_ASN:<community value>, your AS in the first part of the community means that your rules of how to interpret the community value apply. Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of communities (or any other attribute for that matter) just doesn’t sit right with me (what’s next? multicast-ASNs that we can subscribe to?). All the examples in Robert’s draft or wide community RFC, all of them use an example AS# the community is addressed to (not some special reserved AS#). Also should something like this become standard it needs to be properly standardized and implemented as a well-known community by most vendors (like RFCs defining the wide communities or addition to standard communities like no_export/no_advertise/…). This would also eliminate the adoption friction from operators rightly claiming “my AS my rules”. adam From: NANOG <nanog-bounces+adamv0025=netconsultings.com@nanog.org <mailto:nanog-bounces+adamv0025=netconsultings.com@nanog.org> > On Behalf Of Douglas Fischer via NANOG Sent: Tuesday, September 8, 2020 4:56 PM To: NANOG <nanog@nanog.org <mailto:nanog@nanog.org> > Subject: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?' 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:<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. -- Douglas Fernando Fischer Engº de Controle e Automação
I completely agree that there is value for people sharing different community structures that they have created for certain use cases. Such things are generally useful for both operators of any experience level. On Fri, Sep 11, 2020 at 8:08 AM <adamv0025@netconsultings.com> wrote:
Reg the BCP38 vs RFC I guess is point in case (standard or best practice, the adoption is still low)
Reg the community tagging design,
Well it’s daily job of architects/designers to come up with new designs, standards and frameworks that can then be adopted by engineering/ops or automation system workflows or the business as a whole.
Now would it be useful to have a reference design for various L2VPN options, or RR infrastructures, hub-spoke RT allocations, community tagging designs, or BGP input sanity checking, if nothing else like food for thought, sure…
adam
*From:* Jeff Tantsura <jefftant.ietf@gmail.com> *Sent:* Wednesday, September 9, 2020 6:01 PM *To:* adamv0025@netconsultings.com *Cc:* nanog@nanog.org *Subject:* Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
BCP38 is an RFC, 2827.
It is a grand advise if you can:
-find someone who is actually well versed
-afford that someone.
Personally - when in early 2000s I had to write complete community tagging design for a multi country network, I wish I had a “how to”
Regards,
Jeff
On Sep 9, 2020, at 15:35, adamv0025@netconsultings.com wrote:
My advice to “someone who is setting up a new ISP and has a very little clue as where to start” would be just don’t and instead hire someone who’s well versed in this topic.
But I see what you mean, RFC7938 was a good food for thought. But at the same time I’m sceptical, for instance would it help if BCP38 was an RFC?
Would be nice for instance if the community could put together a checklist of things to consider for ISPs (could be in no particular order) (and actually there are such lists albeit concentrated around security)
adam
*From:* Jeff Tantsura <jefftant.ietf@gmail.com> *Sent:* Wednesday, September 9, 2020 9:52 AM *To:* adamv0025@netconsultings.com *Cc:* nanog@nanog.org *Subject:* Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
I don’t think, anyone has proposed to use ‘’reserved ASNs” as a BCP, example of “ab”use of ASN0 is a de-facto artifact (unfortunate one).
My goal would be to provide a viable source of information to someone who is setting up a new ISP and has a very little clue as where to start. Do’s and don’t’s wrt inter-domain communities use.
I really enjoyed the difference RFC7938 (Use of BGP for Routing in Large-Scale Data Centers) made, literally 100s of companies have used it to educate themselves/ implemented their DC networking.
Cheers,
Jeff
On Sep 9, 2020, at 10:04, adam via NANOG <nanog@nanog.org> wrote:
I don’t agree with the use of reserved ASNs, let alone making it BCP, cause it defeats the whole purpose of the community structure.
Community is basically sending a message to an AS. If I want your specific AS to interpret the message I set it in format YOUR_ASN:<community value>, your AS in the first part of the community means that your rules of how to interpret the community value apply.
Turning AS#0 or any other reserved AS# into a “broadcast-AS#” in terms of communities (or any other attribute for that matter) just doesn’t sit right with me (what’s next? multicast-ASNs that we can subscribe to?).
All the examples in Robert’s draft or wide community RFC, all of them use an example AS# the community is addressed to (not some special reserved AS#).
Also should something like this become standard it needs to be properly standardized and implemented as a well-known community by most vendors (like RFCs defining the wide communities or addition to standard communities like no_export/no_advertise/…). This would also eliminate the adoption friction from operators rightly claiming “my AS my rules”.
adam
*From:* NANOG <nanog-bounces+adamv0025=netconsultings.com@nanog.org> *On Behalf Of *Douglas Fischer via NANOG *Sent:* Tuesday, September 8, 2020 4:56 PM *To:* NANOG <nanog@nanog.org> *Subject:* BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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:<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.
--
Douglas Fernando Fischer Engº de Controle e Automação
De-facto standards are as good as people implementing them, however in order to enforce non ambiguous implementations, it has to be de-jure (e.g. a standard track RFC). While I’m sympathetic to the idea, I’m quite skeptical about its viability. A well written BCP would be much more valuable, and perhaps when we get to a critical mass, codification would be a natural process, rather than artificially enforcing people doing stuff they don’t see value (ROI) in, discussion here perfectly reflects the state of art. Cheers, Jeff
On Sep 8, 2020, at 17:57, Douglas Fischer via NANOG <nanog@nanog.org> wrote:
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:<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.
-- Douglas Fernando Fischer Engº de Controle e Automação
On 9/Sep/20 10:03, Jeff Tantsura via NANOG wrote:
De-facto standards are as good as people implementing them, however in order to enforce non ambiguous implementations, it has to be de-jure (e.g. a standard track RFC). While I’m sympathetic to the idea, I’m quite skeptical about its viability. A well written BCP would be much more valuable, and perhaps when we get to a critical mass, codification would be a natural process, rather than artificially enforcing people doing stuff they don’t see value (ROI) in, discussion here perfectly reflects the state of art.
This. Mark.
Jeff Tantsura via NANOG wrote on 09/09/2020 09:03:
De-facto standards are as good as people implementing them, however in order to enforce non ambiguous implementations, it has to be de-jure (e.g. a standard track RFC). While I’m sympathetic to the idea, I’m quite skeptical about its viability. A well written BCP would be much more valuable, and perhaps when we get to a critical mass, codification would be a natural process, rather than artificially enforcing people doing stuff they don’t see value (ROI) in, discussion here perfectly reflects the state of art.
Last year the IETF published RFC 8642, "Policy Behavior for Well-Known BGP Communities" which described how the three well-known communities defined in RFC1997 ought to be interpreted. RFC1997 was published in 1996, 23 years prior, and the definitions looked pretty simple and unambiguous. Here's the opening paragraph:
The BGP Communities attribute was specified in [RFC1997], which introduced the concept of well-known communities. In hindsight, [RFC1997] did not prescribe as fully as it should have how well-known communities may be manipulated by policies applied by operators. Currently, implementations differ in this regard, and these differences can result in inconsistent behaviors that operators find difficult to identify and resolve.
I sympathise with the idea of standardised well-known communities, but if it takes us 23 years to tie down the semantics of three simple WKCs to the point that they behave consistently across vendors and operators, it's going to be a real struggle to define anything more complicated to the point that they end up doing what we want them to do, which is to say that they behave consistently across NOS implementations and different operator networks. Even mixing 16-bit communities and 32-bit communities for stuff like ixp route server no-export causes interoperability problems. Which gets evaluated first? Why? What happens if you get the order wrong? How can you integrate this into an existing routing policy configuration? These things look a bit academic until something breaks, at which point it becomes clear that even simple-looking stuff can be complicated and messy when it goes wrong. Nick
participants (12)
-
adamv0025＠netconsultings.com -
Arnold Nipper -
Chriztoffer Hansen -
Douglas Fischer -
Hunter Fuller -
Jeff Tantsura -
Mark Tinka -
Mike Hammett -
Nick Hilliard -
Owen DeLong -
Robert Raszuk -
Tom Beecher