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 <s...@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 <ra...@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
