[20:50:05] --- thomas.heide.clausen@gmail.com has joined
[20:53:38] <thomas.heide.clausen@gmail.com> (since these logs are kept, I'll try to do some notes, even though there's nobody here yet....)
[20:54:20] <thomas.heide.clausen@gmail.com> Acee: agenda-bashing, some minor reorg of the agenda.
[20:55:40] <thomas.heide.clausen@gmail.com> Joe Macker: IPSec usage issues - maybe there will be permission to turn seq. no on to do replay protection....
[20:55:50] <thomas.heide.clausen@gmail.com> Where would this be discusseD?
[20:56:14] <thomas.heide.clausen@gmail.com> Acee: bis on RFC...ehh, missed the #
[20:56:37] <thomas.heide.clausen@gmail.com> Joe: there might be more than one group wanting to do this.
[20:57:02] <thomas.heide.clausen@gmail.com> Acee: WG status presentation.
[20:57:20] <thomas.heide.clausen@gmail.com> Short time since last IETF, not a lot seems to have happened. Waiting on people to do things.
[20:57:28] <thomas.heide.clausen@gmail.com> No new RFCs
[20:58:09] <thomas.heide.clausen@gmail.com> ospf-mib in RFC editors queue
[20:58:28] <thomas.heide.clausen@gmail.com> Two RFCs in requested publication state - still comments from IESG that need to be addressed.
[20:58:38] <thomas.heide.clausen@gmail.com> Should be published in short order.
[20:59:06] <thomas.heide.clausen@gmail.com> MT & cap: comments from IESG, worked on. Wanting to do interop, but not done yet.
[20:59:37] <thomas.heide.clausen@gmail.com> Traffic engineering: WG last call, waiting for implementation -> std.track.
[21:00:10] <thomas.heide.clausen@gmail.com> Seems straight-fwd based on experience with OSPFv2 traffic engineering.
[21:00:20] <thomas.heide.clausen@gmail.com> Waiting for AD OK?
[21:00:50] <thomas.heide.clausen@gmail.com> te-node-addr: authors will change ever so slightly, last call, then to the IESG.
[21:01:16] <thomas.heide.clausen@gmail.com> OPSF for v6: last called, date past. Looking for reviewers from directorate - 100pg document ;(
[21:01:49] <thomas.heide.clausen@gmail.com> Looking for clarifications, not changes or enhancements.
[21:02:07] <thomas.heide.clausen@gmail.com> Multi Area Adjacency: in publication-requested
[21:02:36] <thomas.heide.clausen@gmail.com> Want to pull back since there are implementations upcoming. Off-line requirements, another revision and then last-call again.
[21:02:49] <thomas.heide.clausen@gmail.com> Should go std. track, regardless what IETF page says.
[21:03:22] <thomas.heide.clausen@gmail.com> <long list of I-Ds that need review, discussion, implementation>
[21:03:35] --- Tsubasa has joined
[21:04:40] <thomas.heide.clausen@gmail.com> Non-wg documents: discussed at the end of the session to evaluate if it is to go here or there.
[21:04:51] <thomas.heide.clausen@gmail.com> Same for MANETs: no rough consensus, will be covered today as well.
[21:05:33] <thomas.heide.clausen@gmail.com> Michael Barnes presents "Cryptographic algorithm implementation requirements for OSPF.
[21:06:36] <thomas.heide.clausen@gmail.com> http://www3.ietf.org/proceedings/06nov/slides/ospf-6.ppt
[21:06:42] --- Tsubasa has left
[21:07:21] --- thomas.heide.clausen@gmail.com has left: Logged out
[21:08:31] --- Tsubasa has joined
[21:09:03] --- Tsubasa has left
[21:16:07] --- thomas.heide.clausen@gmail.com has joined
[21:16:15] <thomas.heide.clausen@gmail.com> Acee: one comment. Turned this down with the statement that we want to use IPSec. 03:10 Motivation fr doing this: lack of replay protection due to lack of e2e key dist on a lan or maccess network. 03:10 Build-in OSPFv2 auth, people have pretty much solved this problem. Seq# is not monotonically increasing with every packet, >= relation. Use clock-tick as seq#. 03:11 Thinks that we may as well go ahead - discuss a bit more and ask, before it becomes wg-doc, 03:11 Sandy Murphy: ask obvious question - will it be mandatory to implement? 03:12 Barnes: this document is just covering the more general "any algorithm" - there will be another doc. 03:14 Manav: different OSPF Auth Schemes (unscheduled presentation) 03:14 Refers to an I-D....
[21:18:18] <thomas.heide.clausen@gmail.com> Acee: I don't think that an impl can say "you should not implement this sec mechanism"
[21:18:54] <thomas.heide.clausen@gmail.com> IPSec will probably die at some point.
[21:19:19] <thomas.heide.clausen@gmail.com> Russ White: instead of SHOULD+/-, maybe rather say "this is currently a SHOULD, but may become a MUST in the future", since it's a bit of a codeword.
[21:20:07] <thomas.heide.clausen@gmail.com> lou Berger: Update to the OSPF Opaque LSA option
[21:20:26] <thomas.heide.clausen@gmail.com> http://www3.ietf.org/proceedings/06nov/slides/ospf-3.ppt
[21:20:43] <thomas.heide.clausen@gmail.com> Update to previous discussion.
[21:22:09] <thomas.heide.clausen@gmail.com> It's important for those in the community to review 2370bis, since there are things which before were not requirements which are.
[21:22:36] <thomas.heide.clausen@gmail.com> Please do a careful review.
[21:23:24] <thomas.heide.clausen@gmail.com> Needed input - discussions over a SHOULD and a MAY, see slide "Changes in Draft from 3270"
[21:23:26] <thomas.heide.clausen@gmail.com> 2370
[21:24:47] <thomas.heide.clausen@gmail.com> Take it to the list.
[21:27:21] <thomas.heide.clausen@gmail.com> Time to bring in any other changes now.
[21:27:57] <thomas.heide.clausen@gmail.com> Acee: needs to be wg document, validate on the list....
[21:28:12] <thomas.heide.clausen@gmail.com> Acee: will rather ask "who thinks it should *not* be a wg document.
[21:30:20] <thomas.heide.clausen@gmail.com> Emmanuel Baccelli: OSPF extension for MANET based on MPRs
[21:30:39] <thomas.heide.clausen@gmail.com> draft-baccelli-ospf-mpr-ext-02.txt
[21:31:02] <thomas.heide.clausen@gmail.com> (slides not on line, but since nobody is listening in here in real-time, I won't bother to type the content - check proceedings if consulting jabber logs post-meeting)
[21:31:59] --- Tsubasa has joined
[21:32:38] <thomas.heide.clausen@gmail.com> Emmanuel presenting MPRs as "subset of links in the network"
[21:32:57] <thomas.heide.clausen@gmail.com> Properties: 2-hop coverage, shortest-path coverage.
[21:33:06] <thomas.heide.clausen@gmail.com> Allows for flooding optimizations, adjacency reduction, topology reduction.
[21:33:23] <thomas.heide.clausen@gmail.com> Validated both experimentally in manets, as well as theoretically
[21:33:33] <thomas.heide.clausen@gmail.com> Recent developments:
[21:33:41] <thomas.heide.clausen@gmail.com> following discussions in DT:
[21:33:54] <thomas.heide.clausen@gmail.com> Modified to match structure of 2740 and 2328
[21:34:03] <thomas.heide.clausen@gmail.com> Newer heuristics...didn't get the rest of the slide.
[21:34:35] --- josoinin@jabber.org/Meebo has joined
[21:34:37] <thomas.heide.clausen@gmail.com> Simulation code based on GTnet on-line on some-url. Check slides when they appear.
[21:34:37] <thomas.heide.clausen@gmail.com> Showing simulations, flooding efficiency etc.
[21:34:46] <thomas.heide.clausen@gmail.com> Acee: figures are compared to normal OSPF, right?
[21:34:50] <thomas.heide.clausen@gmail.com> EB: Yes.
[21:34:55] <thomas.heide.clausen@gmail.com> Simulations show that main overhead is still LSA flooding.
[21:35:36] <thomas.heide.clausen@gmail.com> Flooding efficiency, adjacency reduction, topology reduction benefits shown as compared to regular OSPF.
[21:35:52] <thomas.heide.clausen@gmail.com> Topology reduction gives a substantial gain in the size of packets....
[21:36:03] <thomas.heide.clausen@gmail.com> 500x500 square, 50% gain.
[21:36:22] <thomas.heide.clausen@gmail.com> #links advertised, 75% gain
[21:36:41] <thomas.heide.clausen@gmail.com> Simulations confirmed with independant simulations outside of GTnet and common framework.
[21:37:01] <thomas.heide.clausen@gmail.com> Consistent results between these simulations and the GTnet results.
[21:37:23] <thomas.heide.clausen@gmail.com> Work on analytical model, trying to explain why LSA flooding overhead is larger than synchronization overhead.
[21:37:26] <thomas.heide.clausen@gmail.com> Next steps:
[21:38:15] <thomas.heide.clausen@gmail.com> Simulations are necessary, but there are no satisfying wireless model, the scenarii are too restrictive and all in all simulations are not sufficient to evaluate what goes on in read deployment scenarios.
[21:38:25] <thomas.heide.clausen@gmail.com> Encourages experimental status to move forward with getting real-world experience.
[21:38:40] <thomas.heide.clausen@gmail.com> Both for this and other approaches - seems to me to be the way to go.
[21:38:43] <thomas.heide.clausen@gmail.com> (done)
[21:38:58] <thomas.heide.clausen@gmail.com> Acee: This I-D didn't make the cut-off, so it is posted during this week.
[21:39:38] <thomas.heide.clausen@gmail.com> Acee: one thing which would be interesting would be to see how this compares to others in the same scenarios.
[21:40:02] <thomas.heide.clausen@gmail.com> Emmanuel: Might be interesting, discussed a lot on mailing-list.
[21:40:20] <thomas.heide.clausen@gmail.com> Russ White: OSPF/MANET experimental
[21:40:40] <thomas.heide.clausen@gmail.com> Based on what he has seen on list.
[21:40:50] <thomas.heide.clausen@gmail.com> MDR: no known field-testing, primarily simulation
[21:41:00] <thomas.heide.clausen@gmail.com> Primary reduction is neighbor reduction
[21:41:09] <thomas.heide.clausen@gmail.com> http://www3.ietf.org/proceedings/06nov/slides/ospf-4.ppt
[21:41:32] <thomas.heide.clausen@gmail.com> Joe: Mentioned on the list, there have been field-testing with MDRs
[21:41:42] <thomas.heide.clausen@gmail.com> OR: implemented, tested and deployed
[21:41:55] <thomas.heide.clausen@gmail.com> Relies on flooding changes for overhead reduction
[21:42:57] <thomas.heide.clausen@gmail.com> EB: MPRs are older, and the MPR draft has been posted for more than a year.
[21:43:15] <thomas.heide.clausen@gmail.com> Russ: Requirement issues - do not know which to choose.
[21:43:24] <thomas.heide.clausen@gmail.com> We do not know if the simulations mirror the real world
[21:43:48] <thomas.heide.clausen@gmail.com> Asks if MPR simulations use random waypoint or random walk?
[21:43:51] <thomas.heide.clausen@gmail.com> EB: Both
[21:44:11] <thomas.heide.clausen@gmail.com> Russ: We do not know if the simulation scenarios mirror this. Are simulations a good decission point?
[21:44:29] <thomas.heide.clausen@gmail.com> We do not know which of these drafts are to become draft-standard.
[21:44:41] <thomas.heide.clausen@gmail.com> We do not know if any vendors are requesting actual implementations.
[21:45:01] <thomas.heide.clausen@gmail.com> Proposal: move forward to experimental, until we have more data to decide if we move fwd to std. track.
[21:45:11] <thomas.heide.clausen@gmail.com> Tom Henderson:
[21:45:19] <thomas.heide.clausen@gmail.com> Just wanted to say a few things which he disagrees with.
[21:45:55] <thomas.heide.clausen@gmail.com> <<<<I am trying to participate in the discussion here, so scribing is tuff >>>>
[21:49:27] <thomas.heide.clausen@gmail.com> Andrew: most common medium density, avg neighbors 4-8, not sensor, somewhat static - these proposals are a major win.
[21:49:47] <thomas.heide.clausen@gmail.com> Stan: We've argued or discussed these issues (topology, ...) on the mailing-list
[21:50:00] <thomas.heide.clausen@gmail.com> What it boils down to is: go we go forward with one or with more than one draft.
[21:50:12] <thomas.heide.clausen@gmail.com> For now, all we know is based on simulations - one simulation scenario,
[21:50:46] <thomas.heide.clausen@gmail.com> Supports going forward with multiple experimental drafts, since we *need* more experience.
[21:50:49] <thomas.heide.clausen@gmail.com> Joe Macker: technical points.
[21:51:10] <thomas.heide.clausen@gmail.com> It's important to not falsely argue
[21:51:10] <thomas.heide.clausen@gmail.com> There's been good work done here.
[21:51:10] <thomas.heide.clausen@gmail.com> We've showed topology improvements with many approaches.
[21:51:24] <thomas.heide.clausen@gmail.com> Adjacency reduction was an additional step - validated what you hypothesised have happend.
[21:51:32] <thomas.heide.clausen@gmail.com> Should be studied more, but it is a good first-step.
[21:51:41] <thomas.heide.clausen@gmail.com> These proposals can be used in full ls mode, however.
[21:52:34] <thomas.heide.clausen@gmail.com> Russ: that's why we should go experimental,
[21:52:53] <thomas.heide.clausen@gmail.com> Joe: It's ok to keep optimizing, but we did sit down with the ADs, and this is something that we do not want to optimize.
[21:52:57] <thomas.heide.clausen@gmail.com> If it's close, we're not going to pick one.
[21:53:03] <thomas.heide.clausen@gmail.com> Feels that the approaches are very close.
[21:53:19] <thomas.heide.clausen@gmail.com> Thinks that a decission should be made, since that was the approach they went in with.
[21:53:36] <thomas.heide.clausen@gmail.com> Emmanuel Baccelli: agree that good work has been going on in Dt.
[21:54:14] <thomas.heide.clausen@gmail.com> Disagree on one point: seems that people think that going experimental is a failure. To the contrary, this is the only reasonable way to go,
[21:54:18] <thomas.heide.clausen@gmail.com> Joe: clarify - that's not my point, what I think that we should do is to avoid over-optimization,
[21:54:55] <thomas.heide.clausen@gmail.com> Emmanuel: 3 different proposals. Different mechanisms for TR, Flooding Optimization, Adjacency reduction. Hard to judge which is better - there seems some consensus that simulations while necessary are not sufficient.
[21:55:06] <thomas.heide.clausen@gmail.com> Supports going experimental. This should be for the three drafts.
[21:55:16] <thomas.heide.clausen@gmail.com> Can't see how to judge between two or three
[21:55:38] <thomas.heide.clausen@gmail.com> Philippe Jacquet: not a problem of over-optimization.
[21:56:20] <thomas.heide.clausen@gmail.com> What we discover is not new, it's out of MANEt. Developed for several years. Could fill several slides with references to experiments with MPR-based solutions, and MPR-OSPF and ORCA are both MPR-based.
[21:56:36] <thomas.heide.clausen@gmail.com> First way to work on the solution would be to start with what is out of MANET. MPR-OSPF is out of MANEt.
[21:56:48] <thomas.heide.clausen@gmail.com> No use to over-innovate something new, which has no experimental background
[21:57:13] <thomas.heide.clausen@gmail.com> tom Henderson
[21:58:10] <thomas.heide.clausen@gmail.com> Thinks that we have basis for decission - experiments are notoriously expensive and hard to reproduce
[21:58:21] <thomas.heide.clausen@gmail.com> think that all approaches can work
[21:58:52] <thomas.heide.clausen@gmail.com> His problem with going experimental is how to then identify the next-step. How can we come back and make a decision later. Rather not have this happen
[21:59:03] <thomas.heide.clausen@gmail.com> Acee: this has happened before, will rather not have it happen in his.
[21:59:43] <thomas.heide.clausen@gmail.com> This doesn't seem to have enough, right now, marked requirement as if it has got to be there tomorrow.
[21:59:50] <thomas.heide.clausen@gmail.com> Hard to say what's going to happen.
[22:08:19] <thomas.heide.clausen@gmail.com> <<<< jabber scribe participating in discussion - refer to audiocast or minute-tager >>>>
[22:08:24] <thomas.heide.clausen@gmail.com> s/tager/taker/
[22:10:01] <thomas.heide.clausen@gmail.com> Acee: Tom will go through a few slides of the design-team
[22:10:30] <thomas.heide.clausen@gmail.com> Stan: wants to see a hum tonight from this group if we proceed on one or multiple
[22:10:36] <thomas.heide.clausen@gmail.com> Think that we should proceed with three.
[22:11:07] <thomas.heide.clausen@gmail.com> Acee: if we say one draft, then we need to find an agreed way of selecting. I do not believe that we have that. Was the question if now we want to go forward with multiple draft?
[22:11:11] <thomas.heide.clausen@gmail.com> Stan: Yes
[22:11:40] <thomas.heide.clausen@gmail.com> Tom's presentation: (slides not found)
[22:11:50] <thomas.heide.clausen@gmail.com> Timeline: started by OLSR ported to OSPF protocol
[22:12:03] <thomas.heide.clausen@gmail.com> Difference from that to what subsequently emerged was reliable or unreliable question
[22:12:49] <thomas.heide.clausen@gmail.com> Discussion of when drafts emerged.
[22:14:12] <thomas.heide.clausen@gmail.com> Emmanuel Baccell: wanted to reiterate that the first draft was the one working with MPRs.
[22:14:57] <thomas.heide.clausen@gmail.com> Tom: continues, simulator, ...
[22:17:32] --- josoinin@jabber.org/Meebo has left: Logged out
[22:17:53] <thomas.heide.clausen@gmail.com> Acee: Bill Fenner (AD) do you want to say anything?
[22:17:56] <thomas.heide.clausen@gmail.com> Bill Fenner:
[22:18:07] <thomas.heide.clausen@gmail.com> Wants to echo the disappointment that no consensus solution has come.
[22:18:48] <thomas.heide.clausen@gmail.com> Agree that simulation-only isn't sufficient, but simulations shouldn't be disregarded either.
[22:19:04] <thomas.heide.clausen@gmail.com> Acee: two alternatives:
[22:19:14] <thomas.heide.clausen@gmail.com> 1) Continue to try to come to consensus
[22:19:26] <thomas.heide.clausen@gmail.com> Actually
[22:19:26] <thomas.heide.clausen@gmail.com> 0) Give up ;)
[22:19:30] <thomas.heide.clausen@gmail.com> 1) is to come to a single solution
[22:19:53] <thomas.heide.clausen@gmail.com> 2) To, as russ suggests, publish multiple I-Ds as experimental get some stable specifications.
[22:20:19] <thomas.heide.clausen@gmail.com> Bill Fenner: are there I-Ds ready to be published today?
[22:20:39] <thomas.heide.clausen@gmail.com> Acee: Refined, probably. ORCA hasn't changed for a while. MDR should be simplified.
[22:21:26] <thomas.heide.clausen@gmail.com> Emmanuel: OSPF-MPR needs a bit of refinement, but close to finished.
[22:21:37] <thomas.heide.clausen@gmail.com> Hum on "quit"? -- none
[22:21:53] <thomas.heide.clausen@gmail.com> Hum on "consensus"? -- none
[22:22:24] <thomas.heide.clausen@gmail.com> Hum on "go experimental after refinement"? -- some
[22:22:37] <thomas.heide.clausen@gmail.com> Oops, people were raising hands, not humming and I am in the front.
[22:22:48] <thomas.heide.clausen@gmail.com> So I may not have been getting right on "quit" and "consensus".
[22:23:56] <thomas.heide.clausen@gmail.com> OSPF has been fortunate/spoiled since, with the history and legacy solutions have thus far been obvious.
[22:24:02] <thomas.heide.clausen@gmail.com> Emmanuel: what is the milestones and timeline?
[22:24:14] <thomas.heide.clausen@gmail.com> Acee: when we feel we're ready to implement....we'll WG last-call them.
[22:25:11] <thomas.heide.clausen@gmail.com> Bill: encourage that to be pretty quick. One of the thing we saw in old MANET regime was to tweak "one last thing", and go back and forth doing epsilon-improvements each time. Better to get something done quick, snapshot, as long as it is implementable and corresponds to what people are thinking.
[22:25:18] <thomas.heide.clausen@gmail.com> Acee: will take this under advice.
[22:25:29] <thomas.heide.clausen@gmail.com> Joe: One of our [manet] drafts that was dragging along took years.
[22:25:54] <thomas.heide.clausen@gmail.com> Encourage to set up a milestone - this is a WG chair call.
[22:26:04] <thomas.heide.clausen@gmail.com> Acee: all authors have been attentive to comments.
[22:28:17] <thomas.heide.clausen@gmail.com> The 3 I-Ds should move forward to draft-ietf-ospf to go experimental. Don't think we can exclude one or the other,
[22:29:14] <thomas.heide.clausen@gmail.com> But need, of course, to study carefully.
[22:29:23] <thomas.heide.clausen@gmail.com> Acee: discussing the "lingering documents".
[22:29:39] <thomas.heide.clausen@gmail.com> ogier-dbx - should get consensus to move to wg document.
[22:29:49] <thomas.heide.clausen@gmail.com> Update to OSPF hello procedures.
[22:30:11] --- Tsubasa has left
[22:30:11] <thomas.heide.clausen@gmail.com> Many flavors.
[22:30:34] <thomas.heide.clausen@gmail.com> Need to discuss where we want to go.
[22:30:48] <thomas.heide.clausen@gmail.com> Acee doesn't feel that it is ready to go to wg doc yet.
[22:31:09] <thomas.heide.clausen@gmail.com> Graceful Restart I-D.
[22:33:11] <thomas.heide.clausen@gmail.com> Padma: do we see a requirement for this? Acee: we need to ask this question.
[22:33:58] <thomas.heide.clausen@gmail.com> Acee: wondering if there's any more discussion. This is basically suggestions for graceful restart
[22:34:24] <thomas.heide.clausen@gmail.com> Padma: most are internal optimizations
[22:34:46] <thomas.heide.clausen@gmail.com> Acee: that's for termination. for explicit termination, there are ways you can do it which require changes to the protocol.
[22:35:08] <thomas.heide.clausen@gmail.com> Padma: I am thinking that the first is internal optimization, and that we do not need the second (explicit signaling for GR helper termination)
[22:35:49] <thomas.heide.clausen@gmail.com> Acee: give it one more tour on the mailing-list, to see if we think that either of these requirements are necessary.
[22:36:37] <thomas.heide.clausen@gmail.com> Acee: anyone in here seeing the helper criteria as a requirement (none in the room)
[22:37:04] <thomas.heide.clausen@gmail.com> Idemn for explicit signaling for gr helper termination? - looks like it echos Padma's feel for the requirements
[22:37:18] <thomas.heide.clausen@gmail.com> Extension for advertising optional route / link attributes.
[22:37:28] <thomas.heide.clausen@gmail.com> (disclaimer: Acee is co-author)
[22:37:34] <thomas.heide.clausen@gmail.com> Thinks it is necessary.
[22:38:19] <thomas.heide.clausen@gmail.com> Nobody seems to have read it in the room, need more discussion on it.
[22:38:37] <thomas.heide.clausen@gmail.com> Tried to get some of the people who came up with the requirements to get involved, but not succesful.
[22:38:48] <thomas.heide.clausen@gmail.com> MIB for MT....
[22:39:13] <thomas.heide.clausen@gmail.com> Anyone who doesn't think it should be wg doc (nobody), sufficient people have read it that Acee should be wg doc.
[22:39:37] <thomas.heide.clausen@gmail.com> Conclusion: Ogier-dbx & MIB-MT should be asked to be wg documents, then?
[22:40:04] <thomas.heide.clausen@gmail.com> Final question: how many plan to be in Prague? Seems enough to have a meeting.
[22:40:26] <thomas.heide.clausen@gmail.com> Done. 3 minutes early.
[22:41:14] <thomas.heide.clausen@gmail.com> ****
[22:41:38] <thomas.heide.clausen@gmail.com> Scribe apologizes for having gotten names and details wrong. Was trying to participate in the discussion, which made it sometimes difficult....
[22:41:40] <thomas.heide.clausen@gmail.com> ****
[22:42:02] --- thomas.heide.clausen@gmail.com has left: Logged out