Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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 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. >
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. 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.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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 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 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:, > 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 *On > Behalf Of *Douglas Fischer via NANOG > *Sent:* Tuesday, September 8, 2020 4:56 PM > *To:* NANOG > *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: > > > > So we could say that this is a de-facto standard. > > > > > > But the Policy equivalent to "Please, export these routes only to that > ASN" is very varied on all the IXPs or Transit Providers. > > > > > > With that said, now comes some questions: > > 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or > something like that, that would define 0: as "no-export-to" > standard? > > > > 2 - What about reserving some 16-bits ASN to use : > as "export-only-to" standard? > > 2.1 - Is important to be 16 bits, because with (RT) extended communities, > any ASN on the planet could be the target of that policy. > > 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. > > > > -- > > Douglas Fernando Fischer > Engº de Controle e Automação > >
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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 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. >
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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 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. > >
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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 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. >
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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 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: > > So we could say that this is a de-facto standard. > > > But the Policy equivalent to "Please, export these routes only to that > ASN" is very varied on all the IXPs or Transit Providers. > > > With that said, now comes some questions: > > 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or > something like that, that would define 0: as "no-export-to" > standard? > > 2 - What about reserving some 16-bits ASN to use : > as "export-only-to" standard? > 2.1 - Is important to be 16 bits, because with (RT) extended communities, > any ASN on the planet could be the target of that policy. > 2.2 - Would be interesting some mnemonic number like 1000 / 1 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. >
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Hi Douglas, Just FYI I have tried to capture most common use cases of communities and register them as part of a wide-community effort in IANA. https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02 That draft is pending standardization of wide-communities itself. You are obviously very welcome to either reuse some of this work or support it :) Kind regards, R. On Tue, Sep 8, 2020 at 5:58 PM 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: > > So we could say that this is a de-facto standard. > > > But the Policy equivalent to "Please, export these routes only to that > ASN" is very varied on all the IXPs or Transit Providers. > > > With that said, now comes some questions: > > 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or > something like that, that would define 0: as "no-export-to" > standard? > > 2 - What about reserving some 16-bits ASN to use : > as "export-only-to" standard? > 2.1 - Is important to be 16 bits, because with (RT) extended communities, > any ASN on the planet could be the target of that policy. > 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so. > > -- > Douglas Fernando Fischer > Engº de Controle e Automação >
