Subject: Re: Proposal for OSPF MANET Extensions Design Points

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 16 Jan 2004 09:37:21 -0800

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]]
> Sent: Friday, January 16, 2004 6:49 AM
> To: [email-masked]
> Subject: Proposal for OSPF MANET Extensions Design Points
> 
> 
> I believe that for the foreseeable future the vast majority of
> networks will be fixed (although they may support wireless hosts).
> Based on this belief and the fact that what is being proposed for
> MANET is very different from base OSPFv3 I'd like to propose the
> following design points for the work:
> 
>     1. A fixed network OSPFv3 implementation shouldn't require
>        changes to fully interoperate with an OSPFv3 implementation
>        supporting the MANET extensions.
>     2. The MANET extensions should be limited to wireless 
> interfaces (or
>        whatever level of segregation we end up with).
>     3. As much as possible, an OSPFv3 implementation with the MANET
>        extensions should be a proper subset of an OSPFv3 
> implementation
>        without the extensions. In other words, we should be extremely
>        suspect of changes to basic OSPFv3 mechanisms.
> 

I agree with 1 and 2.  As for 3, extensions cannot be a proper subset
by definition (perhaps "superset" is intended?).  While I sympathize 
with the last sentence of 3, I think that being too conservative in
the possible design of the extensions will constrain the achievable
performance.  I would rather state that "For the MANET extensions, 
departures from basic OSPFv3 mechanisms should be justified by suitable 
performance benefits."

Tom

---

From: Acee Lindem <[email-masked]>
Date: Fri, 16 Jan 2004 13:28:15 -0500

Hi Tom,

----- Original Message -----
From: "Henderson, Thomas R" <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 16, 2004 12:37 PM
Subject: Re: Proposal for OSPF MANET Extensions Design Points

> departures from basic OSPFv3 mechanisms should be justified by suitable

I guess this is where the "as much as possible" comes in. It would be
nice if it looks like a single protocol with an extension for MANET rather
than two protocols that have been munged together.

Thanks,
Acee

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 24 Jan 2004 09:46:16 +0100

>than two protocols that have been munged together.
Here my spare change after reading the drafts hanging out to dry and having
thought about the issue for a while. The  hat I'm putting on is that of
a vendor
having a stable implementation with large deployments in the field and
being
interested in least painfull customer adaptation (not necessarily my current
job situation but from experience the best hat to assure wide-adoption of a
work like this in the field, the metric of success I perceive as the most
practical one for IETF.).

(i) Don't make it a separate protocol. It will duplicate the amount of
code around,
    be close-enough to ospf to be confused with it but on the other hand
not-ospf so
    people using ospf concepts to talk about it will end up confused by
subtle differences
    in the way it works.
    This kind of confusion mirrors itself in
configurations/architectures and
    resulting networks. And of course, spinning out a new protocols
    will take much, much longer than any
    of the parties putting forward such a proposal dare to admit it will.
(ii) I think any resulting solution will change the flooding procedures
in very non-trivial ways,
    therefore I am against an 'interface'-type.
    Pretty much all interface types share the flooding code in any
implementation  I saw
    and mudding with it that heavily will cause deployment problems
    with existing/deployed interface types. Even if the spec is clear
and concise, implementing
    and testing flooding changes on a large scale is very risky. I would
suggest that
    having an 'manet-area' like an nssa-area is the best solution. It
leaves for existing
    implementations an easy option to not implement such an area type,
the option to
    implement different flooding code based on area type (subtle but
important difference
    from having a flooding code  per interface type). An area is
    easily containted deployment wise (so if manet changes cause
troubles, it will
    be area contained), it will be much easier to debug/correctly
interoperate than an area
    with mixture of
    manet and non-manet interfaces since the translation on area
boundary will allow to
    track/isolate problems caused by flooding within manet.
    The manet area could be done as 'some-other-area-type'
    like nssa-area or as superset of standard ospf area so e.g. manet
area could have a completely
    new lsa type, rather than trying to trick manet work into existing
types or heavily use
    opaques which one could argue is not a very elegant solution.

    thanks

    -- tony