[c-nsp] RPKI extended-community RFC8097

[Ben Maddison]

Hi Robert,

On Sat, 2020-04-18 at 18:02 +0200, Robert Raszuk wrote:
> Hi Ben,
> 
> On XE and Classic:
> > 1. you can only preform validation on eBGP-received routes;
> > 2. any iBGP-received route will get marked "Valid" unless it has a
> > 8097
> > extcomm to the contrary; and
> > 2. bestpath selection will prefer "Valid" to "Unknown", at the
> > first-
> > step in the selection process.
> > 
> 
> Yes that is exactly the default dumb behaviour. And frankly these
> days I am
> not sure who to even talk in Cisco with about XE BGP :)
> 
I found (apparently) the right person about a year back, and explained
the design problems with the implementation.
That exchange has gone cold and TBH I've given up trying to explain how
to do their job to them.

Mark says he's having more luck down that same avenue. We'll see...
 
> Thus, without 8097 extcomms to mark validation status, you get a
> > forwarding loop for every prefix that a) you learn at two-or-more
> > ASBRs
> > and b) has no covering ROA.
> > That's the majority of the DFZ table for any multihomed AS.
> > 
> 
> Well that one I do not think is going to be always the case. It may
> be if
> your ASBRs are also RRs or you enable best external or add-paths.
> 
I expect you're probably correct. We run add-paths, and didn't test any
scenarios without it.
I'd expect that for most reasonable size networks, some mechanism to
propagate non-best paths is a fundamental requirement nowadays, so
probably comes down to the same thing in the real world.

> In the described case I just tested this and one ASBR will use local
> EBGP
> path as best and the other one IBGP learned which pretends to be
> valid. So
> there is no forwarding loop. If it would always be one perhaps cisco
> regression testing would fail :)
> 
Hahaha.
It mostly feels like the test suite nowadays is just
    assert self.version > releases[-1].version

Maybe your faith is stronger? ;-)

> In the mean time adding the knob  "announce rpki state" is the way to
> go.
> 
Yup. And to avoid surprises, should be the first command entered when
playing with this stuff.

Cheers,

Ben