"Tactical" /24 announcements

Tue Aug 17 08:36:03 UTC 2021

I quite like this approach as well - for those that would like to do more complicated policy logic off-box, the RTR architecture very much lends itself to that.

JNPR already has accessible APIs (JET-based / RPC) you can leverage to push configuration into the ephemeral database or be called on certain events (e.g. prefix learn). This, however comes with the acceptance of quite a few other risks. RTR could be used to signal other prefix options which would potentially remove the risks of dealing with the ephemeral config construct for certain use-cases, e.g. complex peer prefix filtering. 

- Tim

> On 17 Aug 2021, at 16:24, Saku Ytti <saku at ytti.fi> wrote:
> 
> I share your confusion Randy. It seems like perhaps Jakob answered a
> slightly different question and his answer is roughly.
> 
> a) Use this as-set feature to ensure valid set of ASNs from given peer
> b) Validate prefix using RPKI (I'm assuming with rejecting unknowns
> and invalids)
> c) Don't punch in prefix-lists anywhere
> 
> Which in theory works, but in practice it does not, as RPKI validity
> cover is incomplete.
> 
> Somewhat related, when JNPR implemented RTR the architecture was
> planned so that the RTR implementation itself isn't tightly coupled to
> RPKI validity. It was planned day1 that customers could have multiple
> RTR setups feeding prefixes and the NOS side could use these for other
> purposes too. So technically JNPR is mostly missing CLI work to allow
> you to feed prefix-lists dynamically over RTR, instead of punching
> them in vendor-specific way in config.
> 
> I really hope JNPR does that work, I really like the appeal of doing
> things off-box and using the same protocol to talk to on-box. Also,
> give me gRPC/protobuf route policy API, so I can write my route-policy
> in a real programming language once for all my NOS.
> 
> 
>> On Mon, 16 Aug 2021 at 20:32, Randy Bush <randy at psg.com> wrote:
>> 
>> hi jakob,
>> 
>> i am confused between
>> 
>>> There is no expansion to prefix-set.
>> 
>> and your earlier
>> 
>>>> We have introduced the scalable as-set into the XR route policy language.
>>>> as-path-set does not scale well with 1000's of ASNs.
>>>> Now, you don't need to expand AS-SET into prefix-set, just enter it directly.
>> 
>> expanding AS-SET into prefix filters is exactly what we do.
>> 
>> ```
>> % peval -s RIPE AS-RG-SEA
>> ({198.180.153.0/24, 198.180.151.0/24, 147.28.8.0/24, 147.28.9.0/24, 147.28.10.0/24, 147.28.11.0/24, 147.28.12.0/24, 147.28.13.0/24, 147.28.14.0/24, 147.28.15.0/24, 147.28.4.0/24, 147.28.5.0/24, 147.28.6.0/24, 147.28.7.0/24, 147.28.2.0/24, 147.28.3.0/24, 147.28.0.0/23, 45.132.188.0/24, 45.132.189.0/24, 45.132.190.0/24, 45.132.191.0/24})
>> ```
>> 
>> i do not see how to get around this.  clue bat please
>> 
>> randy
> 
> 
> 
> -- 
>  ++ytti