Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020

[Christopher Morrow <[e-mail]>]

On Wed, Sep 2, 2020 at 1:46 PM Randy Bush <[e-mail]> wrote:
>
> of course, i have no idea what the authors meant
>
> > 1) I think some of the friction here is the use of eBGP in the
> > document. This particular quote:
> >    (section 4)
> >     "(including a trusted EBGP peer for
> >    instance controlled by the same operator as lined out in Section 3)"
> >    PERHAPS this means 'confed boundary' not 'eBGP' ?
>
> yes, confed is ebgp.  but there are providers with multiple ASs which
> might trust eachother, e.g. the classic 70[1-4]

Sure, but I think confed boundary passes non-transitive communities...
so that should 'just work'.
For cases of: "my 2 asn are not confed, but mine and I trust myself"
I'd just signal across the boundary with some set of communities
outside this set... heck, you probably have to
already do that today, so this is just par-for-the-course. (I would
think anyway)

> > I think leaking this outside your ibgp (or confed) boundary changes
> > from having a simple metric system to a mess.
> >   If you want this for internal debug/metrics great.
> >   If you want your iBGP neighbors to perform validation on the routes
> > because the edge-speaker skipped out on that... ok.
> >   If you want to send this knowledge along to your external peers, no.
> > Why wouldn't they just perform BGPSEC validation on their own?
>
> lack of horsepower, expecially as the use case seems to be bgpsec

Sure, that was the reason the original speaker tacked on the community,  right?
the next neighbor though may not be in the same bind?

> randy