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
Job,
> Op 1 okt. 2019 om 23:12 heeft Job Snijders het volgende
> geschreven:
>
> I think we'll also all agree that no fallback to the old behavior is
> needed, as the old behavior is not useful.
Agreed on the usefulness part, but would there be unwanted situations or
behavior someone could ru
On Tue, Oct 01, 2019 at 10:50:29PM +0200, 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.
I think we'll also all agree that no fallback to the old behavior is
needed, as the old behavior is not useful
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 het
> volgende geschreven:
>
> Dear all,
>
> Juniper seems to implement by now just RFC6483 behaviour for ROV
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) clarifi
Hello Kamal
thanks for sharing your valuable insight. Very interesting to see what happens
when one tries to upgrade hundreds of Juniper devices.
Upon reading your mail one could get the impression that the upgrade woes and
all the bugs+regressions are a structural problem related to how Junos i
6 matches
Mail list logo
