Subject: IETF WG Meeting Minutes

From: Acee Lindem <[email-masked]>
Date: Thu, 17 Mar 2005 13:39:59 -0500

Thanks to Ryan Elliot for taking minutes at the last meeting. Please
send any corrections or updates directly to me at [email-masked].

Thanks,
Acee

     IETF OSPF WG Notes - March 8th
     Taken by Ryan Elliot ([email-masked])

1. Administrivia - Blue sheets, etc.

2. Document status

  Published:
     - DC inactive Neighbor Detection

  RFC Editor Queue:  
    - Using LSA options Bit
    - Graceful Restart Implementation Reoprt
    - ReFresh and flooding reduction
 
  IESG Review:
    - OSPF v2 MIB
	* All issues have been addressed. Needs MIB doctor review.
    - Prioritized Treatment of OSPF packets
	* In another revision with comments
    - Authentication for V3
	* Comments for security AD
	* Authors need to have a look
    - Multiarea Adjacencies
	* Awaiting a date on tele-chat.  

  Close to WG Last Call:
     - OSPFv2 Multitopology Routing Draft
     - Extensions for advertising optional capabilities
	* Question: on inclusion of flags. Or do we remove flags?
	* Question: Do all users advertise capabilities? How does a neighbor trigger 
          someone to look into the flags?	
	  1. Should we include the definition of capability flags
          2. Should the informational flags be included at all
          3. Can we advertise the capabilities at different levels.
        * Acee understands issues, they are known issues, and need to be 
          worked over until everyone is happy

     - OSPFv3 TE Extensions
 	* Not many changes in the last 2 years
	* Acee has taken over draft

  Need better/more review:
      - OSPFv3 Update
      - OSPFv3 Support for AF's
      - OSPFv3 Graceful Restart
	* Might not be so urgent

  Expired documents
      - Advertising Local Addresses in TE extensions
	* This is being referenced by other docs, we need to keep it updated
	* Methods used in this doc are being used, what can we do here?
	* Answer: Check w/ the author (already reminded author) to refresh draft
	* Send an e-mail to list on draft, maybe we can add an author to 
          keep it refreshed.

      - MIB for OSPFv3
	* We are working on v2 first, will get back to it.

3. Handling of unknown Link Types - Acee Lindem for Vishwas Manral

  Brian Field - Comcast - Handling of unknown link types is not handled in v2 or v3

  * there are no deterministic ways of handling
  * There is the Manral draft, which has behavior defined
  * 3 things we can do here
      1. Ignore
      2. Ignore and log an unexpected
      3. Reject LSA
  * Consensure is to ignore unknown types, but want to be conservative 
    what we are going to Add.
  * Quesion: Do we need to document? (Acee)
  * Answer: (Alex Zinnin) - Does anyone see a problem? Ignoring will lead to inconsistent 
    routing table, .  The only realistic measure is to raise all possible flags.  We find 
    unknown because 1. Bug is causing 2. New type of link introduced, but what if we have 
    a network w/ routers which know and don't know link type.  Need some type of capabilites 
    negotiation if htere are multiple inconsistent routers.  Doesn't think ignore (Option #1) 
    will work.  #3 (Reject LSA), not sure there is enough detail to understand consequences.  
    Does it fall in line w/ algorithms?  Are we going to stop SPF?  We need to drop traffic, 
    so it's not looped, so we don't consume bandwidth.
  * Acee: there is a section of backwards compatibilities in the draft. there are some holes; 
    If we ignore, what do we do? Could be a 4th option to do nothing since we've gone this
    long without formally defining. 

3. OSPFv3 Multiple Interface on Link - Michael Barnes

  * 2740 draft - Section that was missing on "Multiple Interfaces to a Link" 
    (Michael Barnes) - Section 3.9 enhancement
  * Too ambiguous - Original spec didn't answer all questions
  * Specifices that router should support having multiple interface on same physical link. 
    OSPF v3 carries int ID in hello's, we should use that to recognize received hello packets that 
    were sent out on another int on the router.  v3 supports multiple instance ID's, need to 
    ensure that if instances are different thta there is no interference.  If instances are the same, 
    then we have multiple interfaces on same link. Each instance would have own adjacencies, link 
    LSA's, etc...   One interface would be active, continue to send/recieve packets, other 
    interfaces will monitor hello packets from other int, but won't send packets. Designate 
    "Active" and "Standby" interfaces.
  * All interfaces must be in the router LSA to be considered in the SPF
  * Need to generate link LSA for standby interfaces - Need to be flooded over the active 
    interface. Prefixes for standby must be included in LSA's. 
  * If active goes down, there are multiple mechanisms
    1. Monitor hello packets on standby - 
    2. If active is admin brought down, elect standby to become active
  * During SPF - When examining network LSA, must examine to include all links as 
    next hops. Maybe create a list of links, process
  * Keeping track of secondary standbys - New state for state machine.  A standby state 
    for the interface defined as;
	1. Interfaces detects that it's multiple - Triggers link event, puts into standby mode
	2. If another interface causes standby - Then standby will transition back to waiting, 
            then trigger interface up event.
  * Comments
     - Acee - If we follow 2740, there are steps that are taken care of, and remain 
       backward compatible. 
     - Michael - No change to doc, just clarification, and mechanism to detect multiple 
       interfaces, and the state.

4. OSPF Manet Design Team Status - Tom Henderson
    - Manet design team - What kind of extension are possible to add to OSPF protocol to enhace 
      performance in MANET environ.
    - Background
	* Manet WG standardized experimental RFC's
	* Can we borrow principles and apply to OSPF?
	* Maybe define extentions to OSPF for performance
	* Needs written up in problem statement authored by Fred Baker
	* OLSR like adaptations were discussed
	* Charter this design team, meeting informally and on mailing list
    - Review Ground Rules
	* Focus on OSPFv3, not v2
	* Compat w/ non-wireless v3
	* Intra-Area extensions, not on transit network case
           * Output shouldn't preclude though
	* Scaling goal is 50-100 nodes
	* Leverage existing MANET work
	* Use RFC 3668 guidance for IPR
     - Consensus
	* Define a new MANET interface type instead of an Area type.
	* Not match on current interface types, but there were some that are close, 
          maybe a hybrid approach to what we have
	* Design optimized flooding mechanism - Simulation proved that LSA dissemination gave too 
          much overhead, which centered the focus here.
	* Additional optimizations as a lesser priority
	* Focus on 2 active I-D's
     - Both drafts focus on selecting more efficient Relay Node Sets (RNS)
	* Strive to form "Connected Dominating Set" (CDS)
	* If only a subset of nodes could reflood LSA's, there would be minimal tranmissions
     - Difference between drafts
	* 2 constructs - Source Independent vs. Source Dependent - If a node is a CDS, 
          does it forward all LSA's, or a consideration of who send it to you?
	* Hello's vs. LSA's for 2-hop neighbor info
	* Ogier draft addresses minimizing # of adjacencies
     - Review of draft-chandra
	* Slide 6 on presentation
	* How is flooding efficient, would all routers downstream need to reflood? no
	* Protocol dtermines which one-hop neighor would notify the two-hop neighbors
	* A router will have the two-hop neighbor info to determine
	* Main difference between this and OLSR is that this flooding process 
          is ack'ed, so it's reliable
	* Exchange of info is ensured to be successful
	* Creates a non-active relay, and if no ack it turns active
     - Preview of draft-ogier
	* Each router will ensure that their 2-hop neighbor update is taken care of
	* One difference - If we have a set of "relay nodes"
	* An algorithm would be run to select relay nodes - regardless of where the 
          info is received from, the flooding will be done.
	* Terminology is "designated" vs. "backup-designated" router
     - Design team is evaluating both proposals - 
	* Developed implementatin of Chandra's draft in quagga
	* Working on implenting Ogier's draft
	* Next meeting targeting results and decision.
	* Questions the team is trying to answer
           - Stability of relay node set selection
           - Overhead
           - Robustness of routing
           - Stratch factor on data and overhead
           - Runtime complexity
	* Initial results 
           - Most overhead is due to LSA flooding
           - Make flooding efficient
           - Minimize # of LSA'a generated
           - Chandra's *DOES* reduce overhead by focusing on efficiency
     - Next steps
	* Goal to select flooding algorithm by next IETF
	* Implement Ogier's draft simulation
	   - Focus on optimized flooding
     - Questions
        * Question (Rohit): Is it a goal to have a single recommendation between 
               the 2 drafts?
           - Answer (Henderson): Not explicit goal, but probobly implicit. 
             Trying to drive to 1 recommendation.

4. Manet Extensions using CDS Flooding (Ogier's draft presentation) - Richard Ogier
    - Richard could not make it, Tom is presenting
    - How can we find the subset of nodes that will be relays?
    - Core idea - Generalize router concept in Broadcast environment
    - Connected dominating set might be a group of nodes, rather than the single one in a 
      broadcast environ.
    - It has the concept of a backup designated router in the wireless case, we can have 
      "backup" nodes which has adjacencies formed, adding robustness and redundancy.
    - Algorithm in draft includes concept of CDS - Uses 2 hop neighbor info to elect 
      CDS nodes.
    - Verify w/router priority and router ID, self-elected as DR, else, a neighbor has a 
      higher priority.  
    - If all neighors cannot be covered by neighboring router, then it will not elect itself
      and the neighbor will be a dependent neighbor. Backup DR is similar.
    - 2 variants - 1. Persistent version 2. Non-persistent version
    - Algorithm O(d2) - 
    - There is a family of CDS algorithms, depending on needs of robustness, if relay set 
      size grows, then tranmission w/ grow. Trading overhead to gain robustness.
    - Router priority - How do we determine: Capacity, willingness, stability
	* These can be adjusted in these algorithms
	* Advertized to neighbors
    - Adjacencies
	* Only formed between designated, backup, and Dependent Neighbors.
    - Comments/Questions:
        * (Macker) Addition to tradeoffs, how do we test? Can we have fast repair? Dependency on how 
          election occurs, and # of adjencies.  What about how can we repair faster, look more into 
          mobility scenarios, and more info nodal failure.
        * (Henderson) Agree
        * (???) Clarification on algorithm - Is it distributed, answer, yes. Since differnet 
           nodes will have differnet neighbors, won't different subset's elect different DR's, 
           backup DR's?
        * (Henderson) Role in adj forming, if a node selects itself as a DR, then announce it 
           it's neighbors, and all dependent routers.
        * (???) What is router doesn't elect itself as a DR?
        * (Henderson) take offline to answer
        * (Macker) Additional dependencies on the algorithm, on the election process.
           Look into failures - More decisions and re-negotiations.
        * (Henderson) Agree will be interesting to look at.
    - Simulation in Mobile Networks
	* Persistent version of Essention CDS algorithm.
	* Average # of designated and backup DR's
	* Number of adjacencies
	* Details in slides
    - Conclusion of Simulation
	* Richard believes CDS is more scalable
	* Believes DR/BDR generalized naturally and efficiently w/MANETS

5. OSPFv3 Protocol Extension - Acee
    - History of extension chronology
	* Added base v2 protocol
	* Added MOSPF, Type 6
	* NSSA Type 7
	* Opaque LSA
	* v3
	* Graceful restart
	* v2 TE
	* v2 MTR
   - Options	
	#1 - Continue adding new LSA tyupes for v3, new opaque for v2
	#2 - go 100% TLV based approach, like ISIS
	#3 - Evolve TLV based on LSA types. 
   - Advantages of Option #1
 	* Potentially smaller LSA's
	* Advertisements contain only changes
	* Maintains status quo
   - Advantages of Option #3 
	* No sync issues between LSA's. Fewer lookups, less searching
	* Flexible extensions whi mainaining LSA granularity
	* Fewer LSA's to manage
	* Unified approach for protocol extension
	* Other IGP's won't be able to say were inflexible  :) 
   - Vision - Single IP IGP for Enterprise, ISP, and wireless
   - Questions if #3 selected
	* What happens to v2 in the near futue, do we revisit that?
	* How do we control protocol bloat?
   - Comments/Questions:
        * (Alex Zinin) Do we redifine existing standards of LSA's, or preserving that, and 
          moving on to new LSAs?
        * (Acee) Keep LSA's around, then after an area is moved to a new extension, 
          then revisit, at some point the flooding domain can only use the new LSAs.
        * (Russ White) Looks like we can make v3 better than v2.
        * (Alex Zinin) Questions/discussion come onto the list.