nanog mailing list archives
Re: "Tactical" /24 announcements
From: Tim Raphael <raphael.timothy () gmail com>
Date: Tue, 17 Aug 2021 18:36:03 +1000
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 () 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 () psg com> wrote: hi jakob, i am confused betweenThere is no expansion to prefix-set.and your earlierWe 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
Current thread:
- Re: "Tactical" /24 announcements, (continued)
- Re: "Tactical" /24 announcements Mark Tinka (Aug 13)
- Re: "Tactical" /24 announcements Mark Tinka (Aug 13)
- Re: "Tactical" /24 announcements Mark Tinka (Aug 13)
- Re: "Tactical" /24 announcements Mark Tinka (Aug 11)
- RE:"Tactical" /24 announcements Jakob Heitz (jheitz) via NANOG (Aug 14)
- Re: "Tactical" /24 announcements Saku Ytti (Aug 14)
- Re: "Tactical" /24 announcements Mark Tinka (Aug 15)
- RE: "Tactical" /24 announcements Jakob Heitz (jheitz) via NANOG (Aug 16)
- Re: "Tactical" /24 announcements Randy Bush (Aug 16)
- Re: "Tactical" /24 announcements Saku Ytti (Aug 16)
- Re: "Tactical" /24 announcements Tim Raphael (Aug 17)
- Re: "Tactical" /24 announcements Randy Bush (Aug 17)
- Re: "Tactical" /24 announcements Ben Maddison via NANOG (Aug 17)
- Re: "Tactical" /24 announcements Randy Bush (Aug 17)
- Re: "Tactical" /24 announcements Tim Raphael (Aug 17)
- Re: "Tactical" /24 announcements Ben Maddison via NANOG (Aug 19)
- Re: "Tactical" /24 announcements David Bass (Aug 18)
- Re: "Tactical" /24 announcements Ben Maddison via NANOG (Aug 19)
- Re: "Tactical" /24 announcements David Bass (Aug 19)
- Re: "Tactical" /24 announcements Ben Maddison via NANOG (Aug 19)
- Re: "Tactical" /24 announcements Saku Ytti (Aug 14)