Subject: [sidr] Interim Meeting Notes / Participation modes / wiki updated

From: Chris Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 13:22:25 -0400

Howdy folks,
For those interested in the Apr 30 Interim meeting, we updated the wiki:
  <http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430>

to include as much as we currently can say about the
location/agenda/remote-participation-foo. I believe that the intent is
to run the meeting as a completely virtual meeting, with some folks
localized in space/time as space permits.

We attempted to expound on the questions Arturo and Danny had in the
draft-agenda announcement with the wiki content. If there are further
questions please ask.

-chris
<co-chair>

---

From: Arturo Servin <[email-masked]>
Date: Wed, 11 Apr 2012 23:25:42 +0200

Chris,

	For the agenda item: "Deployment Discussion -> Discuss the need, and publication location/method, for documentation that details rollout of SIDR technologies in an operational network." Are we going to discuss what Tim suggested in his e-mail on March 30th (subject:  rpki repository and validation issues). I think he pointed out three valid points to discuss (at least start with the first 2 as he suggested):

	"(1) enumerate the problems that we see, and (2) refine a list of requirements for improvement, and then (3) find ways forward to address these requirements, without breaking the existing infrastructure".

	Is that the intention of the agenda item? Or are you planning to discuss something else?

Cheers,
.as

On 11 Apr 2012, at 19:22, Chris Morrow wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Apr 2012 10:15:41 +0900

> For the agenda item: "Deployment Discussion -> Discuss the need, and
> publication location/method, for documentation that details rollout of
> SIDR technologies in an operational network." Are we going to discuss
> what Tim suggested in his e-mail on March 30th

this is indeed of interest, and very few are actually measuring and
testing, as opposed to blathering on, about it.  but, as i said
previously, i do not think this is an urgent item as we have
considerable time to work on it and the current documented methods will
hold us for a while.

i am more interested in questions about incremental deployment of origin
validation and bgpsec, possible loose ends (confeds, as migration), and
misunderstandings (not by those who clearly have not actually read the
docs).

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 22:16:09 -0400

>        For the agenda item: "Deployment Discussion -> Discuss the need, and publication location/method, for documentation that details rollout of SIDR technologies in an operational network." Are…

Actually no, Tim wanted to be able to present/be-in-person so the next
time he can do that is the coincident meeting with IETF in Vancouver,
BC.

This is really:
  "Do we need some documentation about deployment, is that an IETF
document? a BCOP/etc from some *nog, something hosted on
psg.com/rpki.net/as701.net/geocities.com"

and:
  "What is the content of this? three basic deployment walk-throughs?
FAQ about each part of a deployment? Something else?"

or, is the answer much shorter: "This is all quite simple, people will
just figure it out... done." (this I think is unlikely, but... who
knows)

-Chris

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 12 Apr 2012 16:38:05 +0200

Hi,

> time he can do that is the coincident meeting with IETF in Vancouver,

Indeed, I can't make the 30 April interim meeting (not even remote). And it's also too short notice to bring more real measurements and experience (& measurements) from piloting possible alternatives to the table.

I agree with Randy (if I understand his point correctly) that measurements are needed to substantiate any discussion about the problems and possible alternatives. So... we actually plan to work on this over the following weeks (after the RIPE meeting):

- Add an automated feedback feature to our validator so that we can get statistics from wherever people run it (if they enable the feature). We're thinking of measuring:
   = average time to validate enabled TAs
   = frequency of rsync repositories being unavailable
   = frequency of validation corner cases occurring because we get a repo *while it is being updated* (eg mft out-of-sync with some object)
   = I am open to suggestions of other stuff to measure..

- Do a quick pilot implementation of some ideas:
   = Use an rss like notification mechanism to alert RPs of updates
   = Use http to fetch *consistent* deltas
   = And then do the same measurements as above and possibly more we can think of (like some controlled load stressing)

Of course there are lots of details involved here that are interesting to discuss with other RP implementers, RPKI publishers and the sidr wg at large, but... we feel that at this stage we want to mature and try out our ideas first so that when we bring this to the table we'll have a reasonable idea of whether it actually works in real code and helps to solve the real issues that we see. In short: we want to invest some energy in trying it out first, and then discuss more, rather than the other way around..

Planning can always change, but it looks like we should be able to do this without spending too many of our resources and in time to report about it in Vancouver.

For the time being we will use the list of problems and requirements that I formulated as a guideline for this pilot, but I am well aware that that list is subject to change when it's discussed in more detail in sidr on-list or at a meeting..

Tim

---

From: Arturo Servin <[email-masked]>
Date: Thu, 12 Apr 2012 20:59:56 -0300

There has been a lot of discussion about different topics related, I wasn't sure what we were going to discuss.

	Thanks for clearing this out.

Regards,
as

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 12 Apr 2012 20:03:14 -0400

> sure what we were going to discuss.

hoping to actually get a running list started of 'topics that need
time for discussion', perhaps on the wiki even :)

> Thanks for clearing this out.

trying my best :)

> publication location/method, for documentation that details rollout of SIDR
> technologies in an operational network." Are we going to discuss what Tim
> suggested in his e-mail on March 30th (subject:  rpki repository and
> validation issues). I think he pointed out three valid points to discuss (at
> least start with the first 2 as he suggested):
>
>
>
> Indeed, I can't make the 30 April interim meeting (not even remote). And
> it's also too short notice to bring more real measurements and experience (&
> measurements) from piloting possible alternatives to the table.
>
>
> I agree with Randy (if I understand his point correctly) that measurements
> are needed to substantiate any discussion about the problems and possible
> alternatives. So... we actually plan to work on this over the following
> weeks (after the RIPE meeting):
>
> - Add an automated feedback feature to our validator so that we can get
> statistics from wherever people run it (if they enable the feature). We're
> thinking of measuring:
>    = frequency of validation corner cases occurring because we get a repo
> *while it is being updated* (eg mft out-of-sync with some object)
>    = And then do the same measurements as above and possibly more we can
> think of (like some controlled load stressing)
>
> Of course there are lots of details involved here that are interesting to
> discuss with other RP implementers, RPKI publishers and the sidr wg at
> large, but... we feel that at this stage we want to mature and try out our
> ideas first so that when we bring this to the table we'll have a reasonable
> idea of whether it actually works in real code and helps to solve the real
> issues that we see. In short: we want to invest some energy in trying it out
> first, and then discuss more, rather than the other way around..
>
> Planning can always change, but it looks like we should be able to do this
> without spending too many of our resources and in time to report about it in
> Vancouver.
>
> For the time being we will use the list of problems and requirements that I
> formulated as a guideline for this pilot, but I am well aware that that list
> is subject to change when it's discussed in more detail in sidr on-list or
> at a meeting..
>
>
> Tim
>
>