Subject: [Ospf-wireless-design] Design Team Problem Statement

From: Acee Lindem <[email-masked]>
Date: Wed, 01 Sep 2004 10:48:49 -0400

I've struggled with this and here is what Joe and I have come up
with so far. I think it might be good to bounce it off the group
for opinions on what this should contain.

             OSPF Wireless Design Team Problem Statement

  The charter of the design team will be to select the initial
  set of OSPFv3 extensions in support of wireless (or MANET) networks
  and document these in one or more Internet Drafts. The extensions
  will become WG documents and will be reviewed by the OSPF and MANET WGs.
  The initial environment will be viewed as:

   1) Design team will focus on OSPFv3 and not OSPFv2.
   2) Compatibility with non-wireless OSPFv3 implementations must be
      maintained.
   3) Only Intra-area environments will be considered in the initial set of
      extensions.
   4) MANET wireless environments will not normally be a transit for
      wireline networks but this shouldn't be precluded.
   5) Number of nodes in the wireless network should be 50 - XXX (where XXX
      is what is acheivable given the technologies we have to chose from).
   6) When possible, mechanisms from existing MANET protocols should be
      leveraged.
   7) Technology without IPR claims should be preferred over technology
      with IPR claims (ala section 8 of RFC 3668).

  The simulation/performance work in and of itself is not a goal of the
  design team except in the context of evaluation of OSPFv3 extensions.

-- 
Acee

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

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Fri, 3 Sep 2004 11:35:02 -0400

Hi All,

Agree with most of the problem statement.  Two imbedded comments:

>   6) When possible, mechanisms from existing MANET protocols should be

I think we need to scope out the particular design aspects that we
will consider in order to have a focused effort.  Please 
refer to my email on 'DT Directions' for a suggested outline.  

I believe that we should tack on timelines and milestones to help
us be effective.

>      with IPR claims (ala section 8 of RFC 3668).

I hope we consider performance of the technology, and not reject a
design just because it has an IPR statement attached to it.  Especially,
since many IPR claims are purely defensive...as is Cisco's.

Thanks!
-Madhavi