Subject: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended

From: Acee Lindem <[email-masked]>
Date: Mon, 13 Nov 2006 08:59:48 -0500

Here are the minutes from the 67th IETF OSPF WG meeting. Thanks
to Steve Nadas from Ericsson for taking them.

There was quite a bit of dialog at the mike with respect to the
OSPF MANET direction. I've also appended Thomas Clausen's
jabber log. Please unicast corrections to me. IETF 67

Please unicast any corrections to me.

Thanks,
Acee
 Minutes taken by Steve Nadas from Ericsson ([email-masked])

Acee: OSPFv3 IPSec Automated key generation no longer on agenda.
      We need to pass  requirements to MSEC WG. 

Joe Macker: IPSec usage issue is common to MANET protocols. Requirements to
            be coordinated. 
Acee: Yes - there are multiple protocols that will have/need similar IPSec
            automated key requirements.

Presentation Acee: Document status - no new RFCs since 66 - see slides 
    
    Authors to resolve - multi-topo - like to see interop 
		       - capabilitils	  - iesg commetns
    need impls/interop test  - TE extensions for V3 
    tls from iana requested  - wait on AD oks 

    WG LC: rtr's local address in TE xtensions 

    OSPF fot V3 - needs reviewers in rtg area (+ others for
    clarity/readability ) 

    Multi-area adjacency - Respin and re-Last Call - Will 
      become standards track rather than informational.  
    
    OSPFv3 mib, traps added 
    
    OSPFv3 multi-topo - needs rev and impl
    
    addr families - simpler but not fate share but adj overhead 
    
    ospf - ll signalling --> to wg doc 

    New non-wg drafts - See later in minutes 

    OSPF manet drafts - No rough consensus as yet 

Presentation Michael Barnes : Crypto alg reqmts for OSPFv2

    Some discussion on list already 

    Crypto - only md5 to date, can be attacked, some want stronger algs 
	 perhaps should specify these 
	
    How - 2328 can add other algs w/o too much problem 
	
    This draft - new algorithms should be used and won't change
    proto fields, there is key-id field which can has an associated
    algorithm as a property. 

    Adding crypto terms- SA's - will carry key/alg choice, fairly
    straight forward approach - should not cause backwards compatibility
    because no change to OSPF proto fields - it's mis-config if one peers
    has a different algorithm.  

    Acee: IPSec for v3, once done, lacks replay and key dist issues
    on lan - w/v2 these problems are solved mainly (seq#>=, not
    monotonic incr). Vishwas present requirements in Paris in both
    OSPF and RPSEC WGs. 

    Sandy Murphy, Sparta : what is manditory to implement?
    Michael - Separate doc will discuss what is req'd (ala ISIS approach)
	
Presentation: Manav Bhatia - Crypto Requirements Document

    NULL, MS5, sha1, cryptographic - refs in this doc 
    more algorithms keep coming eg des was once must, now is should ot 
	
    What doc must, should, - running doc as algorithms come and go 
    uses 2119 terms should+ = should may become must 
		
    See slides and draft for specific requirements. 
		
    Acee: "should not" wording is problematic for NULL and other 
    existing requirements. 
	
    Russ white: shold may become a must vs. should+ (better to say
	 what is meant)

Presentation Lou Berger: berger-ospf-rfc2370bis followon to ietf66 - opaque 
    LSA across areas - problem w/validation - so instead rev'd 2370 
	
    Edited Igor's draft into 2370 

    2370 minor changes - draft format - non-standard MUST etc
    keywords - and upodated community needs to review to see if
    it's right - because the wording was once subjective and is
    now less so.

    See slides for other changes. 
	 
    Acee wanted MAY or Should added 
    Acee: when we add new info to TE LSAs - scalability issues -
          give priority to base ospf LSA over the opaque LSAs.
    Lou: We should take to list whether MAY or SHOULD should be in
         the final text. 

    Acee: Will validate on list that this is to become a WG document. 

Presentation Emmanuel Baccelli: presented in dallas - simulations - 
        draft-baccelli-ospf-mpr-ext-02 
	
    MPR extension for MANETs, recent, simulations.
  
    See slides for presentation. 
	
    Acee: Didn't make cutoff - draft is queue to be posted 
	    
    Acee: Interesting to compare w/other simulations mdr etc - 

    Emmanuel: yes but much discussed

Presentation Russ White: ospf/manet experimental 

    MDR - Design team favored - No field test - Employs neighbor 
          reduction
	
    Joe Macker: On list stated that MDR was field tested.

    OR - implemenmted , tested and getting deployed
   
    MPR - New entry - See slides for more info.  
	
    Emmanuel Baccelli: MPR draft is 1 year old and OLSR is 
        older. What are real requirements?  

    Emmanuel: Use both random walks and boeing framwework using
             random wavepoint for simulations

    Russ: No good way to decide what should become draft standard -
	testing is limited - recommend experimental for multiple
        proposals and additional work. 

    Tom Henderson: Disagree characterization - flooding reduction
	- not so easy to untangle where benefits - between flood
	reduce and neighbor reduction. Unfair to characterize MDR as
        unfit for life critical applications. 
    Acee: Can use either approach (or all 3) with or without neighbor
        reduction. 
    Russ: There may be MANETs where there is low density 
    Tom: Agree but MDRs handles multiple topologies.

    Andrew: low dense vs medium density - there are cases 
            where fixed networks acts like mobile because weather 

    Stan Ratliff  - This has been discussed - do we go forward 
                    with one or more drafts. 

    Joe Macker - technical points - there has been good work done and have 
        shown good results with adjacency reductino - these can be used in
	full link state mode - not clear mesh n/w's - there are cases
	where these techniques are useful 
	      
     Russ: Agrees with Joe. 
	
     Joe: If things are close, try to pick one - and that was ourstragety 
        initially - perhps reasdon to make decision 
	
     Emmanuel: Agrees good work done - doesn't see experimental as a failure.       
  		         
     Joe: Was dissapointed with failure to pick single solution - 
          need to avoid over optimization 
	
     Emmanuel: 3 proposals w/different mechanisms - don't see how to
	judge which is better - consensus simulations are necessary but not
	sufficient - need to go experimental in order to be able to judge 
	
     Phillip Jacquet: Should over optimize or over invoated - MPR is
        based on MANET (OLSR) which has been around for some time - try to
	adapt these approaches - think 3 proposals are interesting

      Tom: defends simulations - are advantages to sim - used sharable and
	tests\ed code - MANET experiments are expensive and hard to
	reprodice and so there is cost for that approach - thinks all
	will work want to understand how to get 2 next step - what is
	looked for and how will we know in 2 years?

      Acee: happend in pim/cbt and vpn info distribution for VPLA - in 
        1 case CBTs died to due lack of implementations but for VPLS
        there are 2 ways to do it deployed. However, I don't see how we
        get to consensus given everyone who goes to the mike gives a 
        different summary of where we are.      

      Andrew - Some version will get deployed in an experimental network. 
        We will have some results but these will be hard to reproduce. 
	get some info - results are hard to reprodice - need to look
	for a long time on a real network - simulations are harder on
	network except that lots of packets are lost in the real network. 

      Tom: This does not imply that we can't do experiments - these are
        expensive due to the salary cost of the people who are mobile. 
	
      Thomas Clausen - No critcism for Design Team work - would be good
        to use test beds from MANET community - not overnight process but
        there are opportunities - reqmt's are soft so no need to force
        solution. We can try and get experimental results and would have
        more information to make decisions. 

      Joe Macker - been doing experiments in MANET for some time -
	need to have good tools to collect results - network can break but
	not seen in experiment - traffic flow and mobility abtre both
	important (done 20-30 nodes) suppplement sims w/experiments
	some failure modes are only seen in sim 
	
      Russ: simulations aren't enough.
	
      Thomas- Experiments - are necessary but not sufficennt - 
              relatively low hanging fruit 

      Phillipe: Risk for 500x500 node in middle cover 80% - not like 
                real life - mayne solution for simulation. 

      Stan - Don't throw simulatoins away - agree - 
             Design Team has done good work - not enough info with just
             simulationss - need to proceed with multiple experimental
             draft.   
	
      Acee: Asked Tom to discuss Design Team work in a few slides 
	
      Stan - Like to see hum on 1 or multiple 

      Acee: If one draft - how would we pick it? We've been unsuccessful
            heretofore to agree on criteria.  
	
Presentation: Tom Henderson: Summary of Design history - See slides.

     Emmanuel: First MPR drafts - 4 yrs old - 2002 time frame (response to
         timeline).
  
     See slides for timeline of design team. 

     Bill Fenner: Echo disappointment on no consensus. We should not
	ignore simulations. It provides useful info - but more is needed -
	no opinion on how to proceed. 
	
     Acee: one alternative: quit. 
           2nd: Continue trying to agree on single solution.  
           3rd:	Multiple expeimrntal drafts - provide stable point for
                implementation and further experience. 

     Bill: Are the drafts ready today?  How long to refine and then publish? 
           Don't keeping tweaking if since we want experience with various
           approaches ASAP. 
	
     Acee: More like refine and publish (ro's) but one is stable -
	   Criteria for publication is less stringent for experimental
           drafts. 

     Emmanuel: MPRs is pretty close 
	
     Acee: Show hands on what should be done:
           - Quit working on OSPF MANET: none 
           - Continue to drive to consensus: none 
	   - Refine drafts and publish as experimental: 2/3's of people
             in room. To be validated on list.

     Acee: Refining and publishing is clearly the consensus of those here
           at the meeting. This is difficult for the OSPF WG since we are
           used to reaching consensus on a single solution and only arguing
           about encodings and corner cases that need to be documented. 

     Emmanuel: What type milestone are we looking at?
	
     Acee: Should proceed ASAP to WG last call and publication as experimental.

     Bill: Encourage to do this pretty quickly - easy to keep
	   iterating and it better to get a quick snapshot soon for
           more experience with the approaches. 

     Joe Macker: One experiment MANET draft dragged for years - maybe here want
	converge - WG chair call to get control of iteration and enhancement
	creep...

     Acee: Experimental drafts (even WG) should be treated a bit 
           differently than standards track WG documents. In this case,
           the authors should retain control over the content and move toward
           publication rather than making the content the collective 
           property of the OSPF WG. 

     Jabber Comment: Need to see new MPR draft and code before agreeing to
           publish.

     Acee: Since lots of good work has been done and we are going to publish
           more than one draft, we should publish those which meet the
           implementation and simulation criteria. 

----- 

Presentation Acee: Docs on the Edge 
     
     Ogier database exchange change draft --> Should move to WG doc.
     Please read it. Extracted from MDR work. There were no objections
     to making the draft a WG document.

     Update to hello (kou) -
      Vendors have implemented in many different ways. Unlikly to be 
        standardised after the fact
      No recent discussion. 
	    
     holla-opsf-update-gr 
         - helper criteria changed 
         - explict GR signalling 
         Is there a requirement for these ?  
     
     Padma: read older draft & thought these were already known - most
            thought explicit signaling didn't offer much improvement
            over inconsistent LSA. 
     
     Acee: If were a true requirement we could respin but author limit
           would be exceeded. 

     Padm: First is internal operation and no requirement for second. 

     Acee: Discussion in montreal - some thought it was useful - it 
           would be good to discuss on the list again. 

         Helper Criteria Change - No one in room views as required. 
         Explicit Termination - Also no one in room views as required.

     mirtorabi OSPF tag - extra into for lnks/rts - Acee is author so
         thinks is needed - more discussion on list - haven't gotten 
         those with requirements to present at IETF> 

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

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: Richard Ogier <[email-masked]>
Date: Mon, 13 Nov 2006 08:34:50 -0800

>              in room. To be validated on list.

Acee,

Correct me if I am wrong, but since the latest version of INRIA's
draft was available only last week, and since previous versions did
not fully specify the protocol (as pointed out by Phil Spagnolo in
his 9/28/06 post to the ospf-manet list), it has not yet been decided
that INRIA's draft will be published as experimental.

Moreover, since INRIA has not participated in the GTNetS simulation
comparison that Boeing has been conducting for the last two
years, in which the MDR draft has been compared to Cisco's
OR/SP drafts (results can be found at Boeing's OSPF-MANET website
http://hipserver.mct.phantomworks.org/ietf/ospf/ ),
it is only fair that we should do such a comparison with INRIA's draft
before deciding to publish it as experimental.

In fact, that has been the plan since the Dallas IETF meeting in March,
and Philippe agreed to this in his message of 4/5/06:

Philippe Jacquet wrote on 4/5/06:
 > Yes it would be great to synchronize our efforts on GTNet.
 > Let's see how to proceed.

Now, 7 months later, INRIA has implemented their solution in GTNetS,
so the next step would be for Boeing to work with INRIA to make
sure the code is debugged and implemented in a manner that allows
a fair comparison, just as Boeing has done with the OR/SP and
MDR solutions over the last two years.  Hopefully, this work can
be completed by the next IETF meeting.

I think it is reasonable and fair to require such a comparison
to be done before INRIA's draft is accepted, especially
since they promised to synchronize efforts 7 months ago.
Let me know if you agree or disagree.
IMO, to give INRIA a free pass and avoid such a comparison
would be unfair to those of us who worked hard for the last two
years on the GTNetS simulation effort.

Richard

---

From: "Manav Bhatia" <[email-masked]>
Date: Mon, 13 Nov 2006 23:47:45 +0530

Acee,

The minutes missed out my replies.

>    Acee: "should not" wording is problematic for NULL and other 

Manav: NULL authentication is a "should NOT" in case an admin requires OSPF
security.

> Russ white: shold may become a must vs. should+ (better to say

Manav: We have used these additional RFC2119 terms since the earlier
cryptographic implementation requirement RFCs 4305, 4307 have used a similar
language.

Cheers,
Manav    

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]] 
> Sent: Monday, November 13, 2006 7:30 PM
> To: OSPF List
> Subject: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct 
> file appended 
> 

Send instant messages to your online friends http://uk.messenger.yahoo.com

---

From: Acee Lindem <[email-masked]>
Date: Mon, 13 Nov 2006 13:35:47 -0500

Hi Richard,
I think we agreed upon a process to move along and we should
continue to hold all the drafts to the same experimental publication
criteria. I guess the point was that we should not limit the number to
2 if we're going to publish more than 1. Without injecting too much judgment
on the MPR draft's maturity, did everyone at the meeting hear the
same message?

Thanks,
Acee

---

From: Richard Ogier <[email-masked]>
Date: Mon, 13 Nov 2006 11:06:30 -0800

Acee,

I am not sure I understand what you mean.  The MDR and OR/SP
drafts have already been evaluated exensively via GTNetS
simulations.  INRIA's solution has not yet participated
in any such evaluation. So if we require all the drafts
to participate in the GTNetS evaluation (which was the
original plan two years ago), then we *are* holding all
drafts to the same experimental publication criteria.

Or, are you saying that we should give INRIA a free pass
to avoid participating in the GTNetS evaluation?
I really don't think this would be fair, and therefore
seriously doubt that the consensus would agree with this.

I don't think the voting at the meeting clearly distinguished
between the two options of accepting 2 versus 3 drafts.
This distinction was not made explicit at the meeting.

Richard

---

From: Acee Lindem <[email-masked]>
Date: Mon, 13 Nov 2006 20:01:21 -0500

Hi Richard,
> drafts to the same experimental publication criteria.
GTNetS Simulation results were presented in San Diego so I believe
MPRs have been implemented. The code should be made available for
public inspection and comparison with the other drafts.

> seriously doubt that the consensus would agree with this.
I agree.
> This distinction was not made explicit at the meeting.
You are right that the question of 2 or 3 wasn't the primary
focus of the dialog. While we've agreed to allow for more
than one experimental draft, I don't think we should lower
our standards. I don't think anyone who was at the meeting
would disagree.
Thanks,
Acee

---

From: "U. Nilrebmorf" <[email-masked]>
Date: Tue, 14 Nov 2006 02:58:51 +0100

Hi Richard,

I was at the meeting. The consensus was that since simulations are not
sufficient to decide for one solution over another, simulations are also not
sufficient to exclude one solution. So it was decided to move on with 3
experimental. If I am not mistaken, it is read in the minutes from the
meeting:

"Acee: all authors have been attentive to comments. The 3 I-Ds should move
forward to draft-ietf-ospf to go experimental."

That's what the working group decided in the end. If you had been there
maybe it would be clearer to you?

Hope to see you at the next meeting.

Nilreb

---

From: Richard Ogier <[email-masked]>
Date: Tue, 14 Nov 2006 08:51:07 -0800

U. Nilrebmorf wrote:

> sufficient to decide for one solution over another, simulations are 
> also not sufficient to exclude one solution.

I disagree with your reasoning.  If we had 100 solutions, and simulations
show that 10 of them perform much better than the other 90, then I think
that might be a good way to exclude the 90 and keep only 10.
Whereas by your reasoning we should keep all 100.

Richard

> So it was decided to move on with 3 experimental. If I am not 
> mistaken, it is read in the minutes from the meeting:
>
> "Acee: all authors have been attentive to comments. The 3 I-Ds should 
> move forward to draft-ietf-ospf to go experimental."
>
> That's what the working group decided in the end. If you had been 
> there maybe it would be clearer to you?
>
> On 11/13/06, Richard Ogier <[email-masked] 
> <mailto:[email-masked]> > wrote:
>
>     Acee,
>
>     [email-masked] <mailto:[email-masked]>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------
>
>Internal Virus Database is out-of-date.
>Checked by AVG Free Edition.
>Version: 7.1.394 / Virus Database: 268.13.22/512 - Release Date: 11/1/2006
>

---

From: Richard Ogier <[email-masked]>
Date: Tue, 14 Nov 2006 08:45:59 -0800

> public inspection and comparison with the other drafts.

We seem to be in agreement.  The question is, when will INRIA make
their (up-to-date) code available to allow a fair comparison.
The reason I am concerned is because I don't want to see a repeat
of the MANET debate between OLSR and TBRPF, in which there
was no cooperation to allow a fair comparison.  (I will avoid giving
the details here, since it might result in more arguing.)

One of the reasons I decided to work on the MDR design is because
there was a good plan for comparing the performance of the
different proposals (using GTNetS).

Richard

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 14 Nov 2006 09:36:05 -0800

> Sent: Monday, November 13, 2006 5:01 PM
> To: Richard Ogier
> Cc: OSPF List
> Subject: Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct 
> file appended
> 
> Hi Richard,
> Richard Ogier wrote:
> > Acee,
> >

Acee,
I agree with all of your above responses.

Tom

---

From: "Phil Cowburn" <[email-masked]>
Date: Thu, 16 Nov 2006 21:12:08 +0530

Acee,

>    How - 2328 can add other algs w/o too much problem

Yes it does, but debugging would be a nightmare! :-)

Let me not trigger a discussion again, i am ok with using the existing
type code!

>    Russ white: shold may become a must vs. should+ (better to say

I dont see any show stopper comments, so what is the status of the
auth drafts? There was a discussion on these drafts some time back and
the consensus was that the drafts would not be changed and we would
reuse the existing type code for additional authentication types.

If there are no further comments then should these be taken up as a new items?

>    LSA across areas - problem w/validation - so instead rev'd 2370

..

>    Lou: We should take to list whether MAY or SHOULD should be in

SHOULD sounds too strong to me. This is an implementation specific
issue and not all implementations may be able to prioritize OSPF pkts.
In view of this, a MAY should be sufficient as a recommendation from
the WG. Lets not word it any stronger than this.

>    Acee: Will validate on list that this is to become a WG document.

I am in favor of this.

Phil