plea for comcast/sprint handoff debug help

Fri Nov 6 15:14:45 UTC 2020

On Fri, Nov 6, 2020 at 1:28 AM Christopher Morrow <morrowc.lists at gmail.com>
wrote:
<snip>

> 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[0] 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.

Tony


> 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
> troubles.
>
<more snip>

> >
> > > 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...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201106/209d8f63/attachment.html>