Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
draft-ietf-manet-olsrv2-multitopology-07

[Ballot comment]

Thanks for addressing my DISCUSS and Sue's points.

Editorial comments:

Section 12

"If the MANET may contain non-MT-OLSRv2 routers,"
This is weird sentence.

The next bullet point contains a similar sentence which I believe is more appropriate:
"Note that if there is any possibility that there are any routers not implementing MT-OLSRv2"

The following sentence could also be improved (may or may not)
      "If a packet is created for a destination that is not part of the
      corresponding topology then it may or may not be delivered (if the
      originating router is a non-MT-OLSRv2 router) or will not be
      transmitted (if the originating router is an MT-OLSRv2 router).
      Routers SHOULD be managed so that this does not occur."

Regards, Benoit

[Ballot discuss]
The multiple points, brought up by Sue part of her OPS-DIR review, deserve a DISCUSS. Let's engage in the discussion.

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.

[Ballot comment]
Let's please have a brief, non-blocking discussion of the "updates" status here.  As I read this, I don't see how this updates either 7181 or 7188.  It clearly doesn't update 7188: it's just using an extension mechanism that was specified in 7188.  I also don't think it updates 7181, because it's specifying an optional (indeed, experimental) extension.  Here: does someone reading 7181, with no interest in implementing this experimental extension, need to read (or even know about) this document?  I think the answer is no.

(There's also the spurious "XXXX" in the updates list, which should be removed.)

Update: The authors confirm that it doesn't matter to them, and they just want it to be right.  Unless anyone thinks otherwise, I think we should remove all the "updates" on this one.

[Ballot comment]
Let's please have a brief, non-blocking discussion of the "updates" status here.  As I read this, I don't see how this updates either 7181 or 7188.  It clearly doesn't update 7188: it's just using an extension mechanism that was specified in 7188.  I also don't think it updates 7181, because it's specifying an optional (indeed, experimental) extension.  Here: does someone reading 7181, with no interest in implementing this experimental extension, need to read (or even know about) this document?  I think the answer is no.

(There's also the spurious "XXXX" in the updates list, which should be removed.)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-manet-olsrv2-multitopology-05.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments:

IANA understands that at least one of the actions requested in the IANA Considerations section of this document is dependent on the approval of another draft.

IANA understands that, upon approval of this document, there are four actions which IANA must complete.

First, in the Type 7 Message TLV Type Extensions subregistry renamed from MPR_WILLING Message Type Extensions by the approval of draft-ietf-manet-tlv-naming, the following change will be made:

Table 4 of draft-ietf-manet-tlv-naming is to be replaced by the following (where [tlv-naming] represents the approved draft draft-ietf-manet-tlv-naming):

+-----------+-------------+-------------------------+---------------+
| Type | Name | Description | Reference |
| Extension | | | |
+-----------+-------------+-------------------------+---------------+
| 0 | MPR_WILLING | First (most | [RFC7181] |
| | | significant) half octet | [tlv-naming] |
| | | of Value field | [ RFC-to-be ] |
| | | specifies the | |
| | | originating router's | |
| | | willingness to act as a | |
| | | flooding MPR; | |
| | | subsequent half octets | |
| | | specify the originating | |
| | | router's willingness to | |
| | | act as a routing MPR, | |
| | | either for the link | |
| | | metric types reported | |
| | | in an MPR_TYPES TLV (in | |
| | | the same order), or (if | |
| | | no MPR_TYPES TLV is | |
| | | present) for the single | |
| | | administratively agreed | |
| | | link metric type | |
| 1 | MPR_TYPES | The link metric types | [ RFC-to-be ] |
| | | supported on this | |
| | | OLSRv2 interface of | |
| | | this router (one octet | |
| | | each). | |
| 2-223 | | Unassigned | |
| 224-255 | | Reserved for | [RFC7181] |
| | | Experimental Use | |
+-----------+-------------+-------------------------+---------------+

Second, in the MPR TLV BIT Values subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at:

https://www.iana.org/assignments/manet-parameters/

the following two changes are to be made:

the description for bit 7, value 0x01 is changed to: "If set then the neighbor with that network address has been selected as flooding MPR"

the description for bit 8, value 0x02 is changed to: "If set then the neighbor with that network address has been selected as routing MPR, either for the link metric types reported in an MPR_TYPES TLV (in the same order), or (if no MPR_TYPES TLV is present) then (first octet bit 6, value 0x02) for the single administratively agreed link metric type"

In both cases the reference is to be updated to [ RFC-to-be ].

Third, Table 14 of draft-ietf-manet-tlv-naming is to be replaced by the following (where [tlv-naming] represents the approved draft draft-ietf-manet-tlv-naming):

+-----------+---------+-----------------------------+---------------+
| Type | Name | Description | References |
| Extension | | | |
|-----------+---------+-----------------------------+---------------+
| 0 | GATEWAY | Specifies that a given | [RFC7181] |
| | | network address is reached | [ RFC-to-be ] |
| | | via a gateway on the | |
| | | originating router. The | |
| | | number of hops is indicated | |
| | | by the Value field, one | |
| | | octet per link metric type | |
| | | reported in an MPR_TYPES | |
| | | Message TLV (in the same | |
| | | order) or (if no MPR_TYPES | |
| | | Message TLV is present) | |
| | | using a single octet | |
| 1-223 | | Unassigned | |
| 224-255 | | Reserved for Experimental | [tlv-naming] |
| | | Use | |
+-----------+---------+-----------------------------+---------------+

Fourth, Table 13 of [RFC7181] is to be replaced by the following:

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

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before these changes can be made.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Experimental RFC


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Multi-Topology Extension for the Optimized Link State Routing Protocol
  version 2 (OLSRv2)'
  as Experimental RFC

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 2015-05-15. 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.

Abstract


  This specification describes an extension to the Optimized Link State
  Routing Protocol version 2 (OLSRv2) to support multiple routing
  topologies, while retaining interoperability with OLSRv2 routers that
  do not implement this extension.

  This specification updates RFC 7181 by creating an interoperable
  extension to it.  This specification updates RFC 7188 and RFC XXXX by
  modifying and extending TLV registries and descriptions.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ballot/


No IPR declarations have been submitted directly on this I-D.

Question about IANA
==========

Hi,

I have started my AD review of your draft having received the
publication request. before I get too far into the document, I want to
discuss the IANA Considerations section which, I think, needs a little
work.

- - -

The IANA Considerations section of the document does not give IANA clear
instructions about what they should do. They need to hear:
- go to registry named foo
- go to sub-registry named bar
- make the following change to the registry...

Everything else is a distraction to them and needs to come out of the
document completely or be moved to another section.

- - -

But first, two meta questions:

1. In some of the sub-registries where you are assigning new Type
  Extensions, there is already scope for "Experimental Use."  Why do
  you feel the need to have Expert Review assignments rather than using
  experimental values (the latter would not have their values recorded
  against this RFC nor have the values recorded in this RFC)?

  I should add here that you *are* allowed to have Expert Review
  assignments for Experimental RFCs (if the experts so agree).

2. I am fixing (on this week's IESG telechat) the fact that many of
  these sub-registries are missing their Designated Experts. That's a
  formality, and the WG chairs can stand in these roles.

  However, I suspect that the DEs have not explicitly made clear that
  they are OK with the assignments in this document. That's OK, but I
  just need to know (normally in the Shepherd write-up) and to let you
  know that IANA will ping the DEs at some point to get them to sign
  off, so making sure that they are happy in advance is a good way to
  avoid surprises.

  (The guidance to DEs in 5444/6.1 seems very clear.)

- - -

Section 13.1 as far as I can tell does not change the guidelines to the
Designated Experts that have already been established. So I think you
can safely delete this section. In particular, this section does not
give IANA any information.

- - -

Section 13.2

>  This specification replaces Table 11 of [RFC7181].

This reads like you are Updating 7181 (i.e. changing that specification).
I don't believe that is your intention
 
 
>  That specified a
>  Message MPR Type described as MPR_WILLING, for which only Type
>  Extension 0 was defined.  This specification reserves that name
>  MPR_WILLING for Type Extension 0,

I think you mean "retains". "Reserve" has a specific IANA meaning of
"not available for use".

However, it appears that you are updating the text for the MPR_WILLING/0
value in the "MPR_WILLING Message Type Extensions" sub-registry found at
https://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#mpr-willing-message-type-extension

This you observe in the next sentence where you say:

>  It also changes the Value field
>  specification of the MPR_WILLING TLV.

You need to show IANA the old text and the new text. I think that the
text in your Table 2 may be useful to retain in this document (in
another section) but is too much text for IANA to include in their
registry.

>  defines a new Type Extension 1, with a new name MPR_TYPES,

I don't think you can do this!
Type 7 is already entirely known as MPR_WILLING (see the "Message TLV
Types" sub-registry).

So your choice here is to use a new Message TLV or to retain the same
name for the new Type Extension.

As far as IANA is concerned, you need to tell them:
- in which sub-registry to include Type Extension 1
- what text to include with it

>  and leaves the remaining Type Extensions
>  of this TLV Type unnamed.

"Unnamed"? Maybe you mean "Unassigned"?

>  Specifications of these TLVs are in Table 2.  Each of these TLVs MUST
>  NOT be included more than once in a Message TLV Block.

I don't think that IANA needs to see this table, and certainly doesn't
need to know about the protocol rules.

- - -

Section 13.3

>  Table 16 of [RFC7181] is replaced by Table 3.  Note that the only
>  change is to the description of the Value field.

If you are replacing a table in 7181 then you are updating 7181. But is
that what this draft is doing?

Anyway, I don't think IANA is interested in this point. They want to
know what changes to make to the "GATEWAY Address Block TLV Type
Extensions" sub-registry at
https://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#gateway-address-block-tlv-type-extension

Again, just old and new text.

If you want to include Table 3 in this document, then please put it
outside this section.

>  Table 13 of [RFC7181] is replaced by Table 4.  Note that the only
>  change is to allocate 8 Type Extensions as assigned by administrative
>  action, in order to support administratively determined multi-
>  topologies.

Pretty much exactly the same considerations.

- - -

If you can answer all this quickly, I can go ahead with the rest of my
review. I suspect that the answers will need a revised I-D, but we can
batch that with the rest of my review once I know what the answers are.

Thanks,
Adrian

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this
type of RFC indicated in the title page header?

        Publication as experimental is requested. This is indicated in the title
        page header.

        The document specifies a multi-topology extension to RFC7181 (OLSRv2), for
        which a stable specification is required for gaining operational experience
        prior to advancing onto standards track. The document contains a section
        "Motivation and Experimentation" indicating which experiments this
        specification, particularly, is intended to facilitate.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
        This specification describes an extension to the Optimized Link State
        Routing Protocol version 2 (OLSRv2) to support multiple routing
        topologies, while retaining interoperability with OLSRv2 routers that
        do not implement this extension.

Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there
controversy about particular points or were there decisions where the consensus was
particularly rough?

        There were no particular points of contention in the WG process, and the
        consensus behind publication of this document as an Experimental RFC
        appears solid.

Document Quality:
Are there existing implementations of the protocol? Have a significant number of
vendors indicated their plan to implement the specification? Are there any reviewers
that merit special mention as having done a thorough review, e.g., one that resulted in
important changes or a conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the request posted?

        There are two experimental implementations of the specification.
        There have been good discussions of the document among the WG participants,
        in general (reflected in the acknowledgements section).
        There have been no specific MIB doctor, Media Type or other expert reviews
        done.

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?

        The Document Shepherd is Ulrich Herberg.
        The Responsible Area Director is Adrian Farrel.

(3) Briefly describe the review of this document that was performed by the Document
Shepherd. If this version of the document is not ready for publication, please explain
why the document is being forwarded to the IESG.

        The document shepherd has reviewed this document, both as part of the
        WG process, and prior to the issuance of the Publication Request.
        The document shepherd believes that this version of the document is
        ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed?

        The document shepherd has no concerns with the depth or
        breadth of the reviews of this document.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

        This document does not need reviews beyond those normally done during
        AD and IESG processing.

(6) Describe any specific concerns or issues that the Document Shepherd has with this
document that the Responsible Area Director and/or the IESG should be aware of?
For example, perhaps he or she is uncomfortable with certain parts of the document,
or has concerns whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to advance the document,
detail those concerns here.

        The document shepherd has no specific concerns with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required
for full conformance with the provisions of BCP 78 and BCP 79 have already been
filed. If not, explain why?

        Each author has confirmed that they are not aware of any IPR requiring
        disclosure.

(8) Has an IPR disclosure been filed that references this document? If so, summarize
any WG discussion and conclusion regarding the IPR disclosures.

        No IPR disclosures have been filed, referencing this document.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the WG as a
whole understand and agree with it?

        The WG consensus behind this document appears solid. Several reviews
        have been made, and it has been discussed on the list and at WG meetings
        since IETF87.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

        No appeals have been threatened.
        No extreme discontent has been indicated.

(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks
are not enough; this check needs to be thorough.

        IDNIT returns no errors and no warnings.

(12) Describe how the document meets any required formal review criteria, such as
the MIB Doctor, media type, and URI type reviews.

        This document does not require any of these reviews.

(13) Have all references within this document been identified as either normative or
informative?

        All references have been identified as either normative or informative.

(14) Are there normative references to documents that are not ready for advancement
or are otherwise in an unclear state? If such normative references exist, what is the
plan for their completion?

        All normative references are to already published RFC at the same,
        or on a higher, maturity level.

        All informative references are to already published RFC at the same,
        or on a higher, maturity level.

(15) Are there downward normative references references (see RFC 3967)? If so, list
these downward references to support the Area Director in the Last Call procedure.

        There are no downward references.

(16) Will publication of this document change the status of any existing RFCs? Are
those RFCs listed on the title page header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract and Introduction, explain why,
and point to the part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document, explain why the
WG considers it unnecessary.

        This document does not change the status if any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.

        The document shepherd has reviewed the IANA considerations section, which
        is both consistent with the body of the document, and straight-forward in
        that for each registry modified, the document provides "replacement tables"
        for how the registry shall look after being updated by this document.

Confirm that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries.

        This is confirmed.

Confirm that any referenced IANA registries have been clearly identified.

        All referenced IANA registries have been clearly identified.

Confirm that newly created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations are
defined, and a reasonable name for the new registry has been suggested (see RFC
5226).

        This document does not create any new IANA registries.

(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA
Experts for these new registries.

        This document does not create any new IANA registries.
       
        This specification adds one new Message TLV, MPR_TYPES, allocated as a new
        Type Extension to an existing Message TLV from RFC7181. The relevant registry
        is established by Table 11 of [RFC7181]. This specification also modifies the
        Value field of an existing Message TLV, MPR_WILLING, established in Table 11
        of [RFC7181].
        This specification provides, in Table 2, how the registry will look after
        these allocations and modifications have been made

        This specification updates the description of the IANA allocation for the
        GATEWAY Address Block TLV Type, established in Table 16 of
        [RFC7181].

        This specification provides, in Table 3, how the registry will look after
        these allocations and modifications have been made

        This specification makes additional allocations for "administrative assignment" of
        metrics types from the LINK_METRIC Address Block TLV Type registry,
        established by Table 13 of [RFC7181].
       
        This specification provides, in Table 4, how the registry will look after
        these allocations and modifications have been made

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

        No formal language is contained in the document.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this
type of RFC indicated in the title page header?

        Publication as experimental is requested. This is indicated in the title
        page header.

        The document specifies a multi-topology extension to RFC7181 (OLSRv2), for
        which a stable specification is required for gaining operational experience
        prior to advancing onto standards track. The document contains a section
        "Motivation and Experimentation" indicating which experiments this
        specification, particularly, is intended to facilitate.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
        This specification describes an extension to the Optimized Link State
        Routing Protocol version 2 (OLSRv2) to support multiple routing
        topologies, while retaining interoperability with OLSRv2 routers that
        do not implement this extension.

Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there
controversy about particular points or were there decisions where the consensus was
particularly rough?

        There were no particular points of contention in the WG process, and the
        consensus behind publication of this document as an Experimental RFC
        appears solid.

Document Quality:
Are there existing implementations of the protocol? Have a significant number of
vendors indicated their plan to implement the specification? Are there any reviewers
that merit special mention as having done a thorough review, e.g., one that resulted in
important changes or a conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the request posted?

        There are two experimental implementations of the specification.
        There have been good discussions of the document among the WG participants,
        in general (reflected in the acknowledgements section).
        There have been no specific MIB doctor, Media Type or other expert reviews
        done.

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?

        The Document Shepherd is Ulrich Herberg.
        The Responsible Area Director is Adrian Farrel.

(3) Briefly describe the review of this document that was performed by the Document
Shepherd. If this version of the document is not ready for publication, please explain
why the document is being forwarded to the IESG.

        The document shepherd has reviewed this document, both as part of the
        WG process, and prior to the issuance of the Publication Request.
        The document shepherd believes that this version of the document is
        ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed?

        The document shepherd has no concerns with the depth or
        breadth of the reviews of this document.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

        This document does not need reviews beyond those normally done during
        AD and IESG processing.

(6) Describe any specific concerns or issues that the Document Shepherd has with this
document that the Responsible Area Director and/or the IESG should be aware of?
For example, perhaps he or she is uncomfortable with certain parts of the document,
or has concerns whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to advance the document,
detail those concerns here.

        The document shepherd has no specific concerns with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required
for full conformance with the provisions of BCP 78 and BCP 79 have already been
filed. If not, explain why?

        Each author has confirmed that they are not aware of any IPR requiring
        disclosure.

(8) Has an IPR disclosure been filed that references this document? If so, summarize
any WG discussion and conclusion regarding the IPR disclosures.

        No IPR disclosures have been filed, referencing this document.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the WG as a
whole understand and agree with it?

        The WG consensus behind this document appears solid. Several reviews
        have been made, and it has been discussed on the list and at WG meetings
        since IETF87.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

        No appeals have been threatened.
        No extreme discontent has been indicated.

(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks
are not enough; this check needs to be thorough.

        IDNIT returns no errors and no warnings.

(12) Describe how the document meets any required formal review criteria, such as
the MIB Doctor, media type, and URI type reviews.

        This document does not require any of these reviews.

(13) Have all references within this document been identified as either normative or
informative?

        All references have been identified as either normative or informative.

(14) Are there normative references to documents that are not ready for advancement
or are otherwise in an unclear state? If such normative references exist, what is the
plan for their completion?

        All normative references are to already published RFC at the same,
        or on a higher, maturity level.

        All informative references are to already published RFC at the same,
        or on a higher, maturity level.

(15) Are there downward normative references references (see RFC 3967)? If so, list
these downward references to support the Area Director in the Last Call procedure.

        There are no downward references.

(16) Will publication of this document change the status of any existing RFCs? Are
those RFCs listed on the title page header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract and Introduction, explain why,
and point to the part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document, explain why the
WG considers it unnecessary.

        This document does not change the status if any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.

        The document shepherd has reviewed the IANA considerations section, which
        is both consistent with the body of the document, and straight-forward in
        that for each registry modified, the document provides "replacement tables"
        for how the registry shall look after being updated by this document.

Confirm that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries.

        This is confirmed.

Confirm that any referenced IANA registries have been clearly identified.

        All referenced IANA registries have been clearly identified.

Confirm that newly created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations are
defined, and a reasonable name for the new registry has been suggested (see RFC
5226).

        This document does not create any new IANA registries.

(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA
Experts for these new registries.

        This document does not create any new IANA registries.
       
        This specification adds one new Message TLV, MPR_TYPES, allocated as a new
        Type Extension to an existing Message TLV from RFC7181. The relevant registry
        is established by Table 11 of [RFC7181]. This specification also modifies the
        Value field of an existing Message TLV, MPR_WILLING, established in Table 11
        of [RFC7181].
        This specification provides, in Table 2, how the registry will look after
        these allocations and modifications have been made

        This specification updates the description of the IANA allocation for the
        GATEWAY Address Block TLV Type, established in Table 16 of
        [RFC7181].

        This specification provides, in Table 3, how the registry will look after
        these allocations and modifications have been made

        This specification makes additional allocations for "administrative assignment" of
        metrics types from the LINK_METRIC Address Block TLV Type registry,
        established by Table 13 of [RFC7181].
       
        This specification provides, in Table 4, how the registry will look after
        these allocations and modifications have been made

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

        No formal language is contained in the document.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

        Publication as experimental is requested. This is indicated in the title
        page header.

        The document specifies a multi-topology extension to RFC7181 (OLSRv2), for
        which a stable specification is required for gaining operational experience
        prior to advancing onto standards track. The document contains a section
        "Motivation and Experimentation" indicating which experiments this
        specification, particularly, is intended to facilitate.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
        This specification describes an extension to the Optimized Link State
        Routing Protocol version 2 (OLSRv2) to support multiple routing
        topologies, while retaining interoperability with OLSRv2 routers that
        do not implement this extension.

Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

        There were no particular points of contention in the WG process, and the
        consensus behind publication of this document as an Experimental RFC
        appears solid.

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

        There are two experimental implementations of the specification.
        There have been good discussions of the document among the WG participants,
        in general (reflected in the acknowledgements section).
        There have been no specific MIB doctor, Media Type or other expert reviews
        done.

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?

        The Document Shepherd is Ulrich Herberg.
        The Responsible Area Director is Adrian Farrel.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

        The document shepherd has reviewed this document, both as part of the
        WG process, and prior to the issuance of the Publication Request.
        The document shepherd believes that this version of the document is
        ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

        The document shepherd has no concerns with the depth or
        breadth of the reviews of this document.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

        This document does not need reviews beyond those normally done during
        AD and IESG processing.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

        The document shepherd has no specific concerns with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

        Each author has confirmed that they are not aware of any IPR requiring
        disclosure.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

        No IPR disclosures have been filed, referencing this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

        The WG consensus behind this document appears solid. Several reviews
        have been made, and it has been discussed on the list and at WG meetings
        since IETF87.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

        No appeals have been threatened.
        No extreme discontent has been indicated.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

        IDNIT returns no errors and no warnings.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

        This document does not require any of these reviews.

(13) Have all references within this document been identified as either normative or informative?

        All references have been identified as either normative or informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

        All normative references are to already published RFC at the same,
        or on a higher, maturity level.

        All informative references are to already published RFC at the same,
        or on a higher, maturity level.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

        There are no downward references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

        This document does not change the status if any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

        The document shepherd has reviewed the IANA considerations section, which
        is both consistent with the body of the document, and straight-forward in
        that for each registry modified, the document provides "replacement tables"
        for how the registry shall look after being updated by this document.

Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries.

        This is confirmed.

Confirm that any referenced IANA registries have been clearly identified.

        All referenced IANA registries have been clearly identified.

Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

        This document does not create any new IANA registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

        This document does not create any new IANA registries.
       
        This specification adds one new Message TLV, MPR_TYPES, allocated as a new
        Type Extension to an existing Message TLV from RFC7181. The relevant registry is established by Table 11 of [RFC7181]. This specification also modifies the Value field of an existing Message TLV, MPR_WILLING, established in Table 11 of [RFC7181].
        This specification provides, in Table 2, how the registry will look after
        these allocations and modifications have been made

        This specification updates the description of the IANA allocation for the
        GATEWAY Address Block TLV Type, established in Table 16 of [RFC7181].          This specification provides, in Table 3, how the registry will look after
        these allocations and modifications have been made

        This specification makes additional allocations for "administrative assignment" of metrics types from the LINK_METRIC Address Block TLV Type
        registry, established by Table 13 of [RFC7181].
        This specification provides, in Table 4, how the registry will look after
        these allocations and modifications have been made


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

        No formal language is contained in the document.