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.