>> 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?" where do you see "destroying" your AS? my only guess is that o you have not read the spec or any documentation on it, and o you triggered on the phrase "path stripping" fwiw, path stripping is removing the bgpsec gorp from a bgpsec path and rendering a classic bgp4 path to hand to a bgp listener who does not understand bgpsec. no ASs are harmed in the process. randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
