Subject: [OSPF] Updated Minutes from IETF 65

From: Acee Lindem <[email-masked]>
Date: Fri, 07 Apr 2006 18:06:05 -0400

See updated minutes attached.
Thanks,
Acee
IETF65 OSPF WG minutes

March 23, 2006
Dallas, TX
Scribe: Michael Barnes ([email-masked]) 

09:00 CST

Administriva
------------
09:04

Review Agenda

Document Status
---------------
09:05

Editor's Queue Waiting
IESG Finished - Waiting on Activities
	Request to know who is implementing MTR
	Request to know who is implementing TE for OSPFv3
* Bill Fenner - OSPFv3 Auth has entered the editor's queue
* Acee - I know of at least 3 implementations

  Will do last call for "Advertising a Router's Local Addresses in 
  OSPF TE Extensions"

  Not add optimizations for "OSPF for IPv6" respin. Keep it as is.  

  OSPFv3 Graceful Restart going to last call. Soon to be two 
   implimenations.

  Waiting on two implementations for "OSPF Multi-Area Adjacency". 
   Was experimental, but going to make it standards track.

  More work going on MIB for OSPFv3

  Have seen customer need for "Extensions to OSPFv2 for 
    Advertising Optional Router/Link Attributes"

  Will consider taking "OSPF Link-Local Signaling" to standards track

Immediate Reply Hello
---------------------
09:16
Presented by Xiaoyi Guo (not Zengjie, as in the agenda)

Questions
* Acee - Do we want to make a document for this? Because a lot of 
  implementations just do this. Most routers just send a hello when 
  the interface first come up.
  For neighbor state changes, is only if BDR flaps, most routers 
  send hello immediately when they come up, so what's the advantage?
	Don't see an advantage of sending a hello when DR role changes
* Xiaoyi - Advantage is the then the DR can quickly become the BDR
* Acee - but most routers send the hello anyway when they first come up
* Acee - take to list

* Acee - regarding the part of going straight to 2way state, also
  some routers do this already.

* Mike Shand - The issue of whether we want to standardize is whether 
  it affects interoperability. It doesn't seem to, so there is no 
  apparent reason to standardize this behavior.
* Padma Pillay-Esnault - Same comment as Mike. Implementation detail. If 
  using BFD will cover cases where interfaces are flapping. Most 
  implementations send hello when they come up. Question numbers shown 
  in the slides. Those numbers depend on implementation and would 
  probably not be accurate for many real implementations.

* Acee - How many people think it's a good idea to document?
	Mixed, little bit more for not.

Acee - More discussion on the list.

OSPF MPR Extension - Emmanuel Baccelli
------------------
09:30
Emmanuel Baccelli

* Tom Henderson - Wondering if you will make available the 
  simulation models?
* Emmanuel - Sure
* Tom - Can you describe the simulations?
* Emmanuel - These are canonical(?) results

* Acee - more time for discussions after all of the MANET presentations

* Acee - Note that point of this draft is that routers use the shortest 
  path to make adj decision.

OSPF MDR Draft Update - Tom Henderson for Richard Ogier
---------------------
09:43
Tom Henderson

Background information can be found in the mailing list archives.

* Philippe Jacquet - (was link quality considered for selection?)
* Tom - Not looked at link quality to date
* Philippe - 
* Tom - My understanding of the test, are not considering link 
  quality in the selection process
* Philippe - (think link quality is something which should be considered)
* Tom - When selecting MDR must consider multiple factors, but don't 
  think it's been studied
* Acee - Hesitant to get into link quality game because of differences 
  between radios. Difficult to standardize across radios.
* Tom - I think it is important to consider whether or not (to use 
  link quality)
* Philippe - Using link quality is a difficult problem
* Philippe - In your simulation do you use link quality 
  when compute the cost?
* Tom - I think the point (Philippe) made is at every hop there is a 
  SPF computation, from the perspective of the first node, and hence the 
  cost, is different because the links used in it's SPF are different 
  from the downstream links?
* Philippe - yes
* Tom - have not looked at the difference. Have looked at paths that 
  are selected using full topologies compared to path links using 
  overlapping relay and MDR case. But not at case described by new draft.

OSPF MDR Position - Tom Henderson for Richard Ogier
-----------------
09:55
Tom Henderson

(slide 5)
* Joe Macker - Question: Richard described k hop case, would be good to 
  show the algorithm is generalized, but really probably going to 
  implement the 2 hop case
* Tom - The parameter is among this set of neighbors, not 
  tuning the number of hops
* Joe - Assuming, pretty much looking at 2 hop neighbor algorithm
* Acee - Even if looking at 2 hop neighborhood, could still 
  have k greater than 2
* Philippe - What is the purpose of this selection rule? (backup MDR)
* Tom - What is the purpose of having backup MDRs period? The purpose 
  is to have redundancy in the MDR set. Say if the primary were 
  to fail, the backup would be sufficient.
* Acee - Gives you a disjoint flooding set from your two hop neighbors

(slide 6)
* Emmanuel - When have MDR and BMDR set, similar to case where regular 
  network, have property where both are sync?
* Tom - No, no guarantee that any two nodes which are sync with 
  same MDR have same BMDR

(slide 8)
* Acee - Note: usually stretch factor refers to data plane, but 
  in this slide refers to flooding plane

(slide 9)
* Philippe - MDR may not be optimal for all scenarios. MPR may be 
  a better compromise for more scenarios.
* Tom - There are a lot of options, we have not fully explored all 
  options in simulations, we have covered a lot of them. We have seen 
  better performance from reducing the number of adjacencies the most.
  We have looked at a subset of the parameters, the ones they feel 
  are more important. We feel the capability to drop the number of 
  adjacencies significantly is the best. Some of the properties that
  MPR talks about, like providing the shortest path, may result in 
  updating the flooding set much more often to maintain those properties. 
  Trying to maintain some properties looses others, it's a complicated 
  tradeoff. You have a higher rate of change when trying to keep the 
  properties that Emmanuel describes.
* Padma - I don't see how it is valid to come to these numbers without 
  doing simulations using MPR (new draft)
* Tom - There are statistics you can look at just using OR simulations
* Padma - I think these are not real numbers, simulations are not 
  like the real thing.
* Tom - This draft only published a few weeks ago so there was no time 
  for all those simulations 
* Padma - I think we should not be doing comparisons unless we have them
* Tom - MDR and OR have been on the table for long time. Emmanuel's 
  draft was only out in last month, so there was no time to compare 
  with that. But other models have been around for long time and 
  comparisons for these simulations are good
* Acee - GTNetS simulation code is available to anyone, so anybody can 
  take their ideas and do their simulations
* Joe - I have the same idea as Padma, but not as strongly. Studies 
  are good, I have been involved with simulations. But it's not so 
  clear to me regarding the tradeoff of MPR. Somewhat it depends on 
  the heuristics used, you can change the amount of rate of adjacency 
  change. I'm hesitant to jump to conclusion of the last two bullets 
  on this slide. 
* Tom - I'm reporting Richards claims. We have done ourselves looking 
  at OR spec, to do modeling. But not done a model the way Emmanuel 
  has (described in his draft).
* Emmanuel - Regarding adjacency reduction, (I think there is) 
  confusion. There is a difference between adjacency reduction and 
  topology reduction. These are different matters. One decreases the 
  number of packets verses the size of LSAs and the size of LSUpdates. 
  This hasn't been clear in the debate.
* Tom - Agree that there are two components. Looked at combining different
  aspects, combinations. If you're saying that in MDR case they are 
  the same, I disagree. MPR is analogous to a mode in Richard's testing 
  advertising only adjacencies. 
* Acee - point advertising 2way is one thing that SP uses that concept 
  to decouple flooding path from route computation. Not a new idea or 
  unique to Richard's proposal.
* Tom - Conclusion, Richard proposes that WG move forward with 
  MDR based design.

OSPF MANET DT Progress/Next Step - Tom Henderson
--------------------------------
10:28
Tom Henderson

* Joe - Clarification, I was looking at SP type of approach. Richard 
  has come up with way to look at MRP-CDS. I don't see it as off the 
  table. For the standard, we might want to pick one. But it is not 
  clear to me, they have similar benefits, adjacency formation one 
  is better. Flooding options are about the same. Kind of interested in 
  going forward with MDR but want to consider MPR-CDS.
* Tom - Would like to build out further (in simulation) Emmanuel's 
  proposal and see if MPR-CDS could apply to that. We can, in parallel, 
  have a draft that would take OR/SP off the table, and a new draft 
  based on MPR.
* Joe - It would be good to get past this issue.
* Emmanuel - Regarding Joe's comment re: MPR having more adjacency 
  changes: once (it is) decided that LSAs advertise links that are 
  not adjacent, then saying that MPR has more adjacency changes 
  is not correct, it depends on the scheme. I want to point out that 
  we have to be clear on constraints being looking at.
* Acee - I think with your approach you could get further if you 
  take into consideration if you already have an adjacency. Should 
  make the assumption that advertising 2way is okay, if they meet 
  other criteria, covered by CDS.
* Emmanuel - then if this is a constraint we give up, then claim 
  that MPR has a higher rate of new adjacencies is wrong.
* Tom - What I've seen is that MPR does create more adjacencies because 
  of source specific nature. Rate is affected by other elements 
  such as adding permanence for selecting MDR, neighbor quality, etc
* Emmanuel - Don't understanding if you use MDR how get more adjacencies
* Tom - Need something in the algorithm to make sure the adjacency 
  set remains connected. MDR gives you essentially a backbone that 
  stays connected. If use another approach, what is it?
* Emmanuel - Decouple adjacency, what is advertised, from flooding. 
  So it is wrong to just talk about adjacency rate.
* Acee - Can not decouple the adjacency path from flooding path, 
  because we took it as a constraint that OSPF has reliable 
  flooding, and retransmit along adjacencies.
* Philippe - Are you sure that by advertising LSA, it is not going to 
  create much more traffic then created with new adjacencies?
* Tom - If you advertise fuller LSAs then it must increase 
  flooding because higher frequency of updates.
* Philippe -
* Tom - We've able to isolate different comp, diff adjacency strategies 
  with different topology strategies. One study is looking at full 
  adjacencies to partial adjacencies, could be done with topology too.
  There is a benefit to reducing topology in LSAs because adding more 
  neighbors increases frequency when LSAs are updated.
* Acee - Let's keep as future work
* Joe - Historically, when design started, we decided to have non-goal 
  to overoptimize the protocol. When we get to point where it is close, 
  then probably should stop. 1% improvement not worth to add complexity.
  Fitting into the OSPF framework, is still a goal.
* Acee - agree.
* Bill Fenner - have a lot of experience with spinning when have multi 
  protocols that do the same thing. If that's what we're doing, then 
  find a way to break the loop. Encourage everyone to break the 
  loop themselves.
* Acee - When kept on looking at simulation results, from that env, it's 
  obvious that the MDR solution with bi-directed subgraph intuitively 
  has better result. Regarding complexity, we need more people to work 
  on optimizing the algorithm. I would disagree with Richard that it is 
  simple. but remember back in 1991 that folks thought that basic SPF 
  was complicated. Now this is not true. Same thing with disjoint 
  path algorithm. (Folks should) spend the time (studying the algorithm) 
  to get an intuitive feel for it. Just picking a subset of people 
  to flood with. Move forward with this, also evaluate the MPR proposal. 
  Another option, open up like at beginning of MANET, allow a number 
  of proposals - but I doubt we'd ever converge. 
* Thomas - Our MPR I-D was not intended to be a monkey-wrench in the process but a
  technical contribution -- we did not know that a decision essentially had already been
  taken on this matter and that technical alternatives were not encouraged.
* Acee - Trouble reaching consensus. Apologies to folks who were 
  surprised. Not a WG consensus, just among others on some of the draft. 
  Just a rough consensus. Encourage putting MPR draft into simulation 
  to see how it fares.

OSPF WG Charter - Acee
----------------------
10:51

Lot of things being worked on which are not on the charter.

* Tom - MANET topology reduction on charter?

OSPF WG Charter Discussion
--------------------------

* Kiretti Kompella - question on TE
* Acee - will last call that
* Kiretti - not talking about as new charter item, but 
  talking to Dmitri, merge drafts. 
* Acee - if we do ASON, that is big enough, would be charter item.
* Kiretti - ASON just put in /32 vs /128s, could make single TLV. 
  Fact can be used by ASON is orthogonal. Political issues on 
  whether to merge or not.
* Acee - Call TE node prefix.

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