Subject: Minutes from OSPF WG Meeting in Washington, DC

From: Acee Lindem <[email-masked]>
Date: Wed, 17 Nov 2004 22:18:41 -0500

Thanks to Richard Rabbat for taking the detailed minutes.

Acee
Minutes for Open Shortest Path First WG (ospf)
Monday, November 8 at 1300-1500

SCRIBE: Richard Rabbat <[email-masked]>
CHAIRS: Rohit Dube <[email-masked]>
        Acee Lindem <[email-masked]>

o Document Status 10 minutes (Rohit)
   - 1 rfc published
   - 3 to be published soon: OSPF DN Bit, Graceful Restart Implementation
     Report,Flooding Optimization in stable environments
   - Scalability draft had couple of comments by IESG to be addressed
     by authors
   - In AD evaluation: OSPF v2 mib and multi-area adjacency
       Bill Fenner: OSPFv2 MIB Went through review, looks like has to go to
                    professional MIB reviewer for extra review
     Multi-area adjacency: many solutions, WG decided to published
     simplest of them. No implementations yet.
   - Close to last call:
      * Extensions to OSPF for advertising optional router cap
      * Advertising a router’s local addresses in OSPF TE extensions
      * Authentication/confidentiality for OSPFvd
   - WG discussion:
      * OSPFv3 MIB
      * TE extensions to OSPF v3
      * Support of address families in OSPFv3
   - New WG documents:
      * MT-OSPF: Multi-Topology (MT) routing in OSPF
        Discussed in San Diego: no dissention
        Two MT proposals: one for v2
        Semantics are different
        The OSPFv3 multi-topology from an OSPF perspective seems radical.

o RFC 2740 Respin 10 minutes (Acee)
  - OSPF v2 RFC has gone through several iterations. We’re now at 2328.
  - OSPF v3 has not had an update
  - Goals:
    * Fix errata that have accumulated
    * Ambiguities
    * Include omissions including features that lack specification
    * Bugs in protocol
    * Deprecate unused features
    * Acknowledge correction contributors
  - Went through some errata:
    * Section 3.4.3.7: intra-area-prefix
    * Appendix: LSA field sizes wrong
  - Ambiguities:
    * Interface instance ID
    * Forwarding addresses and link locals
  - Include omissions:
    * NSSA additions
    * Input/output processing additions from Nic Neate
    * SPF calculation handling of LSAs with v6
  - Protocol bugs:
    * Fix to mitigate the effects of DoS attack using Max Sequence LSAs
      with high checksum because the checksum in the order above the
      age (hard to purge) applies equally to v2 and v3
  - Deprecate:
   * OSPF external attributes LSA
   * Reference to site local addresses
   * MOSPF: Probably will leave it in in case it makes a resurgence
  - No questions

o OSPFv3 MTR 15 minutes (Sina Mirtorabi)
  draft-mirtorabi-mt-ospfv3-00.txt
  Abhay Roy/Sina Mirtorabi
  - Last IETF meeting: v2; This IETF: v3
  - MTR v3 goal
    * Define multiple independent topology within a physical topology
  - Potential solutions
    * Instance ID approach
    * Use integrated approach with existing LSAs: problems
 - Proposed solution
    * Define new LSAs to carry MT information
    * Ignored by legacy OSPFv3 routers
    * New use TLVs for extendibility in extended LSAs
    * MT-ID field: 8 bit field present in LSA
    * MT routing operations:
       - Single adjacency formed even if the link participates in
         multiple topologies.
    * v3 control packets..
    * Default topology
    * Topology that is built using the exiting LSAs as specified in v3
    * Defined 2740 compatibililty…
    * NEW LSAs
      - New lsa payload are TLV based
      - tlv may contain sub-TLVs
      - Extended router LSA has link description TLV
      - Other extended LSAs are similar with TLVs
      - If all routers are MT capable, only extended LSAs are used
        for the default topology
    * Asked to be WG document
  - Discussion
    Acee: once you accept new TLV, you may need to accept unknown TLVs as well.
          Urged everybody to read this and try to do something about
          ordering of TLVs to add a little more structure than ISIS
    Sina: Agreed
    Alex: Not entirely new to OSPFv3. Meed to accept unknown LSA’s so it’s
          already there
    Himanshu (Ciena): Not following motivation. If you get data packet on
          a single link, how do you distinguish the MT?
    Sina: Neither MT-ISIS, v2 or v3 have considered forwarding aspect.
          It all depends on how you color packet. In those drafts, we’re
          only looking at control plane
    Alex: Had a discussion with ISIS guys. There are considerations in
          the draft. We need to have a document one way of doing this
          in interoperable fashion. We can take it to routing WG. From the
          aspect of interop, need to have a single way to demultiplex
          packets in the case a link belongs to multiple MTs

o OSPF Wireless Design Team Status (Tom Henderson)
   - Met in San Diego and discussions continuing since
   - Agreed on problem statement
   - Several initial agreements on work scope
   - Summarize current technical discussions
   - Next steps
   - DT chartered to produce initial set of v3 extensions for wireless
     (motivated by draft-baker-manet-ospf-problem-statement)
     Some extensions would become wg documents and reviewed by MANET
     and OSPF WG
   - Problem statement:
     * Focus on v3
     * Compatibility with non-wireless v3
     * Intra-area extensions only
     * Not focusing on transit network case but not precluded
     * Scaling goal to 50-100 nodes in wireless channel
     * Leverage existing MANET work where possible
     * Use RFC3668 guidance in dealing with IPR claims
  - Consensus reached so far:
     * Agreed to define new MANET interface type rather than a MANET area type
       (parallel with existing OSPF interface types)
     * Focusing on designing an optimized flooding mechanism for new LSA
       generation
     * Using acknowledge (reliable) flooding
     * Unacknowledged periodic flooding future extension
     * Hybrid operation also a future possibility
  - Optimizing flooding behavior in broadcast wireless network
     * Reduced # of xmissions to reliably disseminate LSAs
     * Robustness
     * Must make sense within ospf framework-minimize change to ospf
     * Trying to leverage previous work: source-dependent vs.
       source-independent relay node sets (connected dominating sets
       in the literature). Considering tradeoffs
     Joe Macker: MANET WG chair: nNot necessarily dependent on who sent it
                 but the previous hop
     Acee: Example of source-independent is if you try to create shortest
           spanning tree for the whole domain.

 - Simulation evaluation of flooding alternatives
   * In the process of releasing simulation environment for the team
   * Consider whether to define additional wireless optimizations
     (proposals to make hello message to be differential, to optimize
     database exchange procedure) or to send them to next work
   * Target draft submission to March IETF
   * Simulation results will be made available
   Alex: Question about unreliable flooding. Wanted the solutions
         to be in the framework of OSPF design.
   Tom: Having an un-acked mode of operation may be approximate
        reliable flooding.
   Alex: Still need to change OSPF mechanism and flooding paridigm.
   Tom: There have been proposal to change timers
   Alex: Is the end-result unreliable flooding mechanism?
   Tom: It would still be reliable with backoff of retransmit timer
   Alex: Maybe that should be kept in MANET WG.
   Tom: DT has decided to work on reliable flooding at this time.
   Rohit: To summarize, flooding is now kept as reliable as OSPF

   Acee: Work is moving along. As a consequence of no proposals for
         OSPFv2 wireless, we’ll continue with this on top of OSPFv3.
         It seems that this is the protocol that vendors want in OSPF WG.

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 19 Nov 2004 01:56:35 -0800

Hi,

Reading the minutes I figured out some work is being planned for
simulation evaluation of flooding alternatives.

We may want to have a look at
http://www.watersprings.org/pub/id/draft-choudhury-manral-flooding-simul
ation-00.txt ,on which we worked on quiet a while back.

One of the things I recollect while working on OSPF and IS-IS, was that
OSPF required the entire database of the neighbor before it could
figure-out which LSA's were missing, in IS-IS this was pretty simple and
straight forward. If we defined an order of sending LSA's this
restriction could be easily got over.

Thanks,
Vishwas

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Thursday, November 18, 2004 8:49 AM
To: [email-masked]
Subject: Minutes from OSPF WG Meeting in Washington, DC

Acee