plea for comcast/sprint handoff debug help
ttauber at 1-4-5.net
Fri Nov 6 15:14:45 UTC 2020
On Fri, Nov 6, 2020 at 1:28 AM Christopher Morrow <morrowc.lists at gmail.com>
> I think a way forward here is to offer a suggestion for the software
> folk to cogitate on and improve?
> "What if (for either rrdp or rsync) there is no successful
> update in X of Y attempts,
> attempt the other protocol to sync down to bring the remote PP back
> to life in your local view."
100% Please do this.
I also agree with Job's pleas to consider this work as part of the plath
outlined in the RSYNC->RRDP transition draft mentioned below.
> This both allows the RP software to pick their primary path (and stick
> to that path as long as things work) AND
> helps the PP folk recover a bit quicker if their deployment runs into
> > > This is a tradeoff. I think that protecting against replay should be
> > > considered more important here, given the numbers and time to fix
> > > HTTPS issue.
> > The 'replay' issue you perceive is also present in RRDP. The RPKI is a
> > *deployed* system on the Internet and it is important for Routinator to
> > remain interopable with other non-nlnetlabs implementations.
> > Routinator not falling back to rsync does *not* offer a security
> > advantage, but does negatively impact our industry's ability to migrate
> > to RRDP. We are in 'phase 0' as described in Section 3 of
> > https://tools.ietf.org/html/draft-sidrops-bruijnzeels-deprecate-rsync
> > Regards,
> > Job
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NANOG