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?” :-)… Mark.
Touche :-)… 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.
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
Chriztoffer Hansen via NANOG
Sent: Wednesday, September 9, 2020 1:29 PM> 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
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.
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.
Yeah, I’ll steer clear of that one :-)… I don’t know. If they are here, they can chime in. Mark.
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.
Great excuse 
Regards,
Jeff
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
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
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.
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.
To the extent that communities are standardized, they’re supposed to be ASN:Community, so 0: 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
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
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
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