Subject: [OSPF] Questions regarding draft-ietf-ospf-manet-or-00.txt

From: Richard Ogier <[email-masked]>
Date: Sat, 14 Jun 2008 06:55:26 -0800

Abhay,

I have two questions regarding draft-ietf-ospf-manet-or-00.txt.

First, the Intended Status is given as "Standards Track".  Is this a
mistake?  I thought all three OSPF-MANET drafts were supposed to be
Experimental.

Second, I noticed that the concept of "Unsynchronized Adjacencies",
along with the "Unsynchronized SPT" and the "Unsynchronized" bit (U-bit)
are not included in the draft, even though they were included in
http://tools.ietf.org/html/draft-roy-ospf-smart-peering-01

I thought this concept was needed in order to distinguish between
synchronized links and unsynchronized links in Router-LSAs, to avoid
a circular dependency problem.
Is this also a mistake, or is there a reason for this omission?

Richard
_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Abhay Roy <[email-masked]>
Date: Sun, 15 Jun 2008 22:59:06 -0700

Hi Richard,

Thanks for the review. Please see inline for comments.

> mistake?  I thought all three OSPF-MANET drafts were supposed to be

I will change this to Experimental.

> Is this also a mistake, or is there a reason for this omission?

You are right. The draft is currently synced to smart-peering-00 
version. When I get it ready for LC, I plan to update it to -01 version.

Regards,
-Abhay

---

From: Richard Ogier <[email-masked]>
Date: Wed, 18 Jun 2008 08:33:27 -0800

Abhay,

I have a few more questions regarding the OSPF-OR draft.
The first bullet of Section 3.3.3 (Terminology) states:
"Note that all neighbor references in this document are
assumed to be FULL neighbors."

Is this really true?  If so, then it would imply that all overlapping
relays (ORs), including non-active ORs, must be Full neighbors.
In particular, an adjacent neighbor in state Exchange cannot be a
non-active OR (even though OSPF performs flooding along all
adjacencies, not just Full adjacencies).

Section 3.3.8 (Flooding and Relay Decisions) states:
"Upon receiving an LSA from an adjacent speaker, a node makes
flooding decisions based on the following algorithm."

The above is consistent with OSPF flooding.  However, if only Full
neighbors can be ORs, then a received LSA will never be relayed
unless the LSA was received from a Full neighbor, which does
not seem right.

The GTNETS code for OSPF-OR developed by Boeing, and used for their
Milcom'06 paper, actually allows an received LSA to be relayed even
if it was received from a non-adjacent neighbor.  This implicitly
allows any bidirectional neighbor to be a non-active OR.

So there are three possibilities for (non-active) ORs:
1. An OR must be a bidirectional neighbor.
2. An OR must be an adjacent neighbor (state Exchange or above).
3. An OR must be a Full neighbor.

When smart peering is used (for adjacency reduction), the first
choice might have the drawback that there are too many non-active
(backup) ORs, which can affect scalability (as shown in simulations
of large networks).  Choice 2 would limit ORs to the reduced
adjacency graph, which would result in far fewer non-active ORs.
Although the current spec implies that choice 3 is used, as I
mentioned above this does not seem like the best choice.

If the answer is either 1 or 2, then the draft should be modified to
change the definition of an OR.  For example, if the answer is 2,
then the definition can be changed to:

"An adjacent neighbor is considered an overlapping relay for a
speaker if it has an adjacent neighbor that is not an adjacent
neighbor of the speaker itself."

Richard
www.manet-routing.org

---

From: Richard Ogier <[email-masked]>
Date: Wed, 18 Jun 2008 16:40:09 -0800

Abhay,

I have a few more comments that are mostly editorial.
First, I would like to correct my suggested definition of an
overlapping relay to the following:
 
"An adjacent neighbor is considered an overlapping relay for a
speaker if it has an adjacent neighbor that is not equal to
the speaker itself."

Another possible definition of an overlapping relay (which I think
is used in Boeing's GTNETS code) is:
"A bidirectional neighbor is considered an overlapping relay for a
speaker if it has an adjacent neighbor that is not equal to the
speaker itself."

The existing definition of overlapping relay from Section 3.3.2 is:
"A neighbor is considered an overlapping relay for a speaker if it can
reach a node in the two-hop neighborhood of the neighbor, i.e., if it
has one-hop neighbors."

I think "neighborhood of the neighbor" should be
"neighborhood of the speaker".

Note that the definition of "two-hop neighborhood", i.e., "those
nodes that are neighbors of the speaker's one-hop neighbors", implies
that the speaker can be in its own two-hop neighborhood, which is
why I excluded "the speaker itself" in my suggested definitions.
(However, this probably will not affect flooding operation.)

In Section 3.3.3 (Terminology), the 5th bullet is:

   o  N2: A subset of 2-hop FULL neighbors excluding the nodes only
      reachable by members of N.

I think N2 is the subset of 2-hop FULL neighbors excluding the
1-hop neighbors, i.e., excluding members of N.
However, the 2nd bullet already defines the 2-hop FULL neighbors
to exclude the 1-hop neighbors:

   o  2-hop FULL neighbors: The list of 2-hop neighbors of the node that
      are FULL and that can be reached from direct neighbors, excluding
      any directly connected neighbors.

Richard

---

From: Richard Ogier <[email-masked]>
Date: Thu, 19 Jun 2008 08:02:07 -0800

I thought of a better way to fix the problems that I mentioned.
First, the convention that "neighbor" always means "Full neighbor"
should be avoided (since it does not allow the draft to refer to
neighbors that are not Full).

Second, since every router that is not an active OR can be
considered to be to be a non-active OR, I suggest not even
defining "active" and "non-active", but just call an "active OR"
an MPR (which is what it really is!).  (Or use "OR" to mean "MPR".)
The behavior of routers that are not MPRs can be specified in the
flooding procedure, as I suggest below.

Since Boeing's implementation allows LSAs received from non-adjacent
neighbors to be processed and flooded, in Section 3.3.8
(Flooding and Relay Decisions), specify that an LSA received from
any bidirectional neighbor can be processed and flooded, e.g.,

"Upon receiving an LSA from a bidirectional neighbor, a node makes
flooding decisions based on the following algorithm."

In step 1, change "active overlapping relay" to MPR.
In step 2, change "If the node is a non-active overlapping
relay for the adjacent speaker" to
"If the node has at least one adjacent neighbor from which
the LSA, or an ack for the LSA, has not been received".

Step 2.1 strikes me as being vague, since it is not clear how to
determine that "flooding the LSA will only result in a redundant
transmission".  I suggest modifying this step as follows:

2.1. Upon expiration of PushbackInterval plus jitter, if there exists
at least one adjacent neighbor from which the LSA, or an ack for
the LSA, has not been received, the router MUST transmit the LSA
at this time.

The above is just a suggestion. I am not 100% sure it is correct.

Richard