Subject: [sidr] docco changes from minutes

From: Randy Bush <[email-masked]>
Date: Wed, 23 May 2012 08:11:59 +0900

so i reviewed the minutes from last month, looking for what i had to hack
in the docs i edit.  i found very little.  essentially

    <t>A prudent operator will pre-provision each router's 'next' key in
      the RPKI so that, in case of compromise of the current key, there
      is no propagation delay for provisioning the new key.</t>

and

    <t>The operator should be aware that BGPsec, as any other policy
      change, can cause traffic shifts in their network.  And, as with
      normal policy shift practice, a prudent operator has tools and
      methods to predict, measure, modify, etc.</t>

surely there was more.  help!!!

randy

---

From: "George, Wes" <[email-masked]>
Date: Wed, 23 May 2012 08:34:37 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randy Bush
>
> so i reviewed the minutes from last month, looking for what i had to hack in
> the docs i edit.

> surely there was more.  help!!!

[WEG] I have some notes implying I owe you text, but one of them is a bit cryptic through the filter of waiting too long after the meeting to look at it, perhaps it'll make sense if we both stare at it?

        Send Randy text about *why* you should drop invalid

        Origin ops/ BGP Sec ops
        Text - Deploy (upgrade code),
        apply policy just to tag with a community,
        then do analysis to ensure it's doing what you expect,
        then deploy policy to actually do things like drop invalid, prefer valid over unknown, etc."

I think the former is reference to a comment I made saying that if we were recommending (SHOULD? Or MUST?) that invalid be dropped, rather than simply de-preffed, we needed to spend some time explaining why (what badness can ensue if you don't drop). You wanted text, but I'm not totally sure that I know the complete rationale well enough to supply said text. Is it just a matter of the risk of eventually using an invalid route if the better options go away, or is there more to it?

The latter looks to me like a deployment guideline to address the concerns that I think Brian brought up about OV/BGPSec potentially creating non-trivial changes to routing during deployment. I can flesh that text out a bit if people agree that it's useful to add.

Thanks,
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 May 2012 22:51:09 +0900

> Send Randy text about *why* you should drop invalid

i actually understand this.  it's the jgs paris aha.  thanks!

if you have a roa
   10.0.0.0/16-24  42
and you get announcements
   10.0.0.0/16     42
   10.0.666.0/24  666
if you do not drop the invalid 10.0.666.0/24, then longest match will
send packets to 666

>         prefer valid over unknown, etc." 

this i do not follow.

> The latter looks to me like a deployment guideline to address the
> concerns that I think Brian brought up about OV/BGPSec potentially
> creating non-trivial changes to routing during deployment. I can flesh
> that text out a bit if people agree that it's useful to add.

i think i covered that with the new traffic paragraph.

thanks!!!

randy