RE: "Tactical" /24 announcements
RPKI validity cover is incomplete. One way: add your own RTR records. They don't all have to come from the RPKI. Another way: Add route-policy to validate the origin-as. That requires a prefix-set. However, these prefix-sets are much smaller and the sum of them is smaller than the sum of prefix-sets you would use on your neighbor sessions.
Regards, Jakob. -----Original Message----- Date: Tue, 17 Aug 2021 09:22:01 +0300 From: Saku Ytti <saku@ytti.fi> 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 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
RPKI validity cover is incomplete. One way: add your own RTR records. They don't all have to come from
Oh, and your other issue. IOS-XR has two modes in which you can use RPKI validity. One is where the router automatically uses the validity. The other mode is where you use the validity in any way you want in route-policy. Regards, Jakob. -----Original Message----- From: Jakob Heitz (jheitz) Sent: Tuesday, August 17, 2021 9:59 AM To: nanog@nanog.org Subject: RE: "Tactical" /24 announcements the RPKI. Another way: Add route-policy to validate the origin-as. That requires a prefix-set. However, these prefix-sets are much smaller and the sum of them is smaller than the sum of prefix-sets you would use on your neighbor sessions. Regards, Jakob. -----Original Message----- Date: Tue, 17 Aug 2021 09:22:01 +0300 From: Saku Ytti <saku@ytti.fi> 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 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
participants (1)
-
Jakob Heitz (jheitz)