Reply to your request dated 29/07/2012 Draft Reviewed By: Abdussalam Baryun (AB) Dated:22/08/2012 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 --------------------------------------------------------------------------------------- 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. >