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.
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 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.
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.
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
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
This.
Mark.
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
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.
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
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
I don’t think the OP cares about what you do internally.
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.
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. 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.
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.
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.
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.
More operators don’t use communities internally than the number of operators that do.
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.
If history has taught us anything, everything we do will be ignored by those that most need it. 