The Optimized Link State Routing Protocol Version 2
draft-ietf-manet-olsrv2-19

[Ballot discuss]

I'm going to clear this discuss as soon as my co-AD
has had a chance to check he's ok with the argument
that BCP107 doesn't apply here.

[Ballot comment]

draft-ietf-manet-olsrv2-18
Just reviewing section 23 and associated docs; these
are non-blocking comments

- 23.1, 2nd para: "digital signature" is maybe a
bad example since you're doing MACing (same
comment about other places you say "digital
signature" since a MAC is not one of those)

- 23.2, maybe s/recommended/RECOMMENDED/ if you
mean it in 2119 terms or s/recommended/highly
useful/ if you don't

- 23.2, saying a timestamp is "required" is maybe
not quite accurate as other anti-replay mechanisms
could be used in principle, maybe you mean a
timestamp is a useful mechanism for that if you
have sufficiently synchronised clocks

- 23.2, this text might be confusing "In general,
digital signatures and other required security
information may be transmitted within the HELLO
and TC messages, or within a packet header, using
the TLV mechanism.  Either option permits
"secured" and "unsecured" routers to coexist in
the same network, if desired." The confusion might
arise due to the use of "may" (vs 2119 MAY) and
where you elsewhere (in
draft-herberg-manet-nhdp-olsrv2-sec) say that a
bad or missing ICV means DROP.

- 23.2, I think that 6622bis really ought be a
normative reference for this. It is already via
transitive inclusion as a normative ref to
draft-herberg-manet-nhdp-olsrv2-sec, so won't be
any more blocking that it already is.

- 23.2, ICVs are, in general, not signatures.

- 23.2, are we still saying that its ok to not
reject a message with a bad ICV? I think you ought
say that such messages must be rejected.  (Where
you currently say "can be used as a reason to
reject")

- 23.2, last para of p85, "must specify how to" is
that a 2119 MUST? seems like it might be. And
you're a bit ambiguous on rejection - it says
"must specify how to... and to reject.." does that
mean you MUST reject messages with bad ICVs or
that you MUST specify how to reject messages with
bad ICVs? (Where bad includes unverifiable.)

- 23.2 same para typo s/their purpose/the purpose/

- 23.5 "and a single shared secret key" seems
wrong, it'd work fine if all nodes had the same N
shared secrets, I think you want to say "and
manually managed shared secrets"

- 23.5 last para, the SHOULDs there are a bit odd
in 2119 terms, I'd say for the first one you want
to say "[OLSRv2-integrity] SHOULD be used" and for
the second one just say that mechanisms with
re-keying would be needed but are not yet
specified.

- 23.6 1st para, "lend themselves" isn't right,
you want to be saying what's needed and what's
not.

- 23.6 "uses only one key" is wrong again, you
just need to say "uses only a small set of
manually managed shared secrets"

- 23.6 multicast argument, I think if you could
argue that multicast key management doesn't match
the baseline use-cases this would be better. I
don't know if that's the case or not.

- 23.6 "not kerberos" argument - this is nothing
to do with bandwidth (kerberos doesn't use much at
all) but about availability of a KDC.

-------------
draft-herberg-manet-nhdp-olsrv2-sec-02 (this is
not a full review, just a quick check that it
seems ok with the olsrv2 draft above, I'll do a
full review when it comes back to the IESG.)

- abstract, "single shared secret" is wrong since
you can handle >1 (same comment elsewhere) That'll
be a DISCUSS when this comes back if you don't
want to fix it. (But I think that 6622 does
support key ids so this is a trivial fix.)

- the diagram on p4 implies that a bad or
unverifiable ICV means that packet/message is
dropped (just to contrast with the above comment
where you said you can mix and match unsecure and
secure in the same n/w)

- "MUST use different algorithms" seems too
restrictive, don't you want to say MUST use a
different alg or key id?

-------------
draft-herberg-manet-rfc6622-bis

I didn't check this one, but the diff with 6622
looks ok on first glance.

[Ballot discuss]

(Just updated to note -17 doesn't address the discuss yet)

Why are "guidelines" for securing OLSRv2 sufficient and how
does that meet BCPs 61 and 107? ROLL has been stuck on this due
to punting on the defintion of key management mechanisms and
lots of work is having to be done to retro-fit security for
routing in sidr and karp so why is it ok for us to perhaps make
the same mistake (punting on security for routing) again?

Is there even a proof-of-concept that OLSRv2 can be used with
RFC6622 TLVs to produce a "secure" solution for routing in at
least some MANETs?

If there were at some "SHOUL implement" statements about some
flavour of use of RFC6622 and where an accompanying key
managment solution actually exists then this might be fine, but
as-is, it looks like nobody is going to get interop for
security without more work being done, and experiene with ROLL
seems to show that getting that done can be hard to impossible.

[Ballot comment]
This is a well written, clear document, and I'm happy to put a YES ballot on it.  The -17 version resolves all the questions I had, and thanks for addressing them.

[Ballot comment]
No objection to the publication of this document.
However, I would appreciate an answer/discussion on the following two points.

1.
When reading about MPRs, the first question I asked myself was: why two distinct devices for the two MPR types (flooding and routing). I found some information in the draft:

  When possible (in particular if using a
  hop count metric) the same routers may be picked as both flooding
  MPRs and routing MPRs.

And in section 18.1:

  Each router MAY select its flooding and routing MPRs independently
  from each other, or coordinate its selections.

However, the draft doesn't really explain the pros/cons of one versus two devices.
At first glance, I was thinking: "why do I want to have two different devices in dynamic topology: it simply going to add a level of complexity?". Maybe there are some other cases where link speed is involved.
A few words about this would be appreciated.

2.
More of clarifying question to start with. Not sure if there is a problem.
Since "OLSRv2 retains the same basic mechanisms and algorithms, enhanced by the ability to use a link metric other than hop count in the selection of shortest routes", I was wondering about the metric semantic.
Looking at this sentence:
  "This specification does not define the nature of the link metric.
  However, this specification allows, through use of the type extension
  of a defined Address Block TLV, for link metrics with specific
  meanings to be defined and either allocated by IANA or privately
  used."
I was expecting an IANA registry with the different metric types. What do I miss?
Or "Table 3: LINK_METRIC TLV definition" is really a placeholder for a metric, and we have no idea about the semantic? If this is the case, don't we run the risk that parts of the network have different configured metric types (hop count versus OSPF-like cost).

Disclaimer 1: I'm not a MANET expert
Disclaimer 2: I glanced through some parts of the draft.

[Ballot discuss]

Why are "guidelines" for securing OLSRv2 sufficient and how
does that meet BCPs 61 and 107? ROLL has been stuck on this due
to punting on the defintion of key management mechanisms and
lots of work is having to be done to retro-fit security for
routing in sidr and karp so why is it ok for us to perhaps make
the same mistake (punting on security for routing) again?

Is there even a proof-of-concept that OLSRv2 can be used with
RFC6622 TLVs to produce a "secure" solution for routing in at
least some MANETs?

If there were at some "SHOUL implement" statements about some
flavour of use of RFC6622 and where an accompanying key
managment solution actually exists then this might be fine, but
as-is, it looks like nobody is going to get interop for
security without more work being done, and experiene with ROLL
seems to show that getting that done can be hard to impossible.

[Ballot discuss]


Why are "guidelines" for securing OLSRv2 sufficient and how
does that meet BCPs 61 and 107? ROLL has been stuck on this due
to punting on the defintion of key management mechanisms and
lots of work is having to be done to retro-fit security for
routing in sidr and karp so why is it ok for us to perhaps make
the same mistake (punting on security for routing) again?

Is there even a proof-of-concept that OLSRv2 can be used with
RFC6622 TLVs to produce a "secure" solution for routing in at
least some MANETs?

If there were at some "SHOUL implement" statements about some
flavour of use of RFC6622 and where an accompanying key
managment solution actually exists then this might be fine, but
as-is, it looks like nobody is going to get interop for
security without more work being done, and experiene with ROLL
seems to show that getting that done can be hard to impossible.

[Ballot comment]
Throughout the document, there are references to assorted "time" values, but nowhere that I can find is there an explicit granularity requirement. Is the granularity documented elsewhere and therefore so obviously understood to be seconds by the MANET community that it is not worth mentioning in this document? If not, it might be worth mentioning.

I find all of the MUSTs and MAYs in the definitions of section 2 weird. For example:

      A router MUST be able to distinguish a routable address
      from a non-routable address by direct inspection of the network
      address, based on global scope address allocations by IANA and/or
      administrative configuration.  Broadcast and multicast addresses,
      and addresses which are limited in scope to less than the entire
      MANET, MUST NOT be considered as routable addresses.  Anycast
      addresses may be considered as routable addresses.

I'm trying to figure out what it would mean for a router to be unable to distinguish routable from non-routable addresses. What are the interoperability considerations here? "Considering broadcast and multicast addresses as routable" seems problematic in general, not just for this protocol. Aren't you simply saying that routers that implement this protocol will need to distinguish routable and non-routable addresses? Either way, why is this protocol instruction in the definitions section? Sounds like it should be in a "Basic Requirements" section if it needs to be a protocol requirement.

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...

Don't you mean, "TC messages and HELLO messages [RFC6130] will all use either IP or UDP in a given MANET in order that it be..."? I don't see what the MUST is doing in this sentence. The sentence is a statement of fact, not a protocol directive.

16.3.3.1 - 16.3.3.4: "The router MUST update its...". I always find MUSTs of this sort weird. It's not really a protocol requirement to update the internal state of the router. It's the behavior of the router that's the protocol requirement. These probably simply don't need MUSTs, though perhaps rewording is in order. But these sorts of MUSTs seem to appear throughout sections 7 through 12 anyway (requirements for local implementation of information bases), so perhaps this ship has sailed long ago in the MANET work.

[Ballot discuss]
This is a good document and I do not object in principle to the publication of the document.

However, there is a broader question about congestion potentially caused by this which isn't addressed in the document, especially not since it is on the Standards Track.

Everything in OLSRv2 about congestion control is copied from RFC 3626. RFC 3626 is Experimental,  so far so good.

1) Is there any guidance on congestion avoidance and control that was learned from deployments of RFC 3626?

2) The timers for the Message Interval Parameters (TC_INTERVAL and TC_MIN_INTERVAL) are fixed to
o  TC_INTERVAL := 5 seconds
o  TC_MIN_INTERVAL := TC_INTERVAL/4
Is there any recommendation to change the values for very low bandwidth links? Such as being used in MANETS?
The point is that on very low bandwidth links the messages carrying the OSLRv2 information could already take most of the share of the available bandwidth.

3) What would be the recommendation to an OLSRv2 instance experiencing congestion? And the resulting effects for the routing.

[Ballot discuss]
This is a very well written, clear document.  Despite its length (or perhaps because of it), it was very easy to understand, even for an Apps guy.  I'll be happy to enter a "yes" ballot after discussing one concern:

-- Section 16.3.1 --
  A router MAY recognize additional reasons for identifying that a
  message is invalid.  An invalid message MUST be silently discarded,
  without updating the router's Information Bases.

Does this cause any interoperability artifacts?  It seems to be saying that I can consider a message invalid for any reason I decide to come up with, and therefore silently discard any message for basically any reason.  Is that right?  If there are some criteria or limitations relating to those additional reasons, it'd be helpful to give them.  If it really is at a whim, how does that work?  (I see that Section 23.2 suggests some additional reasons, but this section just seems to leave it entirely open.)

I understand that this might just be a quality of implementation issue: if your router picks bogus reasons for discarding otherwise-valid messages, it'll suck and no one will use it.  In that case, is there a way that such a rogue router could be used to attack or DoS a MANET?

[Ballot comment]
I also have a few non-blocking comments that I'd like you to consider, and to feel free to chat with me about.

It seems odd to me that this document doesn't Obsolete 3626.  Can you tell me why it doesn't?  Is it expected that people will continue to experiment with or otherwise use OLSR (v1) after OLSRv2 is published as a Proposed Standard?

-- Section 3 --
This isn't really an Applicability Statement, at least not in the sense described in RFC 2026, Section 3.2.  This is a list of features of this protocol.  It's a fine section to have in here, but it doesn't talk about how this protocol can be used in any particular situations.

-- Section 5.1 --
  This protocol specifies TC messages, which are included in packets as
  defined by [RFC5444].  These packets MAY be sent either using the
  "manet" protocol number or the "manet" UDP well-known port number, as
  specified in [RFC5498].

I don't think this is the right use of "MAY".  As I read it, it says that use of either the protocol number or the port number is entirely optional.  You might well do neither, as you please.  Somehow, I don't think that's what you mean (though I've been wrong before, so just tell me so).  I think you really want a "MUST" here: if those are the only two choices, and you MUST pick one or the other, then MUST is your guy.

The next paragraph after that is a little malformed, "the same of either of" is very awkward.  I think you mean this, yes?:
NEW
  TC messages and HELLO messages [RFC6130] MUST, in a given MANET,
  either both be using IP or both be using UDP, in order that it is

-- Section 5.4.3 --
  o  If TLVs with Type = INTERVAL_TIME, as defined in [RFC5497], are
      included in TC messages, then TC_INTERVAL MUST be representable as
      described in [RFC5497].

Two questions on this:
1. As described *where* in RFC 5497.  I think it's Section 5, but I had to look around.  Please say that ("as described in [RFC5497], Section 5," or wherever).

2. TC_INTERVAL is a number -- what does it mean for it *not* to be "representABLE" as described there?  Do you mean that it must be "representED" that way?  Or something else?

(1) and (2) also apply to T_HOLD_TIME in 5.4.4.

-- Section 5.4.8 --
  A MANET using
  this protocol with too many routers having either willingness value
  equal to WILL_NEVER will not function; it MUST be ensured, by
  administrative or other means, that this does not happen.

Well said.  But is there any guidance that will help determine what "too many" means?  Any way to recommend (non-normatively) some percentage of routers that need to be willing to be selected as flooding and routing MPRs?  Or if not percentage, then at least some other quantitative guidance?

  The following constraints apply to these parameters:
  o  WILL_FLOODING >= WILL_NEVER
  o  WILL_FLOODING <= WILL_ALWAYS
  o  WILL_ROUTING >= WILL_NEVER
  o  WILL_ROUTING <= WILL_ALWAYS

This is a take-it-or-leave-it comment: we often use this mechanism to indicate this sort of "this value must be in between these other two" relationship, and I think it makes the relationship even clearer:

  The following constraints apply to these parameters:
  o  WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS
  o  WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS

This also could apply to 5.4.3:

  The following constraints apply to these parameters:
  o  TC_INTERVAL > 0
  o  0 <= TC_MIN_INTERVAL <= TC_INTERVAL

-- Section 6.1 --
  Link metrics are reported in messages using a compressed
  representation that occupies 12 bits, a 4 bit field and an 8 bit
  field.

This sounds like it's three things.  I think you mean this:

NEW
  Link metrics are reported in messages using a compressed
  representation that occupies 12 bits, comprising a 4 bit
  field and an 8 bit field.

-- Section 7.2 --
  The
  Local Attached Network Set is not modified by this protocol.  This
  protocol MAY respond to changes to the Local Attached Network Set,
  which MUST reflect corresponding changes in the router's status.

The last line invites imprecision and uncertain interpretation as to the antecedent of "which".  What is it that MUST reflect corresponding changes in the router's status?

- Is it the Local Attached Network Set?  That doesn't seem right, because you just said that it's not modified here, so a new MUST can't be applied to it, can it?

- Is it the *changes* to the Local Attached Network Set?  That doesn't seem to make semantic sense; how can it be changes that reflect corresponding changes?

- Is it this protocol?  That makes sense, but doesn't come out of the sentence that's written.

Can you re-write these sentences to make this clearer?  And then I presume that the "it" at the start of the next sentence is "The Local Attached Network Set".

-- Section 14.3 --

The logic here seems to be (if I'm reading it right):

if (1) then discard
else (2) {
  if (2.1) then discard
  else (2.2) {
      do 2.2.1
      if (2.2.2) then discard
      else {
        if (2.2.3) {
            do 2.2.3.1
            do 2.2.3.2
            do 2.2.3.3
        }
        else *** there is no else ***
      }
  }
}

What must happen when the "otherwise if" in 2.2.3 is not true?

-- Section 16.2 --
  When sending a TC message in response to a change of advertised
  network addresses, a router MUST respect a minimum interval of
  TC_MIN_INTERVAL between generated TC messages.  Sending an incomplete
  TC message MUST NOT cause the interval between complete TC messages
  to be increased, and thus a router MUST NOT send an incomplete TC
  message if within TC_MIN_INTERVAL of the next scheduled complete TC
  message.

The first part of the second sentence confused me for a while, and it wasn't until I started typing this comment that I think I figured it out.  You're saying that if you send an incomplete TC message when a complete TC message would be expected in less than TC_MIN_INTERVAL from now, then the complete TC message would be required to wait, and that would be bad -- so don't do that.  Is that right?

I think that second sentence is hard to understand as written (at least, it took me several readings and some intervening misunderstandings), and I wonder if you can try to re-phrase it.

-- Appendix D --
I worry slightly that this appendix is normative, but comes after three non-normative example appendixes.  Perhaps that's fine, and I worry unnecessarily.  Would it be at all worthwhile to say something where Appendix D is cited, in the first bullet in Section 22 ?  Maybe something as simple as adding the word "normative"?: "All updates to the elements specified in this specification are subject to the normative constraints specified in [RFC6130] and Appendix D."

IANA has reviewed draft-ietf-manet-olsrv2-15 and has the following  comments:

IANA has questions about the IANA actions requested in this document.

IANA understands that, upon approval of this document, there are 11
actions which IANA needs to complete.

First, in the Message Types subregistry of the Mobile Ad hoc NETwork (MANET)
Parameters registry located at:

http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges

a new Message Type will be registered as follows from the 0-233 range of the
subregistry:

Type: [ TBD ]
Description: TC : Topology Control (MANET-wide signaling)
Reference: [ RFC-to-be ]

Currently the Message Types subregistry is maintained through expert review as
defined in RFC 5226.

IANA Question -> has the document been reviewed by the Message Types subregistry
expert?

Second, a new registry will be created called the "Message-Type-specific Message
TLVs for TC messages" registry.  This new subregistry will be located in the
Message Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters
registry located at:

http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges

For Types 128 through 223 inclusive, the Description will be "Unassigned" and
the Registration Procedure will be "Expert Review" as defined in RFC 5226.

IANA Question ---> Are the ranges 0-127 and 224-255 to be marked "Reserved?"

Third, a new registry will be created called the "Message-Type-specific Address
Block TLVs for TC messages" registry.  This new subregistry will be located in
the Message Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters
registry located at:

http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges

For Types 128 through 223 inclusive, the Description will be "Unassigned" and
the Registration Procedure will be "Expert Review" as defined in RFC 5226.

IANA Question ---> Are the ranges 0-127 and 224-255 to be marked "Reserved?"

Fourth, in the Message TLV Types subregistry of the Mobile Ad hoc NETwork
(MANET) Parameters registry located at:

http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges

two new Message TLV Types will be created as follows:

Type: [ TBD ]
Description: MPR_WILLING
Reference: [ RFC-to-be ]

Type: [ TBD ]
Description: CONT_SEQ_NUM
Reference: [ RFC-to-be ]

Fifth, a new subregistry will be created called the "MPR_WILLING Message Type
Extensions" subregistry.  This new subregistry will be located in the Message
Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry
located at:

http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges


There are initial assignments and Registration Policies as follows (TBD in this
case refers to the value created for MPR_WILLING in task four above):

+-------------+------+-----------+---------------------+------------+
|    Name    | Type |    Type  | Description        | Allocation |
|            |      | Extension |                    | Policy    |
+-------------+------+-----------+---------------------+------------+
| MPR_WILLING | TBD  |    0    | Bits 0-3 specify    |            |
|            |      |          | the originating    |            |
|            |      |          | router's            |            |
|            |      |          | willingness to act  |            |
|            |      |          | as a flooding MPR;  |            |
|            |      |          | bits 4-7 specify    |            |
|            |      |          | the originating    |            |
|            |      |          | router's            |            |
|            |      |          | willingness to act  |            |
|            |      |          | as a routing MPR.  |            |
| MPR_WILLING | TBD2 |  1-255  | Unassigned.        | Expert    |
|            |      |          |                    | Review    |
+-------------+------+-----------+---------------------+------------+

Sixth, a new subregistry will be created called the "CONT_SEQ_NUM Message Type
Extensions" subregistry.  This new subregistry will be located in the Message
Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry
located at (TBD in this case refers to the value created for CONT_SEQ_NUM in
task four above):

http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges


There are initial assignments and Registration Policies as follows:

+--------------+------+-----------+--------------------+------------+
|    Name    | Type |    Type  | Description        | Allocation |
|              |      | Extension |                    | Policy    |
+--------------+------+-----------+--------------------+------------+
| CONT_SEQ_NUM | TBD  |    0    | COMPLETE:          |            |
|              |      |          | Specifies a        |            |
|              |      |          | content sequence  |            |
|              |      |          | number for this    |            |
|              |      |          | complete message.  |            |
| CONT_SEQ_NUM | TBD  |    1    | INCOMPLETE:        |            |
|              |      |          | Specifies a        |            |
|              |      |          | content sequence  |            |
|              |      |          | number for this    |            |
|              |      |          | incomplete        |            |
|              |      |          | message.          |            |
| CONT_SEQ_NUM | TBD  |  2-255  | Unassigned.        | Expert    |
|              |      |          |                    | Review    |
+--------------+------+-----------+--------------------+------------+

Seventh, in the Address Block TLV Types subregistry of the Mobile Ad hoc NETwork
(MANET) Parameters registry located at:

http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges

Four new Address Block TLV Types will be registered from the 8 - 127 range as
follows:

Type: [ TBD ]
Description: LINK_METRIC
Reference: [ RFC-to-be ]

Type: [ TBD ]
Description: MPR
Reference: [ RFC-to-be ]

Type: [ TBD ]
Description: NBR_ADDR_TYPE
Reference: [ RFC-to-be ]

Type: [ TBD ]
Description: GATEWAY
Reference: [ RFC-to-be ]

Currently the Address Block TLV Types subregistry is maintained through expert
review as defined in RFC 5226.

IANA Question -> has the document been reviewed by the Address Block TLV Types
subregistry expert?

Eighth, a new registry called the "LINK_METRIC Address Block TLV Type
Extensions" subregistry will be created. The new subregistry will be
asubregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at:

http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges


Initial assignments and registration procedures are as follows:

(TBD below refers to the Address Block TLV Type registered for LINK_METRIC in
action seven above)

+-------------+------+-----------+-------------------+--------------+
|    Name    | Type |    Type  | Description      | Allocation  |
|            |      | Extension |                  | Policy      |
+-------------+------+-----------+-------------------+--------------+
| LINK_METRIC | TBD  |    0    | Link metric      |              |
|            |      |          | meaning assigned  |              |
|            |      |          | by administrative |              |
|            |      |          | action.          |              |
| LINK_METRIC | TBD  |  1-223  | Unassigned.      | Expert      |
|            |      |          |                  | Review      |
| LINK_METRIC | TBD  |  224-255  | Unassigned.      | Experimental |
|            |      |          |                  | Use          |
+-------------+------+-----------+-------------------+--------------+

Ninth, a new registry called the "MPR Address Block TLV Type Extensions"
subregistry will be created. The new subregistry will be asubregistry of the
Mobile Ad hoc NETwork (MANET) Parameters registry located at:

http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges


Initial assignments and registration procedures are as follows:

(TBD below refers to the Address Block TLV Type registered for MPR in action
seven above)

+------+------+-----------+----------------------------+------------+
| Name | Type |    Type  | Description                | Allocation |
|      |      | Extension |                            | Policy    |
+------+------+-----------+----------------------------+------------+
|  MPR | TBD  |    0    | Specifies that a given    |            |
|      |      |          | network address is of a    |            |
|      |      |          | router selected as a      |            |
|      |      |          | flooding MPR (FLOODING =  |            |
|      |      |          | 1), that a given network  |            |
|      |      |          | address is of a router    |            |
|      |      |          | selected as a routing MPR  |            |
|      |      |          | (ROUTING = 2), or both    |            |
|      |      |          | (FLOOD_ROUTE = 3).        |            |
|  MPR | TBD  |  1-255  | Unassigned.                | Expert    |
|      |      |          |                            | Review    |
+------+------+-----------+----------------------------+------------+

Tenth, a new registry called the "NBR_ADDR_TYPE Address Block TLV Type
Extensions" subregistry will be created. The new subregistry will be
asubregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at:

http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges


Initial assignments and registration procedures are as follows:

(TBD below refers to the Address Block TLV Type registered for NBR_ADDR_TYPE in
action seven above)

+---------------+------+-----------+-------------------+------------+
|      Name    | Type |    Type  | Description      | Allocation |
|              |      | Extension |                  | Policy    |
+---------------+------+-----------+-------------------+------------+
| NBR_ADDR_TYPE | TBD  |    0    | Specifies that a  |            |
|              |      |          | given network    |            |
|              |      |          | address is of a  |            |
|              |      |          | neighbor reached  |            |
|              |      |          | via the          |            |
|              |      |          | originating      |            |
|              |      |          | router, if it is  |            |
|              |      |          | an originator    |            |
|              |      |          | address          |            |
|              |      |          | (ORIGINATOR = 1), |            |
|              |      |          | is a routable    |            |
|              |      |          | address (ROUTABLE |            |
|              |      |          | = 2), or if it is |            |
|              |      |          | both              |            |
|              |      |          | (ROUTABLE_ORIG =  |            |
|              |      |          | 3).              |            |
| NBR_ADDR_TYPE | TBD  |  1-255  | Unassigned.      | Expert    |
|              |      |          |                  | Review    |
+---------------+------+-----------+-------------------+------------+

Eleventh, a new registry called the "GATEWAY Address Block TLV Type Extensions"
subregistry will be created. The new subregistry will be asubregistry of the
Mobile Ad hoc NETwork (MANET) Parameters registry located at:

http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges


Initial assignments and registration procedures are as follows:

(TBD below refers to the Address Block TLV Type registered for GATEWAY in action
seven above)

+---------+------+-----------+-------------------------+------------+
|  Name  | Type |    Type  | Description            | Allocation |
|        |      | extension |                        | Policy    |
+---------+------+-----------+-------------------------+------------+
| GATEWAY | TBD  |    0    | Specifies that a given  |            |
|        |      |          | network address is      |            |
|        |      |          | reached via a gateway  |            |
|        |      |          | on the originating      |            |
|        |      |          | router, with value      |            |
|        |      |          | equal to the number of  |            |
|        |      |          | hops.                  |            |
| GATEWAY | TBD  |  1-255  |                        | Expert    |
|        |      |          |                        | Review    |
+---------+------+-----------+-------------------------+------------+

IANA understands that these eleven actions are the only ones that IANA
needs to complete upon approval of this document.

Note:  The actions requested in this document will not be completed until
the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Optimized Link State Routing Protocol version 2) to Proposed Standard


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

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Optimized Link State Routing Protocol version 2) to Proposed Standard


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'
  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@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting. This last call
periodhas been extended to handle the fact that it spans the IETF-84
meeting.


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.

(1) The request is to publish this document as a Standards Track RFC,
and this is indicated in the document header.

OLSRv2 reflects approximately 8 years of experiences with OLSR,
published as experimental RFC3626, and multiple independent
implementations and deployments exist. It is built on the Proposed
Standard "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol
(NHDP)" (RFC 6130) that was spun-off from it.

(2) Document Announcement Write-Up.

Technical Summary

The abstract of this document is included below.

This document describes version 2 of the Optimized Link State Routing
(OLSRv2) protocol for mobile ad hoc networks. The protocol is an
optimization of the classical link state algorithm tailored to the
requirements of a mobile wireless LAN.

The key optimization of OLSRv2 is that of multipoint relays, providing
an efficient mechanism for network-wide broadcast of link-state
information. A secondary optimization is that OLSRv2 employs partial
link-state information: each node maintains information of all
destinations, but only a subset of links. This allows that only select
nodes diffuse link-state advertisements (i.e. reduces the number of
network-wide broadcasts) and that these advertisements contain only a
subset of links (i.e. reduces the size of each network-wide broadcast). 
The partial link-state information thus obtained allows each OLSRv2 node
to at all times maintain optimal (in terms of number of hops) routes to
all destinations in the network.

OLSRv2 imposes minimum requirements to the network by not requiring
sequenced or reliable transmission of control traffic. Furthermore, the
only interaction between OLSRv2 and the IP stack is routing table
management.

OLSRv2 is particularly suitable for large and dense networks as the 
technique of MPRs works well in this context.


Working Group Summary

o OLSRv2 is the routing protocol, which uses as constituent parts
  (and from which was spun off) the already published by the MANET
  Working Group RFCs 5148, 5444, 5497, and 6130. The document also
  uses RFC 5498 - also already published by the MANET Working Group.

  This document is, therefore, an integral part of the Working Group
  deliverables, and its publication completes the charter item of a
  "proactive MANET protocol".

o OLSRv2 was first submitted as an individual draft in July 2005
  (draft-clausen-manet-olsrv2-00), and accepted as a Working Group
  document in August 2005.

o A key difference between RFC3626 and OLSRv2 is the introduction of
  support for link metrics. An individual draft
  (draft-dearlove-olsrv2-metrics-00) was submitted in 2007, discussing
  the design options, culminating in 2010 with
  draft-dearlove-olsrv2-metrics-05 documenting Working Group consensus
  on this matter. Metrics support was, then, folded into OLSRv2.

o This version of OLSRv2 was given a one month WGLC, so as to ensure
  sufficient time to review the document.

o The Working Group is actively working on the associated MIB document
  (draft-ietf-manet-olsrv2-mib)

There was an issue concerning the differences between the -14 and -15
revisions of the document, brought up by one WG member. The consensus
opinion from the WG is that the document should proceed, without
additional edits.


Document Quality

There is a number of independent implementations of OLSRv2. Those
listed below have, explicitly, consented to be nominatively mentioned:

o Ecole Polytechnique, France
  (Contact: Thomas Clausen)

o CRC - Communications Research Centre Canada
  (Contact: Yannick Lacharite)

o INRIA, France
  (Contact: Cedric Adjih)

o Hitachi Yokohama Research Lab, Japan
  (Contact: Hiroki Satoh)

o BAE Systems Advanced Technology Centre, UK
  (Contact Christopher Dearlove)

Finally, in the open-source world:

o Fraunhofer FKIE is working on the olsr.org implementation of OLSRv2
  (Contact: Henning Rogge)

o Niigata University, Japan
  http://www2.net.ie.niigata-u.ac.jp/nuOLSRv2/
  (Contact: Hiroei Imai)

Over the years, several interoperability events have been organized, in
France, Canada, Japan, Austria, ....


Personnel

The Document Shepherd is Stan Ratliff (sratliff@cisco.com); the
responsible Area Directors are Adrian Farrel and Stewart Bryant.

(3) The document Shepherd has participated in review both in the Working
Group, and has run the "idnits" tool against the draft.

(4) The Document Shepherd has no concerns about the reviews of the
document; they have been very thorough.

(5) The authors do not believe that additional reviews are required,
aside from the usual directorate reviews during IETF last call.

(6) The Document Shepherd has no concerns with the document.

(7) All authors have confirmed that they are unaware of any IPR needing
disclosure; there are no known IPR claims related to this document.

(8) No IPR disclosures have been filed, as none are required.

(9) WG consensus appears to be strong.

(10) As mentioned earlier, one WG participant has expressed displeasure
to the AD's. As of this writing, the issue seems to be closed, and no
further action is required.

(11) No ID nits were found.

(12) Mib Doctor, media type, and URI reviews are not required.

(13) All references have been defined as either normative or
informative.

(14) No normative references exist to documents not ready for
advancement. Of the normative references, all are to already published
RFC's.

(15) This document contains a downref to RFC5148. RFC5148 was published
as  "Informational", as this document provides guidance as to how to
schedule message transmissions so as to avoid collisions on some common
(in MANET) media types. As RFC5148 does not prescribe behavior that
impacts interoperability, the understanding with the responsible AD when
publishing RFC5148 was that this would not cause any process-problems so
long as it was called out.

(16) Publication of this document will NOT change the status of any
existing RFC.

(17) The Document Shepherd has reviewed the IANA considerations section
of the document, and it appears wholly consistent with the body of said
document. Extensions are associated with the appropriate reservations in
IANA registries. All IANA registries have been clearly defined.

(18) Impact on IANA registries :

This specification defines one Message Type, which must be allocated
from the "Message Types" repository of [RFC5444], two Message TLV Types,
which must be allocated from the "Message TLV Types" repository of
[RFC5444], and four Address Block TLV Types, which must be allocated
from the "Address Block TLV Types" repository of [RFC5444].

Each TLV type incurs creation of a "Type Extension" registry. This
document requests these registry creations, and (by way of referencing
allocation procedures from [RFC5444]) also specifies allocation
policies.

Each Message type incurs creation of a Message-Type-specific TLV
registry. This document requests these registry creations, and (by way
of referencing allocation procedures from [RFC5444]) also specifies
allocation policies.

IANA registry creation and allocations are done exactly as in RFC6130.

(19) The Document Shepherd has run the idnits tool against the document;
all issues have been resolved.