Skip to main content

Last Call Review of draft-ietf-manet-olsrv2-multitopology-05
review-ietf-manet-olsrv2-multitopology-05-opsdir-lc-hares-2015-05-28-00

Request Review of draft-ietf-manet-olsrv2-multitopology
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-05-26
Requested 2015-05-08
Authors Christopher Dearlove , Thomas H. Clausen
I-D last updated 2015-05-28
Completed reviews Secdir Last Call review of -05 by Phillip Hallam-Baker (diff)
Opsdir Last Call review of -05 by Susan Hares (diff)
Assignment Reviewer Susan Hares
State Completed
Request Last Call review on draft-ietf-manet-olsrv2-multitopology by Ops Directorate Assigned
Reviewed revision 05 (document currently at 07)
Result Not ready
Completed 2015-05-28
review-ietf-manet-olsrv2-multitopology-05-opsdir-lc-hares-2015-05-28-00

Thomas and Chris:



I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These

comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments  just like any other last call comments.



Status of the draft: Not ready (publication wise), Almost ready (technical
basis)



Overall comment:

 First of all, as a long-term supporter of the OLSR work I am very happy to see
 this experimental draft that seeks to provide clear proof points of the
 MT-OLSR-v2 work.  I believe the MT-OLSR-v2 can provide substantial benefit in
 the industry.   My comments should be taken as a way to help the experiment
 provide real data points to IETF and to the industry on the successful.  Real
 data will help the long term debate over the ADOV-v2 and OLSR-v2 work.  Almost
 10 years ago Don Fedyk show me some very limited theoretical analysis on where
 early version of these protocol fit within 802.11s work.  Experimental work is
 critical to expansion of this work as new 802.11 and new mobile radios
 continue to make MANET’s work relevant for future networks.



Summary of Comments:

My comments have 6 major issues, and a set of editorial changes.  Five of my
major points have to do with adding more details to the draft to judge the
experiment valuable.  One way to resolve these comments is to create document
providing details on the test that will be run.  A second way to resolve these
comments on experiment is to provide additional high-level guidance in this
document.



The 6th major technical point is that you have not done the IANA Section to
match previous RFCs (7181, 7188).  I believe Barry Lieba and IANA have already
noted this issue as well.   The format of the IANA section should be changed to
include all the IANA registration issues.



I have other editorial comments but since I have indicated a substantial
section re-write due to major comments, I will be glad to review the document
for final editorial comments in a second pass.



Technical summary:

 Basically – it is a good extension of existing work.  It is useful for
 Wireless and MANET for mobile. The authors did a good job of focusing on just
 the revisions.  However, I am recommending more detail on the experiments will
 help the protocol and help to create knobs for configuration and management of
 the protocol.



Here are the main points of the review:



Status:

 Almost ready, but has 5 major points that will help define the experiment as a
 success.

1 Major point about the IANA Section.



Major 1 issues are the exact definition of the tests that make it a successful
experiment.

   (p. 7, section 4, section 5, parameters

This draft needs to have the clarity of setting expectations for if the
experiments succeeds.  The recommended tests in major concern 1-4 could be
created in a separate draft.   If so, this draft should reference that draft.



A few things that should be in the tests are:



1)



Topologies that prove the OLSR-v2 and MT-OLSR “doesn’t break” either protocol.
 As previous tests of link-state protocols have shown, it is the topologies and
the changes between the topologies that cause failures.  Changes to topologies
include migrating between topologies due to link failures or link flapping.  In
the OLSR-v2 and MT-OLSR world this is extremely important as mobile nodes may
have radios or Wifi that fades in and out.



2)



Scaling tests – what happens if the arrays round out of space?  Does the route
calculation for each metric type cause problems?

Are there efficiencies that some implementations use to improve scaling?



3)



Interoperability tests with the previous versions OSLR-v2 (can you crash an
older OLSR-V2 version)?  These tests should be not just two boxes but
topologies of nodes connected by Wifi (802.11n, 802.11ac, 802.11k (if ready))
and other mobile radios (software defined radios, military, and others).



4)



Failure tests/Error conditions (section 5) – E.g. what happens parameter arrays
have repetitions in the

IFACE_METRIC_TYPES. What happens if the ordering of the LINK_METRIC_TYPE.metric

type does not include the

ROUTER_METRIC_TYPE First?



Other tests should be described.  All these tests should have topologies,
parameters, and results.  OSLR-2 tests should pick up the theory from the
benchmarking WG for testing OSPF and ISIS depends on the types of topologies
that are given.  For other authors, I would give more precise details. 
However, due to the expertise of the two authors – I gave just this high level
guidance.  I will be glad to work through scenarios with the authors.



Major 2: Should the be a negotiation of resources sizing or just an overload
bit flag when it fails?



We know that overload bits have problems.  So, does this experiment try to fix
this in the MT-OLSR2?  If not, as it goes to from scalar to arrays – how will
peers know when it fails in one MT-Topology versus another?  Is this experiment
restricted to fate-sharing among the MT-OLSR-v2 topologies due to resources on
a single?  Should the negotiation of the types in the Hello have a resource
constraint in the MPR-WILLING TLV?  This negotiation for MT-OLSRv2 is different
than the simple upgrade from OLSR to OLSRv2.  It is important to know how the
overload works in MT-OLSR-v2 only, and combined MT-OLSRv2 and OLSR-v2.  This
overload should be tested in a variety of topologies with parameters,
topologies, and routing flow carefully detailed. Again, see the benchmarking
drafts on OSPF and ISIS.



Again, what I pose is questions that I feel the authors should consider in an
experiment for this type of work.  These expert authors have the capability to
place additional high-level in this document (or more detail in a different
document).  Again, I will gladly provide the authors with feedback and review



Major 3:  It is not clear that the experiment is consider whether the MPR
calculation per TE-metric will consume significant resources.

A good benchmarking (see Major 1) would be useful.  The theoretical assurance
that:



“

Each router may make its own decision as to whether or not to use a

link metric, or link metrics, for flooding MPR calculation, and if so

which and how. This decision MUST be made in a manner that ensures

that flooded messages will reach the same symmetric 2-hop neighbors

as would be the case for a router not supporting MT-OLSRv2 (section 10,
paragraph)



Is not really strongly there. If this is experimental, it is important to test
this point in the benchmarking.  I do not really see it in the experiment.
 This applies to the 1-hop neighbors (both those not considered (symmetric
links)) and those considered in the 2-hop consideration.



The experiment should again set benchmarks for success on the MPR calculation
for MT-OLSR-v2, and combined MT-OLSR-v2 and OLSR-v2 which contain several
topologies, careful parameter setting, and methods to record convergence time.



Major comment 4:  The link between NHDP and this standard’s experiment with MPR
is not clear.



I expected some comment on how NHDP interacts with the MPR Tests above.  This
may simply be a revision of the text for the use case for MPR calculation.  I
expected some comment because  RFC 7466 states in its abstract:

   Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop

   neighbors if the measured link quality from that 1-hop neighbor is

   below an acceptable threshold while still retaining the corresponding

   link information as acquired from the HELLO message exchange.  This

   allows immediate reinstatement of the 1-hop neighbor if the link

   quality later improves sufficiently.



   NHDP also collects information about symmetric 2-hop neighbors.

   However, it specifies that if a link from a symmetric 1-hop neighbor

   ceases being symmetric, including while "ignored" (as described

   above), then corresponding symmetric 2-hop neighbors are removed.

   This may lead to symmetric 2-hop neighborhood information being

   permanently removed (until further HELLO message

received) if

   the link quality of a symmetric 1-hop neighbor drops below the

   acceptable threshold, even if only for a moment.



Major concern 5:  Experiments should drive to create operational guidelines for
deployment, configuration knobs, and use cases (ADOV-2, OLSR-v2, MT-OLSR-v2)



While all these major issues are not directly operations, early experiments
will help the operations people to set the management variables in section 10:

1)



Reasonable TE metrics,

2)



Detecting that MANET is sufficiently connected,

3)



Providing guidance to deployments on performance of route sets for diff-serv in
different environments (Wifi and other mobile radio nodes),

4)



Determine how the mixture of OLSR-v2 and MT-OLSR-v2 work in different
environments.

5)



Determine how to design for OLSR-v2 and MT-OLSR-v2 networks for better MPR
assignment with NHDP



Major 6: The IANA section does not answer all the IANA questions.



It has most of the information, but I think it is not up to the latest IANA
format and information.   Barry Leiba and others have noted that the RFC 7181
and RFC7188 do not match this IANA section.  Rather than repeat these comments,
I will simple state the data needs to be consistent and the format match IANA’s
comments.



Please let me know if I can help with any additional review of comments on this
exciting work.



Sue