Subject: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 5

From: Aniket Desai <[email-masked]>
Date: Mon, 02 Oct 2006 19:16:50 -0400

At 06:41 PM 10/2/2006, you wrote:
>IMHO, it doesn't matter what you think is a "natural" and "unnatural"
>extension to OSPF. What should matter is the requirements, and the way
>to solve those requirements.

- Let's say OSPF-MDR is a natural way to extend OSPF's broadcast 
interface for MANET type physical medium. It should be an acceptable 
term. What requirements does this solve: scalability, scalability and 
scalability.

>I didn't ask you to stop saying "this is natural" because I have any
>thoughts on what's natural or not, but rather, because it doesn't lead
>to any useful discussion. Tossing words with emotional connotations into
>the conversation doesn't clarify it in any way, shape, or form.
>
>I could, in fact, argue that just about _any_ extension to OSPF is
>"natural," in some sense or another. It's a meaningless concept, in this
>world.

If you agree that OSPF is about maintaining a connected/biconnected 
adjacency graph that is rooted towards its leaders (DR and BDR) which 
are also the *forwarders* of data on this graph, then the CDS concept 
and the subsequent MDRs make perfect sense. That is how scalability 
should be achieved in OSPF. In this design, each node tries to form 
adjacencies that are aligned towards the leaders, and the leader 
*backbone* (i.e. CDS) will forward the LSAs originated by everyone 
everywhere. Also *very important* part is that each node determines 
its own status, which is known universally (not like MPR, where any 
given MPR has no universal context and hence I believe will fall 
seriously short of scalability). Inherent robust mechanisms can also 
elongate the lifetime of an MDR and all that an MDR-other node needs 
to do is find its best MDR and continue to remain adjacent to it as 
long as possible. This makes core adjacency graph as stable as 
possible. I find this design brilliant and in the true spirit of OSPF.

I have to say that this is very natural in the context of OSPF. I do 
agree that the word *natural* can be twisted any way when taken 
without context, but I believe when Dr. Ogier claims *natural*, he 
thinks of scalability and a broadcast interface. Perhaps it is better 
to call MDRs a natural way to extend broadcast interface of OSPF.

Sincerely,

Aniket  

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

---

From: Richard Ogier <[email-masked]>
Date: Mon, 02 Oct 2006 16:37:08 -0700

Aniket,

You described very well what I mean by "natural extension".
You are right that it has a lot to do with scalability.
MDRs achieve scalability in an MANET in the same way that DRs
achieve scalability in an OSPF broadcast network.
It would be great if more people would take the time to understand
the MDR approach as well as you do.

Here is a related paragraph from the introduction of the MDR draft:

   OSPF-MDR was motivated by the desire to extend OSPF to support
   MANETs, while keeping the same design philosophy as OSPF and using
   techniques that are similar to those of OSPF.  For example, OSPF
   reduces overhead in a broadcast network by electing a Designated
   Router (DR) and Backup DR, and by having two neighboring routers form
   an adjacency only if one of them is the DR or Backup DR.  This idea
   can be generalized to a multihop wireless network by forming a
   spanning tree, with the edges of the tree being the adjacencies and
   the interior (non-leaf) nodes of the tree being the generalized DRs,
   called MANET Designated Routers (MDRs).

Richard

---

From: Russ White <[email-masked]>
Date: Mon, 02 Oct 2006 20:32:40 -0400

> interface for MANET type physical medium. It should be an acceptable

Let's not use the term "natural" at all. It's completely orthogonal to
the discussion.

> adjacency graph that is rooted towards its leaders (DR and BDR) which

I don't. There's no such thing as "leaders" in OSPF. There is such a
thing in Spanning Tree--perhaps you're mixing up ST and OSPF? Or you're
confusing the SPF tree, with it's root, with the concept of adjacencies?
DRs and BDRs are optimizations for broadcast links--OSPF would work just
fine without them. Do you know the history of p-nodes in IS-IS?

Hence, a "two hop extension" to OSPF's DR's isn't "natural" in any sense
of the term, and it's not necessarily, the best way to extend the protocol.

Again, let's get past the pejorative terms. Somehow, we've forgotten
history and context here. There's no such thing as a "natural"
extension, it doesn't matter how many times anyone repeats it on list.

:-)

Russ

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

---

From: Aniket Desai <[email-masked]>
Date: Mon, 02 Oct 2006 21:18:54 -0400

>of the term, and it's not necessarily, the best way to extend the protocol.

Hi Russ,

By leaders, I meant DR/BDR. And of course DR/BDR are leaders for 
broadcast interfaces, as they are responsible for forwarding LSAs. My 
usage of the term may be unorthodox, but it makes sense in the 
context that we are talking about.

Also having said that OSPF-MDR is a natural extension for broadcast 
interfaces, it is perfectly legit to correlate the optimizations in 
broadcast to the optimizations in OSPF-MDR. I am also not talking 
about SPF at all. All I said was that adjacencies are pointed towards 
the leaders (i.e. one end of the adjacency must be a leader) and 
leaders form a connected backbone. SPFs or STs are completely 
irrelevant and I have no idea how they entered in the discussion.

I *also* said in my response just before the one to which you 
responded that OSPF works fine without DR and BDR, and that the 
primary reason for introducing the MDR is to adding scalability. I 
believe that an agreement on basic functionality is already in place. 
I even went ahead and tried to correlate the OR/MPR interface to a 
point to multipoint interface type. Finally, I believe that we are 
primarily debating on scalability versus robustness.

I also do not know the history of p-nodes in IS-IS. Let me honestly 
declare that I don't know anything about IS-IS and I don't know what 
a p-node is. If I am missing any relevance or a connection between 
IS-IS p-node and OSPF-MANET, I apologize. Please let me know if that 
is the case.

Finally, I do not believe that the term *natural extension* is 
orthogonal to the discussion. OSPF-MDR implements a new interface 
type without changing the interface state machine. It has a one to 
one correlation with each interface state in broadcast. It has 
similar adjacency and flooding properties as broadcast (Dr. Ogier's 
slide is very educational). I honestly do not know what more *proof* 
does one need to infer that OSPF-MDR is indeed a natural extension of 
an OSPF broadcast interface. I do agree that the usage should be 
restricted to the term *natural extension of a broadcast interface* 
and not *natural extension of OSPF*. However in my opinion, the usage 
in the terms of the former phrase is not only justified but also 
essential when talking of OSPF-MDRs.

Sincerely,

Aniket

---

From: Richard Ogier <[email-masked]>
Date: Mon, 02 Oct 2006 18:30:24 -0700

Another important property of MDRs is that they are source independent,
like DRs but unlike MPRs.   If you want to generalize DRs to multihop
networks, it makes sense to make them source dependent.  The draft
draft-baker-manet-ospf-problem-statement-00
observed that DRs do not work properly in multihop networks, but
frankly did not succeed in generalizing them.  Instead, it was
decided to use MPRs, which are source dependent and therefore do
not generalize DRs.

More comments below.

Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>

OSPF would work just fine without DRs and BDRs?
OSPF would not be scalable without DRs and BDRs (assuming the network
includes broadcast links).  Just as DRs make OSPF scalable,
MDRs make OSPF-MDR scalable,

>of the term, and it's not necessarily, the best way to extend the protocol.

Now that we have explained what we mean by "natural extension", you will
know what we mean when we say it, even if you don't like the term.  :-)

Richard

P.S. I see that Aniket has also replied to your message, but I have
not yet read his reply.

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.2.2 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFFIa+oER27sUhU9OQRAtF5AJwP+LbvcwZJGRABFtEVcrIQnLoCtACghVLj
>S3B6yIjNPjvq9Dha1KF7tCY=
>=P0k+
>-----END PGP SIGNATURE-----
>