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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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
---------------------------------------------------------------------------------------
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 <iesg-secretary@xxxxxxxx> 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
> ietf@xxxxxxxx mailing lists by 2012-08-22. Exceptionally, comments may be
> sent to iesg@xxxxxxxx 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.
>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]