Subject: OSPF WG Direction with respect to MANET Requirements

From: Acee Lindem <[email-masked]>
Date: Tue, 25 Nov 2003 14:56:59 -0500

At the Minneapolis OSPF WG meeting Fred Baker presented the
  MANET requirements for OSPF. On the surface, MANET seems to imply
  some substantial changes to OSPF. These include changes to the
  hello protocol, DR election, flooding, LSA origination, and
  summarization. At this point, it seems we (the OSPF WG) has a
  number of ways in which we could proceed:

    1. Do nothing - Leave MANET to the routing protocol(s) currently
       defined specifically for the MANET environment.

    2. Define a OSPF-MANET boundary node which streamlines the
       interfaction between the chosen MANET protocol (hopefully
       one) and OSPF.

    3. Define extensions to OSPFv3 which allow for one of more MANET
       clouds to connect to an OSPFv3 backbone. The extensions should
       be such that the base OSPFv3 network is insulated from the MANET
       extensions so that OSPFv3 nodes not supporting the extensions
       could co-exist outside the MANET cloud without changes. I say
       OSPFv3 here since everyone at the WG meeting agreed that IPv6
       was a requirement for MANET and everyone at the WG meeting
       agreed that  any substanitive extensions should only goto into
       OSPFv3.

    4. Define a new protocol (OSPFv4) which attempts to satisfy
       the requirements for OSPFv3 and MANET. It should be as
       close to OSPFv3 as possible (but leaves out virtual
       links :^).

    5. Other ideas (since the above are only the ones I thought of)?

  At this point, we need to discuss the direction which we want to take
  and, depending on the direction, how the work should be split between
  us and the MANET WG. I know the MANET WG is also anxious to make
  a decision.

---

From: Fred Baker <[email-masked]>
Date: Tue, 25 Nov 2003 15:35:12 -0800

Acee:

>        close to OSPFv3 as possible (but leaves out virtual

I think there is at least one other approach that has been suggested, which
you have overlooked. IMHO, it is the simplest model.

In Alex's comments to Abhay Roy, he talked about a Manet Area. This
approach seemed to convolute the fundamental concepts of OSPF.
Operationally, one certainly wants to tie a string around the set of router
interfaces that form a manet network or part of one, both to constrain
their disruption of other parts of the network and to constrain the
interactions between similar-but-different manet networks. But
mobile-ad-hoc-ness is not fundamentally a characteristic of the area. The
area is a standard OSPF construct that one uses at an administrative or
policy boundary to ensure that proper summarization happens and unnecessary
changes are not propagated.

In your remarks, you talk about "extensions to OSPFv3 which allow for one
of more MANET clouds to connect to an OSPFv3 backbone". The manet cloud,
from the sound of it, is using another routing protocol. If you want to do
that, we can already do that - leaking routes between routing protocols is
something we pretty standardly do. But route leaking is not very pretty,
and we were hoping to not have to re-invent OSPF (areas, metrics,
multi-topology routing, and all that) to accomplish this. Heck, if we
wanted to go there, we would simply extend EIGRP, or adopt OLSR and extend
it with the things it needs to be deployable on a wide scale.

What we are proposing is something much simpler. We would like to add a
manet interface type to OSPFv3. The addition of this interface capability
is entirely optional - an implementation that never expects to be deployed
in a radio network need not implement it, and can fully expect to
interoperate with implementations that have implemented it, on their
non-radio interfaces.

The MANET interface is different from a standard serial interface (as it
has multiple neighbors) and different from a LAN interface (it has no DR).
I don't see that as a fundamental impediment; remember that about eleven
years ago I pointed out that the NBMA interface didn't work very well in
Frame Relay networks of the day and proposed what we now call the
point-to-multipoint interface. Adapting OSPF to new interface technologies
(F/R being fairly new then) is something that has always been integral to
OSPF's development. To throw out the idea of a manet interface because it
is different - well, that would be a step in conservatism that would cause
me a great deal of concern. I understand and very much support the
conservatism that says "don't break what already works". But conservatism
that prevents OSPF from addressing new requirements declares OSPF an
obsolete protocol, and forces new requirements into a new protocol. I don't
think of OSPF as obsolete...

Can you tell me why adding a manet interface to OSPF is not on of the
options you are willing to consider?

---

From: Acee Lindem <[email-masked]>
Date: Tue, 25 Nov 2003 22:12:52 -0500

Fred,
See inline below.

> approach seemed to convolute the fundamental concepts of OSPF.

This would be an instance of #3. A separate area type may or may not be
necessary to insulate non-MANET routers from MANET routers.

> changes are not propagated.

I agree that a MANET area is not cast in stone. However, on the surface it
would seem like a good  way to segregate the MANET extensions from base
OSPFv3.

> something we pretty standardly do.

This is option #1. There are 3 other options listed.

> But route leaking is not very pretty,

If the MANET interface can be added without significant modification to
the basic OSPF mechanisms (e.g. the P2MP interface was a natural
extension sinnce
it  operates very similar to a mesh of P2Ps) then this would be an
instance of option #3.
If  OSPFv3 will need to changed significantly to meet the MANET
requirements then this
should be a separate option (option #5).

Anyway, it for the OSPF WG as a whole to decide. Maybe it
is best to put forth the MANET interface proposal for technical review.

Thanks,
Acee

---

From: Russ White <[email-masked]>
Date: Fri, 28 Nov 2003 10:24:12 -0500

This would be my preference, at an interface level. We could call this an
"area" level, and it might be an area boundary to the "wire line" ospfv3
cloud, but I think that from the MANET side, it's slightly dangerous to
think of it as an area border, since the concept of a flooding domain/area
becomes much more ambiguous.

So, I think I would put it this way:

-- Define extensions to OSPFv3 that will not impact current wire-line
implementations.
-- Bound these extensions at an interface and/or area border, depending on
what investigation turns up in technical discussion, so the wire line side
is not impacted (see above).

And finally:

-- Once these extensions are completed, tested, and proven to work,
consider moving any such extensions back into OSPF as it might be
considered advantageous at some future point.

So, the way I would approach it:

-- Do a small "technical working group," so that those interested can go
"off on the side" in a public way without making the ospf wg mailing list,
itself, a major thoroughfare. I suspect that just about everyone would
subscribe to this "off on the side" list, which is okay, as long as it
seperates the traffic, most likely. And, we could conciously bring in the
MANET people in this way.

-- Set some timetable/goal for producing output, some set of drafts,
possible competing ones, that will be presented at some definite meeting in
the future.

-- Let the sparks fly.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone