Subject: [OSPF] WG Last Call for draft-ietf-ospf-manet-mdr-02.txt

From: Abhay Roy <[email-masked]>
Date: Mon, 06 Oct 2008 09:21:17 -0700

We are starting WG Last Call of this revision of the subject draft.

This drafts is intended to be Experimental status. The OSPF WG last call
will begin today and will end at 12:00 AM EDT, October 20, 2008.

Abhay/Acee

-------- Original Message --------
Subject: I-D Action:draft-ietf-ospf-manet-mdr-02.txt
Date: Tue, 10 Jun 2008 21:45:03 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Open Shortest Path First IGP Working
Group of the IETF.

	Title           : MANET Extension of OSPF using CDS Flooding
	Author(s)       : R. Ogier, et al.
	Filename        : draft-ietf-ospf-manet-mdr-02.txt
	Pages           : 62
	Date            : 2008-06-10

This document specifies an extension of OSPF for IPv6 to support
mobile ad hoc networks (MANETs).  The extension, called OSPF-MDR, is
designed as a new OSPF interface type for MANETs.  OSPF-MDR is based
on the selection of a subset of MANET routers, consisting of MANET
Designated Routers (MDRs) and Backup MDRs.  The MDRs form a connected
dominating set (CDS), and the MDRs and Backup MDRs together form a
biconnected CDS for robustness.  This CDS is exploited in two ways.
First, to reduce flooding overhead, an optimized flooding procedure
is used in which only (Backup) MDRs flood new link state
advertisements (LSAs) back out the receiving interface; reliable
flooding is ensured by retransmitting LSAs along adjacencies.
Second, adjacencies are formed only between (Backup) MDRs and a
subset of their neighbors, allowing for much better scaling in dense
networks.  The CDS is constructed using 2-hop neighbor information
provided in a Hello protocol extension.  The Hello protocol is
further optimized by allowing differential Hellos that report only
changes in neighbor states.  Options are specified for originating
router-LSAs that provide full or partial topology information,
allowing overhead to be reduced by advertising less topology
information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mdr-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 20 Oct 2008 09:05:31 +0200

Hi,

here are some comments I had about draft-ietf-ospf-manet-mdr-02.

Section 1.1. (Terminology)

..."MDR Other
      A router is an MDR Other for a particular MANET interface if it is
      neither an MDR nor a Backup MDR for that interface."

# Comment 1. It is not clear enough whether this is per interface or
not. By transitivity, it is not clear enough if being MDR is by
interface or not. If it is, add a line such as "this is per interface".
If not add a line such as "this is per node", for this definition and
the definition of MDR.

..."Bidirectional Neighbor
      A neighboring router whose neighbor state is 2-Way or greater.
      The set of such neighbors is called the Bidirectional Neighbor Set
      (BNS)."

# Comment 2. same as above. It is no clear enough whether this is per
interface or not. If it is, add a line such as "this is per interface".
If not add a line such as "this is per node".

..."Non-flooding MDR
      An MDR that does not immediately flood received LSAs back out the
      receiving interface.  Some MDRs may declare themselves non-
      flooding in order to reduce flooding overhead.

# Comment 3. Suggestion: make this a positive definition that says what
a non-flooding MDR does (instead of saying what it does not do, which is
less precise). So say something like: "a non-flooding MDR is an MDR that
delays its flood".

..."Backup Parent
      If the option of biconnected adjacencies is chosen, then each MDR
      Other selects a Backup Parent..."

# Comment 4. Reading the document, it is not clear enough if the "option
of biconnected adjacencies" is identical with Adjconnectivity=2 or not.
If it is the same, then there should be just one denomination throughout
the draft. If it is not, then the draft should contain some text about
the difference between the two.

..."Backup MANET Designated Router (Backup MDR or BMDR)
      One of a set of routers responsible for providing backup flooding
      when neighboring MDRs fail."

# Comment 5. Are BMDRs useful if Adjconnectivity is not 2? Reading the
draft it is not obvious. It should be clearer in the specification what
is the tie between such options?

Section 2.2. (Flooding Procedure)

..."When an MDR receives a new LSA on a MANET interface, it immediately
   floods the LSA back out the receiving interface unless it can be
   determined that such flooding is unnecessary."

# Comment 6. In case of multiple MANET interfaces, this text may be
confusing. What about transmissions on other interface? My suggestion is
to add some text here about operation in such case. And some text should
also be added to precise if MDRs are per interface or not (ref Comment 1).

Section 2.5. (Partial and Full Topology LSAs)

# Comment 7. It seems that LSAFullness = 2 does not exist? In this case,
 it would be more coherent to just use LSAFullness=0,1,2,3 instead of
0,1,3,4.

# Comment 8. Reading the specification, it is not clear enough whether
heterogeneous LSAFullness is supported or not. What is the compatibility
of different routers using different LSAFullness in the same network?
For example if one router uses LSAFullness 0 and all the other routers
use LSAFullness 4, do we still get the properties of LSAFullness 4
(Shortest Paths etc.)? I guess not, so there should be some text
precising that all the routers must use the same LSAFullness and/or some
text that characterizes more precisely the properties resulting in
various LSAFullnesses present in the network.

# Comment 9. The text characterizing the properties of LSAFullness = 0
should include the mention that with this setting, actual path cost may
systematically differ from the computed path cost, which may cause
concerns if traffic engineering is of importance.

Section 3.2. (New Configurable Interface Parameters)

# Comment 10. Is heterogeneous Adjconnectivity is supported? What is the
compatibility of different routers using different Adjconnectivity? Some
text should clearly specify this.

# Comment 11. What is the compatibility of different Adjconnectivity
settings with repsect to different LSAFullness settings? Some text
should clearly specify this too.

Section 4.2.3. (Additional Processing for Both Hello Types)

   "If the router itself belongs to the neighbor's DNS"

# Comment 12. I assume this is a typo: change "DNS" into "BNS".

Section 5. (MDR Selection Algorithm)

# Comment 13. Some text should indicate that bi-connectivity of MDR and
BMDR is available only if the network is itself bi-connected.

Section 5.1. (Phase 1: Creating the Neighbor Connectivity Matrix)

# Comment 14. There should be a clear indication whether the
connectivity Matrix is ()i per interface or (ii) per node.

Section 5.4. (Phase 4: Selection of the (Backup) Parent)

# Comment 15. The step sequence in this section is not specified. There
should be a clear sequence of steps that is assured to provide no
contradictions between subsequent actions.

Section 6.1. (Interface States)

# Comment 16. Does every node in the network need to have the same
2HopRefresh? Or does it work also with various settings in the network?
This is not clear enough in the specification. There should be some text
about this.

Section 8. (Flooding Procedure)

# Comment 17. The introduction of the term "covered" neighbor should be
in terminology. Section 8 should just specify flooding procedure, and be
more concise, for clarity purposes. Recommendation: rewrite a more
consise specification.

Section 8.1 (LSA Forwarding Procedure)

..."(5) If the router is a flooding MDR for this interface,"

# Comment 18. This brings apparent contradictions with section 2.2. Is
MDR per interface? Per node? What happens in case of multiple MANET
interfaces? Some text should specify this in the draft.

# Comment 19. Transition between step 5 and step 6 is confusing. Step 5
floods the LSAs, and step 6 seems to "undo" some transmissions done in
step 5? Should step 5 come in fact after step 6?

# Comment 20. Covered optimization (used in steps 2, 4 and 6) is very
complex, and not straightforward to implement since it is much more than
"last-hop" dependent flooding: it is "multiple neighbor's last hop"
dependent flooding. Is this mechanism really necessary, since there is
already a CDS?

Section 8.1.1 (Note on Step 6 of LSA Forwarding Procedure)

# Comment 21. This should not be in the specification. Maybe this should
be in a "BCP" document instead?

Section B.2. (Detailed Algorithm for Step 3.2 (BMDR Selection))

# Comment 22. There is an optional algorithm for BMDR computation (b)
which seems to not be recommended. So why not remove it altogether?

Comment 23. General comment: the specification should be more
consistent with the denomination of the different options.

Comment 24. General comment: there many options.
- 4 levels of LSAFullness
- 3 levels of AdjConnectivity
- 2HopRefresh value (various differential Hellos)
- non-flooding MDR option
It would be very useful and clearer to have a table somewhere in
appendix that summarizes all the possible configurations of option
settings and which indicates which configurations are functional and
which are not.

Best regards,
Emmanuel

---

From: Richard Ogier <[email-masked]>
Date: Tue, 21 Oct 2008 07:52:34 -0800

Hi Emmanuel,

Thanks for your comments.  Please see my responses below.
I plan to submit an updated draft soon.

 >If not add a line such as "this is per node", for this definition and

I think the phrase "for a particular MANET interface" implies that
it is per interface.  However, I will also clarify this for the
definition of an MDR.  Also, note that MDR Level and Parent are
interface variables.  This is similar to OSPF, which selects a DR
for each broadcast interface.

 >If not add a line such as "this is per node".

I will clarify that the BNS is defined for each interface.

 >less precise). So say something like: "a non-flooding MDR is an MDR that

OK, I can add that a non-flooding MDR performs backup flooding
like a BMDR (as specified in later sections).

 >the difference between the two.

AdjConnectivity is a parameter, and "biconnected adjacencies" describes
what it means for AdjConnectivity to equal 2.
The equivalence of these two is indicated in Section 3.2 where
AdjConnectivity is defined.
In graph theory, a graph is "biconnected" if its connectivity is 2,
so this is the same thing.

 >is the tie between such options?

This is made clear in the last two sentences of page 23:

  "Also, Phase 3 (BMDR selection) is not required if AdjConnectivity is
  0 or 1.  However, Phase 3 MUST be executed if AdjConnectivity is 2,
  and SHOULD be executed if AdjConnectivity is 0 or 1, since BMDRs
  improve robustness by providing backup flooding."

 >also be added to precise if MDRs are per interface or not (ref Comment 1).

Section 2.2 just gives a brief, informal overview of the operation.
The detailed operation for flooding is given in Section 8, including
the case of multiple interfaces.

 > it would be more coherent to just use LSAFullness=0,1,2,3 instead of

LSAFullness = 2 does exist, but its exact implementation is left to
the implementer.  It is defined by the last paragraph on page 41, by
requiring the set of advertised neighbors to be a superset
of the set corresponding to LSAFullness = 1.
The idea is to allow the router to advertise additional neighbors
to provide redundant routes.
Note that an exact algorithm need not be specified, since it is
not necessary for different routers to use the same algorithm,
as noted in the last paragraph of Section 9.3.

 >various LSAFullnesses present in the network.

The fact that different routers can use different values of the new
interface parameters (including LSAFullness and AdjConnectivity) is
made clear in the following paragraph of Section 3.2:

  "Although all routers should preferably choose the same values for the
  new configurable interface parameters, this is not required.  OSPF-
  MDR was carefully designed so that correct interoperation is achieved
  even if each router sets these parameters independently of the other
  routers."

It is stated that LSAFullness = 1 or 4 provides shortest paths,
and that LSAFullness = 0 does not.  As you concluded, shortest paths
are not guaranteed even if only one router uses LSAFullness = 0.
To clarify this, I will add the following: Routing along shortest paths
is provided if and only if LSAFullness is 1, 2, or 4 for every router.

 >concerns if traffic engineering is of importance.

Actual path cost can only be better than the computed path cost,
since each router may have knowledge of first-hop links that
are not advertised in router-LSAs.  I don't think this will cause
any problem.  However, I will mention this fact in the document
since it may be useful to know this.

 >should clearly specify this too.

As I mentioned above, the fact that different routers can use different
values of the new interface parameters (including LSAFullness and
AdjConnectivity) is made clear in the paragraph from Section 3.2
that I quoted above.  This is an attractive feature of OSPF-MDR
as has been discussed on the list (e.g., see the post of
Matthew Thomas on 12/7/2007).

 ># Comment 12. I assume this is a typo: change "DNS" into "BNS".

"DNS" (Dependent Neighbor Set) is correct.

 >BMDR is available only if the network is itself bi-connected.

OK, I will mention that the MDR/BMDR backbone will be biconnected
only if the network is biconnected.  (This does not affect the
algorithm.)

 >connectivity Matrix is ()i per interface or (ii) per node.

OK, I will mention that the matrix is calculated for the given
interface, even though the beginning of Section 5 states that the
entire MDR selection algorithm is applied per interface.

 >contradictions between subsequent actions.

The only required ordering is that the last paragraph (in which
an MDR Other selects its Backup Parent) must be done last (after
the Parent is selected), so I will add text to indicate this.

 >This is not clear enough in the specification. There should be some text

As I mentioned above, the fact that different routers can use different
values of the new interface parameters (including 2HopRefresh) is made
clear in the paragraph from Section 3.2 that I quoted above.
In particular, some routers can use diff Hellos while others
use only full Hellos (corresponding to 2HopRefresh = 1).

 >more concise, for clarity purposes. Recommendation: rewrite a more

The term "covered" is used only in Section 8 (except for one informal
use that I will remove) and has a detailed definition that would
not be appreciated in the terminology section.  The idea is to define
it just before using it, for convenience.  I don't want to burden
the reader with this detailed definition until it is required in
Section 8.

As for writing a more concise specification, I don't see how that
is possible.  Note that, for MANET interfaces, steps 1-7 replace
steps 1-5 in Section 13.3 of RFC 2328 (which are still valid for
non-MANET interfaces).  I want to keep the parallelism.
In both cases, these steps support multiple interfaces.

 >interfaces? Some text should specify this in the draft.

As I mentioned, MDRs are selected per interface.
Steps 1 through 7 are applied to each MANET interface,
similar to Section 13.3 of RFC 2328, and I will add text
to make this clear.

 >step 5? Should step 5 come in fact after step 6?

If Step 5 results in the LSA being flooded out the interface, then
there is no need to execute Steps 6 and 7.  I will add text to
make this clear.

 >dependent flooding. Is this mechanism really necessary, since there is

This was discussed long ago on the ospf-manet list.
There are two main points to make.

First, the flooding procedure in RFC 2328 already requires
examining each neighbor when a new LSA is received (Step 1 of
Section 13.3), so we are not adding any complexity.

Second, it is possible to precompute the set of neighbors that
cover all other neighbors, and use this information to simplify
steps 2 and 6a (which do not involve BMDRs) by ignoring Acks.
For example, step 2 would be replaced with the following:

(2) If the received new LSA covers all bidirectional neighbors
    on the interface, examine the next interface.

(This simplification does not apply to BMDRs, but BMDRs are
optional anyway.)

Instead of explicitly stating the above simplification, I will
allow it simply by allowing the option of ignoring Acks in Step 2.  
(I previously thought about doing this anyway.)

 >be in a "BCP" document instead?

This is just an example illustrating the benefit of Step 6 of the
LSA forwarding procedure.  It helps people to understand why
Step 6 is included.

 >which seems to not be recommended. So why not remove it altogether?

What the draft says is that the simplified algorithm, which
omits step b, is not recommended if AdjConnectivity = 2.
Thus, step b is certainly recommended if AdjConnectivity = 2.
Here is the paragraph that follows the algorithm:

  "A simplified version of the algorithm MAY be performed by omitting
  step (b).  However, the simplified algorithm will result in more
  BMDRs, and is not recommended if AdjConnectivity = 2 since it will
  result in more adjacencies."

 >settings and which indicates which configurations are functional and

All configurations of option settings are functional and interoperable,
except that minimal LSAs (LSAFullness = 0) cannot be used
with full-topology adjacencies (AdjConnectivity = 0).
Although this is implied in the third paragraph of Section 9.3,
I will make it clearer, and also state it in Section 3.2
(New Configurable Interface Parameters).

I will also add your name to the Acknowledgments section.

Richard

---

From: Abhay Roy <[email-masked]>
Date: Tue, 21 Oct 2008 08:38:09 -0700

Last call completed without any significant issues.

Richard will publish a new version with some additional clarifications 
based on comments received so far.

Regards,
-Abhay