[j-nsp] Please push Juniper to implement RFC6907

[Weber, Markus]

Melchior Aelmans wrote:
> All, please be assured that, thanks to all PRs, cases, etc, it’s on
> our (Junipers) Radar and we are looking into it.

Thanks, looking forward to see this showing up in the very near future/
with the next updates of all current in-use releases.

> Agreed on the usefulness part, but would there be unwanted situations
> or behavior someone could run into if we would ‘flip the switch’? I’m
> looking for possible impact due to changing behavior. 

Count the number of AS_SETs seen in the DFZ, reduced to "covered by a 
ROA". Consider there's RFC6472, which recommends not to use AS_SETs
anymore. Then think of how many networks would miss the new "knob" to
enable RFC6907 behaviour and by not enabling, leaving the door open
for not-so-nice activities to bypass ROV.

I think most/all of us would already drop them without questioning.
The brave of us would even drop routes with AS_SETs, if there would
be a way to easily match them. And I'm sure, the ones doing ROV would
drop routes -with AS_SET in the path and covered by a ROA- to mimic
RFC6907 behaviour ... (but this requires two things not available -
matching AS_SET and covered by a ROA).

I'm almost willing to bet, there won't be any cases because of the 
changed behaviour. Maybe a few because people don't understand the 
reason for the invalid in first place ... (BTW: maybe also time to
change the logging within traceoptions, as AS_SETs and empty as-paths
seem to both log "as-set detected, validation result unknown".)

You still can provide a disable-rfc6907 option, but don't have the
default be "unsecure". 

Thanks again,
Markus