Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Christopher Morrow <[e-mail]>]

On Tue, Jan 3, 2017 at 6:31 PM, Randy Bush <[e-mail]> wrote:

> >> ok, i have had coffee.
> >>
> >> as a bif gedanken experiment, posit a global registry where r0 can say
> >> "i can speak bgpsec."  i am a distant r1 and receive an unsigned path
> >> with r0 in it.
> >>   o did someone before r0 on the path not speak bgpsec, so the path was
> >>     never signed?
> >>   o did someone between us not speak bgpsec, so the path was stripped?
> >>   o was there a monkey in the middle?
> >>
> >> i think we did discuss this problem space, and decided that, as long as
> >> we allow islands of partial deployment, and therefore path stripping,
> >> the monkey is on our back.  we might have been wrong in this; but even
> >> with coffee i do not see a way out.
> >>
> >> and i do not think the idea of partial path signing, r0 signing a
> >> received unsigned path, would have helped a lot.
> >>
> >> it is not clear to me that this is a space where the ops doc can help
> >> much.  i am open to ideas.
> >
> > I'm currently not using bgpsec (or rpki for that matter).  BUT, if there
> > was no path to go back, I would never ever use it.  Destroying my ASN
> > because I wasn't ready to migrate is a straight-up No Go(tm).
> >
> > Mistakes will be made.  Rolling back will happen.  Preventing rolling
> > back will kill the baby and will guarentee this will never be rolled
> > out.
>
> what do you mean by "no path to go back" and "rolling back?"
>
>
perhaps to paraphrase peter's question/comment: He's worried that the
proposed standard may leave a user of the technology in a position where
'old bgp' is not functioning for him.

I believe we ran over this horse several times in the WG and other places,
basically to provide a path from 'today' to 'tomorrow' the ability to
co-exist is required. On day-0 no bgpsec exists, on day-1 you (peter) turn
up your first bgpsec peer  pop champagne and rejoice... On day-2 you turn
up 200 more... then on day-10 you realize things are not working so you
disable bgpsec via some knob on your vendors' devices...

All along both 'old bgp' and 'new bgpsec bgp' are working alongside each
other. Randy's correct that the protocol / etc specs cover this sort of
thing... fairly well.

Because 'there are no flag days' on the intertubes, we have to plan for
co-existence... Just like ipv6 did... wait, I mean dnssec. ;)

-chris