Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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"?'
On 9/Sep/20 15:09, Mike Hammett wrote: > If history has taught us anything, everything we do will be ignored by > those that most need it. :-) Touche :-)... Mark.
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": "So far this is not blowing my skirt up, gentlemen. Don't you have anything remotely substantial, Harry? Do you have any HARD DATA?" https://youtu.be/-KHkltl22V4?t=73 :-)... Mark.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
On 9/Sep/20 14:29, Chriztoffer Hansen wrote: > Why not? As a service offering, it makes total sense. Yes, makes total sense. So why aren't jumping all over it? > > Thou, generally I agree with you. Trust, but verify any received > announcement conforms to a base-set of expectations. Discard > non-conforming. This. But as always, the plan is what happens. 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. 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" > *To: *"Mike Hammett" > *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. >
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.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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"?'
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.
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.
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
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"?'
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"?'
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: Centurylink having a bad morning?
On 5/Sep/20 18:46, Randy Bush via NANOG wrote: > fracking dmark illegal header hacking :( > > apologies No worries :-). Mark.
Re: Centurylink having a bad morning?
On 5/Sep/20 17:58, Randy Bush via NANOG wrote: > spoken like a tier two Even "Tier 1's" aren't present everywhere :-)... Although I'm not sure whether having presence in every city means you are a Tier-anything either... Mark.
Re: Centurylink having a bad morning?
On 4/Sep/20 23:41, Tomas Lynch wrote: > > Oh, yes! Let's not start another "what's a tier one" war! Oh no, let's :-). We get over here in Africa as well. Local operators either calling themselves Tier 1, or being called a Tier 1. Nonsensical. Years back, our Marketing team asked me to comment on the use of "Tier" for our literature. You can probably imagine what I said :-). For me, it's simple - you are present in X cities or Y cities. Tier is useless because the Internet does not come from a single country or a single operator. And saying a network is "big" or "small" is subjective to everyone's perspective, so that doesn't help either. So you're present here, and present there. That's it. It's 2020 :-). Mark.
[no subject]
---BeginMessage--- On 7/May/15 15:16, Phil Bedard wrote: Forgot to send this yesterday… We use them in our networks along with ASR9Ks and MXs. There are a lot of them deployed around the world doing very similar things as ASRs and MXs. The config is more like Juniper than Cisco IMHO. Being kind of the “3rd” vendor they have a tendency to implement features proposed by both Cisco and Juniper faster than Cisco and Juniper when proposed by the other vendor. For instance Segment Routing is a Cisco thing, but ALU has already implemented it in their latest 13.0 software, Juniper is sort of dragging their feet on it because it’s a Cisco thing. Same goes for NG-MVPN (BGP signaled multicast VPN). Cisco dragged their feet on it because it was a Juniper thing, ALU had no issues implementing it much sooner. Most of ALUs innovation is on the MPLS services side. We use them for business VPN (L2 and L3) but the underlying protocols are all standard stuff and interoperate with everything else. I went to an ALU lab last year to look at some of their kit. Very impressive in the BNG space, and they've had a good reputation for that even before I laid hands on one. The CLI is pretty neat, and easy to learn. You're right about ALU not being fussy (but being faster) on implementing features that Cisco and Juniper squabble over. We have just received a test router we have for the next couple of months, and may consider them for some roles in the network if we are happy. My only gripe with ALU is their Metro-E offering is currently not where I'd like it to be. Mark. ---End Message---
