Re: [Sidrops] Comments on draft-ietf-sidrops-validating-bgp-speaker

[Jeff Wheeler <[e-mail]>]

On Wed, Feb 14, 2018 at 5:22 PM, Aris Lambrianidis
<[e-mail]> wrote:
> I see two prongs in your email, a technical one (signalling method) and
> a "political" one (for
> lack of a better term), i.e. whether this draft is misguided in principle.

I think your draft has a fair chance of progressing because it's clear
some IXPs (and their members) want route-servers to propagate invalid
paths, and if they are going to keep doing that, it is easy to
understand why the IXPs feel obligated to signal it somehow.  Once you
decided to signal it, a standard is sensible.

Basically, I see you are cutting your own hand.  I think that's stupid
but I support your plan to standardize the type of knife you use.
You're going to spill blood anyway; your members must be demanding it.


For the above reason, I would rather focus on the implementation details.


I'd like to reiterate that the new propagation scope defined by your
draft is a change to the existing, standardized behavior of BGP
Extended Communities.

The nature of this change almost dictates that you also specify a BGP
Capability Code and define a behavior for what you should do when
receiving one of these extcomm from a neighbor that has not signaled
the capability (probably drop the extcomm since its origin is unknown
at that point?)  So now you have a new parameter in the connection
process (no big deal) and new code when parsing and propagating
extcomms.

In fact, you might as well define some kind of router-hops-limit and
as-hops-limit for extcomms because the implementation cost (in
software) of that is essentially the same as what you've already
proposed and the new kind of scope would have other uses to operators.

So the current draft is more complex than it really needs to be.  A
lot of implementation obstacles can be removed by simply using a BGP
Well-Known Community.  If operators want to use your idea they will
need to configure their router, but they would not need to wait on
their vendor for new software.  On your side, you are already using a
community to signal so this clearly works fine.

I understand the long-term advantage hoped for by limiting the
propagation scope, but I think it is a more ambitious and costly plan
than the authors realize.  I ask them to back off from the extcomm, or
in the alternative, approach it as a new propagation behavior to
extcomms which can then be re-used.

-- 
Jeff S Wheeler <[e-mail]>