Subject: Re: Last Call: <draft-ietf-manet-olsrv2-15.txt> (The Optimized Link State Routing Protocol version 2) to Proposed Standard

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 22 Aug 2012 15:17:43 +0200

Reply to your request dated 29/08/2012

Draft Reviewed By: Abdussalam Baryun (AB)    Dated:22/08/2012

Reviewer Comment  AB2:  Related to OLSRv2 Packets.
++++++++++++++++++++++++++++++++++++++++

-The reviewer is not sure how/when the OLSRv2 generates packets
[RFC5444] or how it puts information in the packet. The I-D refers
back to the RFC5444 document but the document is a general
specification for all MANET routers, the reviewer thinks it is
important that OLSRv2-draft mentions what/how the OLSRv2 node puts
information in RFC5444 header or how a node uses the header
information.

-In OLSRv2-draft section 13.2 > This specification does not define or
use any contents of the Packet Header.
The reviewer does not know why the router generates the packet and
does not use, or the reviewer does not know who generates it.

-RFC5444 specifies that IANA is registering namespaces for: Message
Types, Packet TLV Types, Message TLV Types, and Address Block TLV
Types.
OLSRv2-draft IANA consideration section does not mention any assign
for packet header related to OLSRv2 as in RFC5444 section 6.3 (e.g.
Packet TLV Types).

Regards
AB
---------------------------------------------------------------------------------------
This message and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
This message is in compliance with the IETF regulations.
---------------------------------------------------------------------------------------

On 7/29/12, The IESG <[email-masked]> wrote:
>
> The IESG has received a request from the Mobile Ad-hoc Networks WG
> (manet) to consider the following document:
> - 'The Optimized Link State Routing Protocol version 2'
>   <draft-ietf-manet-olsrv2-15.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2012-08-22. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting. This last call
> period has been extended to handle the fact that it spans the IETF-84
> meeting.
>
> This last call is being re-initiated to include a notice that this document
> includes a normative down reference to an Informational RFC:
> RFC5148, "Jitter considerations in MANETs".
>
> Abstract
>
>    This specification describes version 2 of the Optimized Link State
>    Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 22 Aug 2012 22:24:11 +0200

Reply to your request dated 29/07/2012

Draft Reviewed By: Abdussalam Baryun (AB)                       Dated:
22/08/2012

Reviewer Comment  AB1: Terminology and Definition Related
++++++++++++++++++++++++++++++++++++
In [1] the olsrv2-interface runs the NHDP, and some terms in [1] are
defined as in [2]:

Interface:
A router’s attachment to a communications medium. An interface is
assigned one or more addresses.

MANET interface:
An interface participating in a MANET and using this neighborhood
discovery protocol. A router may have several MANET interfaces.

Link:
A link between two MANET interfaces exists if either can be heard by the other.

These above terms’ definitions are different than in [4, 5, and 6].
The reviewer may understand links are logical or/and physical as
defined in [3].
Why definitions are not in consistent with other RFCs?

References
++++++++++
1- Clausen, T., Dearlove, C., Jacquet, P., Herberg, U., “The Optimized
Link State Routing Protocol version 2”, work in progress, IETF, May
2012.
2-Clausen, T., Dearlove, C., Dean, J., “Mobile Ad Hoc Network (MANET)
Neighborhood Discovery Protocol (NHDP)”, RFC6130, IETF, April 2011.
3-  Melia, T., Gundavelli, S., “Logical Interface Support for
multi-mode IP Hosts”, work in progress, IETF, April, 2012.
4- Manner, J., and Kojo, M., “Mobility Related Terminology”, RFC3753,
IETF, June 2004.
5- Narten, T., Nordmark, E., Simpson, W., Soliman, H., “Neighbor
Discovery for IP version 6 (IPv6)”, RFC4861, IETF, Sep. 2007.
6- Blanchet, M., Seite, P., “Multiple Interfaces and Provisioning
Domains Problem Statement”, RFC6418, IETF, Nov. 2011.
7- Corson, S., Macker, J., “Mobile Ad hoc Networking (MANET): Routing
Protocol Performance Issues and Evaluation Considerations”, RFC2501,
IETF, Jan. 1999.
===================================================

Thanks
AB

+++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 22 Aug 2012 22:35:05 +0200

Reviewer Comment AB3:  Related to OLSRv2 Metric
++++++++++++++++++++++++++++++++++++++

OLSRv2-draft> Note that the generation of (incoming) link metric
values is to be undertaken by a process outside this specification;
this
specification concerns only the distribution and use of those
metrics.

Comments> The OLSRv2 uses dimensionless additive metric types. The
OLSRv2 link metric is unidirectional (in document mentions
directional).

Question> The OLSRv2 specification uses dimensionless metric types,
which all nodes MUST support it. Does this mean that OLSRv2 doesn’t
support dimensional metric types?

-The Metric distribution and use:

Section 4.5> Each HELLO or TC message carrying link (or neighbor) metrics
thus indicates which link metric information it is carrying, allowing
routers to determine if they can interoperate. If link metrics
require additional signaling to determine their values, whether in
HELLO messages or otherwise, then this is permitted but is outside
the scope of this specification.

Question> Where is metric defined in TC and hello messages between
neighbors or is it in the MPR message extension between MPRs. Does the
OLSRv2 router allow the both options or more others?

5.4.2> All routes found using this specification use a single link metric
type that is specified by the router parameter LINK_METRIC_TYPE,
which may take any value from 0 to 255, both inclusive.

Comment> links are between MANET interfaces and each router may have
more than one interface, so how can we have only one link metric per
router. IMO, recommended single link metric per interface. However, in
the introduction of section 5 it mentions that routers’ parameters may
not be the same in MANET (does it contradict the single metric-type
parameter?).

-IANA Consideration for OLSRv2 Metric:

Comment> Metric assigned in IANA (table 13) but recommended to be
defined as [additive dimensionless link metric]. In future use of
OLSRv2 there may be non-additive metric types, and dimensional types.

Regards
AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 22 Aug 2012 22:59:42 +0200

Reply to your request dated 29/07/2012
Draft Reviewed By: Abdussalam Baryun (AB)   Dated: 22/08/2012

Reviewer Comment AB4: Related to OLSRv2 Messages.
++++++++++++++++++++++++++++++++++++++++

Section 13.2.> Messages with different originating routers MAY be
combined for transmission within the same packet. Messages from other
protocols defined using [RFC5444], including but not limited to
[RFC6130], MAY be combined for transmission within the same packet.
This specification does not define or use any contents of the Packet
Header.

Comment> the document describes the receive and processing of OLSRv2
messages, but not sure why not about processing of OLSRv2 packets.

Question> in case of messages from other protocols, how the OLSRv2
router receives and processes the packet and/or different routing
messages?

Question> is there possibility that OLSRv2 receives control messages
[RFC5444] which are not packed in RFC5444 packet, or is that not
allowed by the specification?

Regards
AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 22 Aug 2012 23:03:34 +0200

Reviewer Comment AB5:  Related to OLSRv2 update to IP Routing Table.
+++++++++++++++++++++++++++++++++++++++++++++++++++++

Section 4.6> It is intended that the Routing Set can be used for IP packet
routing, by using its contents to update the IP routing table. That
update, and whether any Routing Tuples are not used in the IP routing
table, is outside the scope of this specification.

Question> Why it is out of scope? For OLSRv2 router the *routing
table* update should be in-scope.

Regards
AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 22 Aug 2012 23:40:46 +0200

Reviewer Comment AB6: Related to OLSRv2 Interfaces.
++++++++++++++++++++++++++++++++++++

-Is NHDP a must for OLSRv2 routing?

Comment> The relationship between RFC6130 and the [OLSRv2] was not
clear to reviewer (does OLSRv2 depend on NHDP or it may work without
it), is it only that Hello messages are defined in RFC6130 and router
interfaces. Reviewer may understood that the draft-OLSRv2 may extend
to define Hello messages by routers for its non-MANET interfaces.

Question> is there a use case where OLSRv2 may work better without NHDP?

Section 5.> As for the parameters in [RFC6130], parameters defined in this
specification MAY be changed dynamically by a router, and need not be
the same on different routers, even in the same MANET, or, for
interface parameters, on different interfaces of the same router.

Question> but if routers may change parameters individually, what is
the consistency between routers, and how they cooperate?
Comment> it is recommended to clarify some limits and use case to this
issue for stability purposes.

Section 5.1> TC messages and HELLO messages [RFC6130] MUST, in a given
MANET, both be using the same of either of IP or UDP, in order that it
is possible to combine messages of both protocols into the same
[RFC5444] packet for transmission.

Comment> the words "both protocols" are they refering to IP and UDP or
they refer to OLSRv2 and NHDP. It should be clarified even though the
intention is NHDP/OLSRv2 (my add *port* to UDP, or replace *protocols*
with both names)

Question> if there was two different Hellow messages in terms of
information, one of OLSRv2 type and the other NHDP type, what will the
OLSRv2 router take as valid neighbor information?

-OLSRv2 Interfaces' Addresses:

Section 10.5.> R_local_iface_addr is an address of the local interface
over which
an IP packet MUST be sent to reach the destination by the selected
path.

Section 4.6> The purpose of the Routing Set is to determine and record routes
(local interface network address and next hop interface network
address) to all possible routable addresses advertised by this
protocol, as well as of all destinations that are local, i.e., within
one hop, to the router (whether using routable addresses or not).
Only symmetric links are used in such routes.

Question> From above two sections, are the local interface addresses
routable or maybe routable. Are some local interfaces not network
addresses? Are all next hop interface addresses routable.

Regards
AB