[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: MANET Extensions to OSPF
From: Acee Lindem <acee () REDBACK ! COM>
Date: 2004-04-27 14:41:53
Message-ID: 020f01c42c65$c8d8ffc0$0202a8c0 () aceeinspiron
[Download RAW message or body]
There is significant interest in some level of MANET support in OSPF.
While this is relatively new to the OSPF WG, the idea has been discussed
in the MANET WG for some time. After a lengthy discussion among the routing
ADs and WGs, we would believe that we should pursue this work but
it should NOT preclude the work on MANET protocols that is being
done in the MANET WG. The integration of MANET and OSPF should be bounded
such that an OSPF implementation geared toward traditional enterprise
and ISP requirements should not be impacted by the MANET extensions.
Furthermore, at this juncture, we should not try to address all possible
MANET scenarios or statisfy extreme scaling requirements interesting
from a research perspective.
A strawman for OSPF WG scope is suggested below:
1. The work should be limited to OSPFv3. Mainly due to the fact
this keeps us from having to do it twice and the OSPFv3 design
point of running on a link rather than a subnet is more natural
for MANET. Additionally, there are far more OSPFv2 deployments
and limiting the discussion to OSPFv3 will limit the potential
impact of the extensions.
2. An OSPFv3 implementation that doesn't implement the MANET
extensions should not be impacted by the extensions. Furthermore,
failre to implement the extensions in non-MANET environments
should not result in any interoperability or degradation in
function.
3. Ideally, the MANET extensions would be modular enough that the
MANET unique considerations for future OSPFv3 extensions are
minimized. This is very hard to quantify.
4. At least initially, the OSPFv3 extensions should not be
subject to the scalability requirements of the MANET work going
on in the IRTF.
5. Since all the OSPF MANET extensions proposed heretofore suggest
flooding optimizations we have to very careful about where and
how we choose the boundary for the extensions.
6. Where both IPR and non-IPR encumbered mechanisms are proposed,
the WG will analyze the technical merits and will try to prefer
unencumbered technology without making technical sacrificies.
Thanks,
------
Acee
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic