All, please be assured that, thanks to all PRs, cases, etc, it’s on our (Junipers) Radar and we are looking into it.
Cheers, Melchior > Op 1 okt. 2019 om 18:20 heeft Weber, Markus <[email protected]> het > volgende geschreven: > > Dear all, > > Juniper seems to implement by now just RFC6483 behaviour for ROV > (that is, if there's an AS_SET in the path, the origin AS can't > be determined and as such validation result is always unknown). > Checked on 16.1R7-S5/17.3R3-S5/18.2R3-S1. > > RFC6907 (7.1.8-7.1.12 - considering RFC6472) clarifies this: If > there's a covering ROA and the announcement contains an AS_SET, > it should be considered invalid (no matter if there's a ROA for > e.g. a member of the AS_SET (apparently IOS XR behaviour)). > Otherwise it's unknown (if there's an AS_SET). > > Our case was closed with "At this point, there isn't a plan on > supporting RFC6907". We try to get this registered as EH request, > but it can't harm if more people request this and get some higher > attention from Juniper on this. > > What's the point? Are you doing this rPKI validation thing? Are > you seeing & accepting for example 194.45.182.0/24 and / or > 194.45.183.0/24? You shouldn't ... luckily these are just test > prefixes ... > > ROAs 194.45.182.0/23-23,286 > ROA: 194.45.183.0/24-24,12469 > > 194.45.182.0/24: .* 286 2858 {517} > 194.45.183.0/24: .* 286 2858 {517 12469} > > > Thanks for your time reaching out to your Juniper SE / AM. > Markus > > -- > AS286 - for the time being > > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
