Skip to main content

Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
draft-ietf-manet-olsrv2-multipath-15

Revision differences

Document history

Date Rev. By Action
2017-08-22
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-08-03
15 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-07-14
15 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2017-06-15
15 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2017-06-15
15 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2017-06-15
15 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-06-15
15 (System) RFC Editor state changed to EDIT
2017-06-15
15 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-06-15
15 (System) Announcement was received by RFC Editor
2017-06-15
15 (System) IANA Action state changed to In Progress
2017-06-15
15 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-06-15
15 Amy Vezza IESG has approved the document
2017-06-15
15 Amy Vezza Closed "Approve" ballot
2017-06-15
15 Alvaro Retana IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2017-06-15
15 Alvaro Retana Ballot approval text was generated
2017-05-29
15 Mirja Kühlewind [Ballot comment]
Thanks for addressing my discuss and my comments!
2017-05-29
15 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2017-05-24
15 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-15.txt
2017-05-24
15 (System) New version approved
2017-05-24
15 (System) Request for posting confirmation emailed to previous authors: Jiazi Yi , Benoit Parrein , manet-chairs@ietf.org
2017-05-24
15 Jiazi Yi Uploaded new revision
2017-05-22
14 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2017-05-22
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-05-22
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-05-22
14 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-14.txt
2017-05-22
14 (System) New version approved
2017-05-22
14 (System) Request for posting confirmation emailed to previous authors: Jiazi Yi , Benoit Parrein , manet-chairs@ietf.org
2017-05-22
14 Jiazi Yi Uploaded new revision
2017-05-18
13 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2017-05-11
13 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2017-05-11
13 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2017-05-11
13 Min Ye Request for Telechat review by RTGDIR Completed: Has Nits. Reviewer: Loa Andersson.
2017-05-10
13 Adam Roach
[Ballot comment]
I reviewed the -12 version of this document, and had a comment I was going to make about dropping packets when no contiguous …
[Ballot comment]
I reviewed the -12 version of this document, and had a comment I was going to make about dropping packets when no contiguous path of source-routing capable routers existed between the endpoints; but when I went to quote the offending text, discovered that it has been fixed in the ink-is-still-wet -13 version of the document, dropped one day before the telechat.

To highlight for anyone else who has similarly reviewed the -12 version: the only other non-editorial change I find is that avoiding fragmentation has been demoted from normative to non-normative (see the last two paragraphs of section 8.4). My intuition is that fragmentation is sufficiently disruptive that normative language is called for here, but I don't feel strongly about it.
2017-05-10
13 Adam Roach Ballot comment text updated for Adam Roach
2017-05-10
13 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2017-05-10
13 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2017-05-10
13 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2017-05-10
13 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2017-05-10
13 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2017-05-10
13 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2017-05-10
13 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2017-05-10
13 Warren Kumari
[Ballot comment]
I am not a MANET person, and know very little about the Optimized Link State Routing Protocol, however I found this document to …
[Ballot comment]
I am not a MANET person, and know very little about the Optimized Link State Routing Protocol, however I found this document to be very vague and poorly worded in many places. At some point I simply gave up trying to understand it, but have concerns that it is not sufficiently clear for independent implementations.

I almost made these a DISCUSS, but, as I said, I'm not a OLSR person, and so I'm trusting Alvaro to know if it is deployable / implementable

Comments:
S1.1:
"The multi-path extension for OLSRv2 is expected to be revised and improved to the Standard Track," - I'm not sure an extension can be "improved to the Standard Track" - perhaps you mean that the documents will be improved and published as Standards track? Or that once implementations are more stable they will be documented on Standards Track?

"Although with existing experience, multiple paths can be obtained even with such partial information,  the calculation might be impacted, depending on the MPR selection algorithm used." - I don't understand the "with existing experience", and this sentence is a fragment. I suspect that removing " with existing experience," would make this cleaner, but I don't really understand what you are trying to say...

"Different algorithms to obtain multiple paths, other than the default Multi-path Dijkstra algorithm introduced in this specification." - this should have a reference to somewhere in the document.


5.1:
"CUTOFF_RATIO  The ratio that defines the maximum metric of a path
compared to the shortest path kept in the OLSRv2 Routing Set. For
  example, the metric to a destination is R_metric based on the
  Routing Set." - I don't understand what the last sentence is trying to say.

"CUTOFF_RATIO MUST be greater than or
      equal to 1.  Note that setting the value to 1 means looking for
      equal length paths, which may not be possible in some networks."
  -- surely setting it to 2 (or any other number) will also end up looking for paths which might not be possible?
  E.g:
        ┌──┐  ┌──┐  ┌──┐  ┌──┐       
  ┌────▶│R1│─▶│R2│─▶│R3├─▶│R4│─────┐ 
  │    └──┘  └──┘  └──┘  └──┘    ▼ 
┌───┐            ┌──┐            ┌───┐
│ S │───────────▶│R6│───────────▶│ D │
└───┘            └──┘            └───┘

"SR_HOLD_TIME_MULTIPLIER  The multiplier to calculate the minimal time
      that a SR-OLSRv2 Router Tuple SHOULD be kept in the SR-OLSRv2
      Router Set. It is the value of the Message TLV with Type =
      SOURCE_ROUTE." - this is vague / confusing. I think that you need a reference to Sec 6.1.1.


9.  Configuration Parameters
"the users of this protocol
  are also encouraged to explore different parameter setting in various network environments, and provide feedback."  -- where?


12.  "IANA Considerations
  This section adds one new Message TLV, allocated as a new Type
  Extension to an existing Message TLV."
  -- this section seems to be missing some important information, like which registry this updates Message Type 7 in.




Nits:
S1.1:

"Because the packet drop is normally bursty in a path" -- "Because packet drops on a path are normally bursty"...

"Other than general experiences including the protocol specification and interoperability with base OLSRv2 implementations, the experiences in the following aspects are highly appreciated:"
s/ experiences including/ experiences, including / (grammar)
s/ the experiences / experiences / (grammar)

"Although with existing experience,  multiple paths can be obtained even with such partial information,  the calculation might be impacted, depending on the MPR selection algorithm used."
s/Although with existing experience/Although, with existing experience/ (grammar)

"In scenarios where the length of the source routing header is critical, the loose source routing can be considered."
s/ the loose source /  loose source /

"for  example, the paths with lower metrics (i.e., higher quality) can transfer more datagrams compared to paths with higher metrics." -- nit:  many people (perhaps incorrectly) associate 'datagram' with 'UDP' - you might want to clarify (or just say packet)

S3:
"MP-OLSRv2 is designed for networks with dynamic topology by avoiding single route failure." - this makes it sound like it was *designed* by avoiding single route failure.

"in IPv4 networks the interoperability is achieved by using loose source routing header;" - in IPv4 networks interoperability is achieved using loose source routing headers;" (or "by using the loose...")

S4:
"The reactive operation is local in the router" - "local to the router"

S5.1:
"All the intermediate routers MUST be included in the source routing header, which makes the number of hops to be kept a variable."
-- I don't understand how the "the number of hops to be kept" is "a variable"; this makes it sound like I can set the number of hops to be kept. Perhaps you meant "a variable number of hops" or "the number of hops changes"?
2017-05-10
13 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2017-05-10
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2017-05-10
13 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-13.txt
2017-05-10
13 (System) New version approved
2017-05-10
13 (System) Request for posting confirmation emailed to previous authors: Jiazi Yi , Benoit Parrein , manet-chairs@ietf.org
2017-05-10
13 Jiazi Yi Uploaded new revision
2017-05-09
12 Suresh Krishnan
[Ballot comment]
I find it really strange that this document uses an experimental Routing header type codepoint (254) but requires the processing to be same …
[Ballot comment]
I find it really strange that this document uses an experimental Routing header type codepoint (254) but requires the processing to be same as the RPL Routing header (Type 3). Is there a reason things are done this way instead of just using the Type 3 header as is?
2017-05-09
12 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-05-09
12 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2017-05-09
13 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2017-05-09
12 Zhen Cao Request for Telechat review by INTDIR Completed: Ready with Issues. Reviewer: Zhen Cao. Sent review to list.
2017-05-08
12 Mirja Kühlewind
[Ballot discuss]
The following text in section 4 seems to indicate that scheduling is done on a per-packet basis:
"When there is a
  datagram …
[Ballot discuss]
The following text in section 4 seems to indicate that scheduling is done on a per-packet basis:
"When there is a
  datagram to be sent to a destination, the source router acquires a
  path from the Multi-path Routing Set (MAY be Round-Robin, or other
  scheduling algorithms)."
This seems not appropriate as e.g. TCP packets routed on links with largely different delays may suffer performance. ECMP usually hashes the 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and routes all packets belonging to the same flow on the same route. I recommend to apply the same here.

Also related is this text in section 8.4 that should explain Round-Robin on a per flow basis instead. Further this should only be an example scheduling alogirthm while text belong seems to assume that Round-Robin is always used.
"If a matching Multi-path Routing Tuple is obtained, the Path Tuples
  of the Multi-path Routing Tuple are applied to the datagrams using
  Round-robin scheduling.  For example, there are 2 path Tuples
  (Path-1, Path-2) for destination router D. A series of datagrams
  (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D.
  Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 for
  Packet 3, etc.  Other path scheduling mechanisms are also possible
  and will not impact the interoperability of different
  implementations."

Related is this text in section 8.4.:
"If datagrams without source routing header need to be forwarded using
  multiple paths (for example, based on the information of DiffServ
  Code Point [RFC2474])"
RFC2474 does not specify any application requirements on multipath use and as such the DiffServe field should not be used to determine if the flow can be routed on multiple paths. The ability to profit from multipath routing depends not only on the application and protocols used but also on the characteristics of the multipath link(s); so it's hard to make any implicit assumptions here. However, if routing would only be recommended on a per-flow basis this problem does not occur and the brackets above could be remove. Further, if routed on a per flow basis would be done, DiffServ could actually be used to decide which path to use, if e.g. one path has a lower delay, but that seem to need further discussion as well.
2017-05-08
12 Mirja Kühlewind
[Ballot comment]
Minor comments/questions:

1) section 8.4: this sentence is not clear:
"It is RECOMMENDED to use MTU sizes considering the source routing
  header …
[Ballot comment]
Minor comments/questions:

1) section 8.4: this sentence is not clear:
"It is RECOMMENDED to use MTU sizes considering the source routing
  header to avoid fragmentation."
MAYBE
"It is NOT RECOMMENDED to fragment the IP packet if the packet with the source routing header would  exceed the minimum MTU along the path. In this case source routing and therefore the additional path calculated by MP-OLSRv2 SHOULD NOT be used."

2) section 9:
"For IPv6 networks, it MUST
      be set to 0, i.e., no constraint on maximum number of hops."
Why is that?

3) Not sure why section 12.1. is there? Can this be removed?
2017-05-08
12 Mirja Kühlewind [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind
2017-05-08
12 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-05-07
12 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-05-04
12 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list.
2017-05-04
12 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for Writeup
2017-05-04
12 Alvaro Retana Ballot has been issued
2017-05-04
12 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2017-05-04
12 Alvaro Retana Created "Approve" ballot
2017-05-04
12 Alvaro Retana Ballot writeup was changed
2017-05-04
12 Alvaro Retana Changed consensus to Yes from Unknown
2017-05-04
12 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-05-02
12 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2017-05-02
12 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-manet-olsrv2-multipath-12.txt. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-manet-olsrv2-multipath-12.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Type 7 Message TLV Type Extensions subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at:

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

a new Type Extension will be added as follows:

Type Extension: [ TBD-at-registration ]
Name: SOURCE_ROUTE
Description: Indicates that the originator of the message supports source route forwarding. The value is a multiplier for calculating the hold time of SR-OLSRv2 Router Tuples.
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that this is the only action required to be completed 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. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2017-05-01
12 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Zhen Cao
2017-05-01
12 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Zhen Cao
2017-04-27
12 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2017-04-27
12 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2017-04-27
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to John Bradley
2017-04-27
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to John Bradley
2017-04-23
12 Stan Ratliff

(1) This document is intended for Experimental status. The status is appropriate,
as noted in Section 1.1. The motivation of the experiment is to improve …

(1) This document is intended for Experimental status. The status is appropriate,
as noted in Section 1.1. The motivation of the experiment is to improve data
forwarding reliability in MANET scenarios. The rationale behind the experiment
is well-documented. The RFC type is included in the page header.

(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 document describes an experimental extension of the OLSRv2 protocol
that allows for multiple disjoint paths through a MANET network for a source-
destination pair. Multiple paths can be used to increase throughput in the MANET,
provide load balancing, and improve forwarding reliability.

Working Group Summary

The document was thoroughly reviewed in the Working Group. There were
multiple Last Calls on the document - during previous Last Calls, issues were
discovered, discussed, and resolved. The working group reached consensus
with the extension, and no issues remain.

Document Quality

There are three open-source multi-path OLSRv2 implementations available
for the purpose of proof-of-concept, network simulation, and field test.
Vendors have not indicated plans to implement on a commercial level, hence
part of rationale for making this document Experimental. The document was
extensively reviewed by Christopher Dearlove; those reviews resulted in
issues identified and resolved. Mr. Dearlove’s reviews merit special mention.
No MIB Doctor or other external reviews were sought.


Personnel

  Stan Ratliff (sratliff@idirect.net) is the Document Shepherd. Alvaro Retana
(aretana@cisco.com) is the Responsible Area Director.

Review

The Document Shepherd has performed a cursory review of the document.
The shepherd’s review was not extensive, due to the thoroughness of
other reviews performed in the WG. The document is ready for publication.

Concerns

The Shepherd does not have any concern about the thoroughness of
reviews performed.


Additional Reviews
In the Shepherd’s opinion, additional reviews are not required.

Additional Concerns
None.

IPR Concerns
None. Each author has confirmed conformance with BCP 78/79. There are no
IPR disclosures on the document.

IPR Disclosures
Please see above No IPR disclosures have been filed.

WG Consensus
The document represents strong concurrence of a few individuals, with the
majority of the WG silent. 

Potential Appeals
No appeals have been considered or threatened. No extreme discontent has
been registered.

ID Nits
No ID Nits were found.

Formal Document Review
There was no formal review (e.g. MIB Doctor, URI review) required, as
the document does not effect these areas.

References
All references within the document have been identified as
either normative or informative.

All normative references are to existing published RFCs.

There are no downward normative references.

The document does not change the status of any existing RFCs.

The Shepherd has reviewed the IANA considerations section - the
document requests one (1) entry be allocated as a new Type
Extension to an existing Message TLV. This allocation will be in
registry specified in [RFC5444]. The text for Table 2 in the document
is reasonably clear as to the request.

No new registries are required; the addition to the existing registry calls
for expert review as indicated in [RFC5444].

No formal language sections exist; therefore, no additional automated
reviews have been performed.
2017-04-21
12 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Charles Perkins
2017-04-21
12 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Charles Perkins
2017-04-21
12 Min Ye Request for Telechat review by RTGDIR is assigned to Loa Andersson
2017-04-21
12 Min Ye Request for Telechat review by RTGDIR is assigned to Loa Andersson
2017-04-21
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2017-04-21
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2017-04-20
12 Alvaro Retana Requested Telechat review by RTGDIR
2017-04-20
12 Alvaro Retana Requested Telechat review by INTDIR
2017-04-20
12 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-04-20
12 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: sratliff@idirect.net, Stan Ratliff , manet-chairs@ietf.org, manet@ietf.org, aretana@cisco.com, …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: sratliff@idirect.net, Stan Ratliff , manet-chairs@ietf.org, manet@ietf.org, aretana@cisco.com, draft-ietf-manet-olsrv2-multipath@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Multi-path 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-path 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 2017-05-04. 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 document specifies a multi-path extension for the Optimized Link
  State Routing Protocol version 2 (OLSRv2) to discover multiple
  disjoint paths, so as to improve reliability of the OLSRv2 protocol.
  The interoperability with OLSRv2 is retained.




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

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


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




2017-04-20
12 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2017-04-20
12 Alvaro Retana Placed on agenda for telechat - 2017-05-11
2017-04-20
12 Alvaro Retana Last call was requested
2017-04-20
12 Alvaro Retana Ballot approval text was generated
2017-04-20
12 Alvaro Retana Ballot writeup was generated
2017-04-20
12 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2017-04-20
12 Alvaro Retana Last call announcement was generated
2017-04-19
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-04-19
12 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-12.txt
2017-04-19
12 (System) New version approved
2017-04-19
12 (System) Request for posting confirmation emailed to previous authors: Jiazi Yi , Benoit Parrein , manet-chairs@ietf.org
2017-04-19
12 Jiazi Yi Uploaded new revision
2017-04-03
11 Alvaro Retana
=== AD Review of draft-ietf-manet-olsrv2-multipath-11 ===

Dear authors:

I just finished reading this document.  In general, I think it is relatively straight forward, but it …
=== AD Review of draft-ietf-manet-olsrv2-multipath-11 ===

Dear authors:

I just finished reading this document.  In general, I think it is relatively straight forward, but it needs several clarifications (see below).  I will start the IETF Last Call when my Major comments have been addressed in a new version.

As other people (specially the INT Directorate) review this document, more specific language related to the use of RFC6554 may be needed.  I’m inclined to go forward with the document as is (pending the comments below) because it is Experimental.  We can make further updates if needed.

Thanks!

Alvaro.


Major:

M1. Section 3. (Applicability Statement): “It is interoperable with OLSRv2 implementations that do not have this extension.”  I don’t think that statement is true.  For example, how does a non-MP-OLSRv2 router handle a packet with the RFC6554 header in it?  IOW, strict source routing requires all the routers in the path to support the extension.  I think more clarity and specificity is needed.


M2. MAX_SRC_HOPS .  Both Section 5.1. (Router Parameters) and Section 9. (Configuration Parameters) say that “For IPv6 networks, it MUST be set to 0, i.e., no constraint on maximum number of hops.”  What about potential MTU/fragmentation issues?  RFC6554 (in Section 4.1. (Generating Source Routing Headers)) does talk about a maximum path length.


M3. Section 6.1.1. (SOURCE_ROUTE TLV) says that each HELLO/TC message “MUST have exactly one SOURCE_ROUTE TLV”.  I read this as meaning two things: (1) every HELLO/TC must have a SOURCE_ROUTE TLV, and (2) there must be at most one SOURCE_ROUTE TLV.  What happens if either of these conditions are not met?  RFC7181 describes conditions under which a message should be considered invalid for processing (16.3, for example) – given the language used in this section, I would expect something similar in this document (to enhance what is already in RFC7181).

M3.1. [minor] Section 6.1.1. (SOURCE_ROUTE TLV). “MP-OLSRv2 Routing Process, or an OLSRv2 Routing Process that supports source-route forwarding.”  Specially for IPv6, can you identify a sub-set of this specification that would be implemented by “an OLSRv2 Routing Process that supports source-route forwarding”?  I’m wondering whether that distinction even needs to be made or if you can just assume that a manet router that supports RFC6554 also supports this document (it does, if it originates the new TLV).

M3.2. This section also says that “an OLSRv2 Routing Process MAY have one SOURCE_ROUTE TLV, if the OLSRv2 Routing Process supports source-route forwarding, and is willing to join the source route generated by other MP-OLSRv2 Routing Processes.”  If the 2 conditions are met, doesn’t the text become “MUST have exactly one SOURCE_ROUTE TLV”?  Just pointing out that the differentiation may not be needed…and that the language is not consistent (see above).

M3.3. “The existence of SOURCE_ROUTE TLV MUST be consistent for a specific OLSRv2 Routing Process”  Simplify by adding discard conditions. (See M3 above)


M4. Section 6.2.2. (Source Routing Header in IPv6) says that the routing header from RFC6554 is used with IPv6 Routing Type 254 (experimental).  Why?  I’m asking because RFC4727 says that the experimental values “MUST NOT be shipped as defaults in implementations” – not only do implementations exist, but the purpose of this Experimental document is to gather experience form real deployments.  Short of asking for a new Routing Type, why isn’t the one already assigned to RFC6554 used?


M5. Section 8.1. (HELLO and TC Message Generation).  “The TC message generation based on SR_TC_INTERVAL does not replace the ordinary TC message generation specified in [RFC7181]…The TC generation based on SR_TC_INTERVAL serves for those routers to advertise SOURCE_ROUTE TLV so that the other routers can be aware of the source-route enabled routers so as to be used as destinations of multipath routing.  The SR_TC_INTERVAL is set to a longer value than TC_INTERVAL.”  This text says that there are two intervals at which an MP-OLSRv2 router sends TCs, but that only at SR_TC_INTERVAL will the SOURCE_ROUTE TLV be included, is that correct?  If so, then how does a receiver reconcile that with the requirement in 6.1.1 (and in this section) for “Every HELLO or TC message generated by a MP-OLSRv2 Routing Process MUST have exactly one SOURCE_ROUTE TLV.”??  IOW, it looks like that requirement can’t be met unless all the TCs (including the ones generated every TC_INTERVAL) include the SOURCE_ROUTING TLV.


M6. Section 8.3. (MPR Selection): “MP-OLSR routers SHOULD be preferred as routing MPRs.”  When would it be ok for MP-OLSR routers not to be preferred?  IOW, why is “MUST” not used?


M7. If the Multi-path Routing Set is maintained reactively, what should be done with the datagram that triggered the calculation (while it is being done)?  I’m assuming that it should be buffered somewhere and then forwarded, right?  I’m also assuming that any other datagrams to the same destination that are received while the calculation is happening should also be buffered, true?  Is there a maximum time that this buffering should be maintained?  Is there a maximum expected size?  Maybe these are questions that you may want to answer through the experiment.  Also, buffering some datagrams may open an attack vector – worth mentioning in the Security Considerations section.

M7.1. [minor] Section 4. (Protocol Overview and Functioning): “The reactive operation is local in the router and no message transmission delay is introduced.”  I think you may be referring to control plane messages, but it sounds as if there was no delay in the propagation of the data plane messages – which by definition need to somehow be held while the reactive calculation is completed.  Please clarify.


M8. Section 8.5.2. (Multi-path Dijkstra Algorithm) says that “Using different multi-path algorithms will not impact the interoperability.”  Using different algorithms in a network may not impact interoperability (as the packets on the wire will be understood by all), but it can lead to routing loops.  Please clarify.

M8.1. Section 8.5.2. (Multi-path Dijkstra Algorithm) describes the MP algorithm as two incremental functions at “step i” of the original Dijkstra algorithm.  While the algorithm may be well known, please add a reference so that there is no confusion as to what “step i” is.


M9. The Security Considerations of RFC6554 say that the extension is to be used only inside an RPL domain and that “RPL routers MUST drop datagrams entering or exiting a RPL routing domain that contain an SRH in the IPv6 Extension headers.”  This document does mention that “the source routing header is used only in the current routing domain”, but it doesn’t explicitly talk about what should be done with datagrams that contain the source routing headers as they enter/leave the domain.  Please include some text similar to the one in RFC6554.  Pointing to the Security Considerations of RFC6554 would also be a good idea (to capture ICMP attacks, and whatever else is mentioned there).


M10. IANA Considerations.  Sections 12.1. (Expert Review: Evaluation Guidelines) and 12.3. (Routing Type) are not needed as this document is not specifying any new space that requires DE review (the assignment should be done under DE review, but that is specified elsewhere), and the Routing Type is already assigned by IANA.



Minor:

P1. Please include a reference for “erasure coding”.

P2. Loose vs Strict Source Routing.  It caught my attention that the IPv4/IPv6 source routing modes are not the same – why is that?  I note that RFC791 does support strict source routing.  RFC6554 doesn’t support loose source routing, but other extensions do (draft-ietf-6man-segment-routing-header, for example, can support both loose and strict modes).  Given that this document is Experimental, I don’t think it is a show stopper, but consistency would be nice.  There’s also the opportunity to experiment further.

P3. You mention round-robin and weighted scheduling for path selection (in 1.1).  What about flow-based (keep all the packets in a flow on a single path)?  I’m wondering about this because disjoint paths may result in significant performance characteristic differences, and path stability (as much as possible) may be important in some cases.

P4. Section 1.1 mentions the potential use of “Different algorithms to obtain multiple paths”.  The rtgwg WG has done a lot of work on finding alternate paths (from LFA all the way to MRT) in the context of fast reroute – these alternate paths can obviously be used for traffic forwarding under normal conditions (not just for repair).  I’m wondering why those other mechanisms were not used here?  Where they even considered?  [IOW, it’s always nice to use other IETF-developed technology.]

P5. Please define SR-OLSRv2 in the Terminology section.

P6. The document doesn’t explain how SR_HOLD_TIME_MULTIPLIER should be used.  Later I found (in 8.2) that “source route hold time multiplier” is defined as “the value of a Message TLV with Type = SOURCE_ROUTE“, which is exactly what SR_HOLD_TIME_MULTIPLIER is.  Suggestion: to avoid confusion and be consistent, eliminate the definition of "source route hold time multiplier" and simply use SR_HOLD_TIME_MULTIPLIER.

P7. Section 8.2. (HELLO and TC Message Processing) defines "validity time".  I don’t think this is necessary as it has the same meaning as in RFC7181, right?  If so, then a reference to that (in the SR_time formula) should be enough.  Otherwise, you at least need a reference to RFC5497.  I’m making this comment because it is easier/cleaner to use definitions by reference, than risk not using the exact same text and have the specifications potentially diverge over time.

P8. The definition of the Multi-path Routing Tuple in 8.5.1. (Requirements of Multi-path Calculation) is not (exactly) the same as in 7.2. (Multi-path Routing Set).  Suggestion: put a reference to 7.1 in 8.5.1.

P9. References:
- RFC6982 has been obsoleted by RFC7942.
- s/RFC2460/draft-ietf-6man-rfc2460bis



Nits:

N1. s/original OLSRv2/base OLSRv2

N2. In Section 5.1, please include a forward reference to Section 9…and in Section 6.1.1…and anywhere else the parameters are defined.

N3. s/existed/existing

N4. s/MP-OLSR/MP-OLSRv2

N5. In 8.4 s/they are/there are

N6. s/the the/the
2017-04-03
11 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-01-25
11 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2017-01-25
11 Alvaro Retana Notification list changed to "Stan Ratliff" <sratliff@idirect.net>, aretana@cisco.com from "Stan Ratliff" <sratliff@idirect.net>
2016-11-30
11 Stan Ratliff

(1) This document is intended for Experimental status. The status is appropriate,
as noted in Section 1.1. The motivation of the experiment is to improve …

(1) This document is intended for Experimental status. The status is appropriate,
as noted in Section 1.1. The motivation of the experiment is to improve data
forwarding reliability in MANET scenarios. The rationale behind the experiment
is well-documented. The RFC type is included in the page header.

(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 document describes an experimental extension of the OLSRv2 protocol
that allows for multiple disjoint paths through a MANET network for a source-
destination pair. Multiple paths can be used to increase throughput in the MANET,
provide load balancing, and improve forwarding reliability.

Working Group Summary

The document was thoroughly reviewed in the Working Group. There were
multiple Last Calls on the document - during previous Last Calls, issues were
discovered, discussed, and resolved. The working group reached consensus
with the extension, and no issues remain.

Document Quality

  There are no known implementations of the extension. Vendors have
not indicated plans to implement on a commercial level, hence part of
rationale for making this document Experimental. The document was
extensively reviewed by Christopher Dearlove; those reviews resulted in
issues identified and resolved. Mr. Dearlove’s reviews merit special mention.
No MIB Doctor or other external reviews were sought.

Personnel

  Stan Ratliff (sratliff@idirect.net) is the Document Shepherd. Alvaro Retana
(aretana@cisco.com) is the Responsible Area Director.

Review

The Document Shepherd has performed a cursory review of the document.
The shepherd’s review was not extensive, due to the thoroughness of
other reviews performed in the WG. The document is ready for publication.

Concerns

The Shepherd does not have any concern about the thoroughness of
reviews performed.


Additional Reviews
In the Shepherd’s opinion, additional reviews are not required.

Additional Concerns
None.

IPR Concerns
None. Each author has confirmed conformance with BCP 78/79. There are no
IPR disclosures on the document.

IPR Disclosures
Please see above No IPR disclosures have been filed.

WG Consensus
The document represents strong concurrence of a few individuals, with the
majority of the WG silent. 

Potential Appeals
No appeals have been considered or threatened. No extreme discontent has
been registered.

ID Nits
No ID Nits were found.

Formal Document Review
There was no formal review (e.g. MIB Doctor, URI review) required, as
the document does not effect these areas.

References
All references within the document have been identified as
either normative or informative.

All normative references are to existing published RFCs.

There are no downward normative references.

The document does not change the status of any existing RFCs.

The Shepherd has reviewed the IANA considerations section - the
document requests one (1) entry be allocated as a new Type
Extension to an existing Message TLV. This allocation will be in
registry specified in [RFC5444]. The text for Table 2 in the document
is reasonably clear as to the request.

No new registries are required; the addition to the existing registry calls
for expert review as indicated in [RFC5444].

No formal language sections exist; therefore, no additional automated
reviews have been performed.
2016-11-30
11 Stan Ratliff Responsible AD changed to Alvaro Retana
2016-11-30
11 Stan Ratliff IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2016-11-30
11 Stan Ratliff IESG state changed to Publication Requested
2016-11-30
11 Stan Ratliff IESG process started in state Publication Requested
2016-11-30
11 Stan Ratliff Tag Doc Shepherd Follow-up Underway cleared.
2016-11-30
11 Stan Ratliff Changed document writeup
2016-11-30
11 Stan Ratliff Notification list changed to "Stan Ratliff" <sratliff@idirect.net>
2016-11-30
11 Stan Ratliff Document shepherd changed to Stan Ratliff
2016-10-23
11 Stan Ratliff Tag Doc Shepherd Follow-up Underway set. Tag Other - see Comment Log cleared.
2016-10-23
11 Stan Ratliff IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2016-07-25
11 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-11.txt
2016-07-05
10 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-10.txt
2016-06-08
09 Stan Ratliff 1 week Last Call, ending on June 15.
2016-06-08
09 Stan Ratliff Tag Other - see Comment Log set. Tags Revised I-D Needed - Issue raised by WG, Revised I-D Needed - Issue raised by WGLC cleared.
2016-06-08
09 Stan Ratliff IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead
2016-06-08
09 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-09.txt
2016-05-30
08 Justin Dean Looking to have comments made by Chris Dearlove addressed in an updated draft.
2016-05-30
08 Justin Dean Tag Revised I-D Needed - Issue raised by WG set.
2016-05-30
08 Justin Dean IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2016-05-09
08 Justin Dean IETF WG state changed to In WG Last Call from WG Document
2016-04-27
08 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-08.txt
2016-01-20
07 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-07.txt
2015-10-20
06 Stan Ratliff Tag Revised I-D Needed - Issue raised by WGLC set.
2015-10-20
06 Stan Ratliff IETF WG state changed to WG Document from Waiting for WG Chair Go-Ahead
2015-10-19
06 Ulrich Herberg IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2015-10-02
06 Stan Ratliff IETF WG state changed to In WG Last Call from WG Document
2015-07-21
06 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-06.txt
2015-07-02
05 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-05.txt
2015-06-29
04 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-04.txt
2015-05-25
03 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-03.txt
2014-10-27
02 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-02.txt
2014-09-15
01 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-01.txt
2014-08-15
00 Ulrich Herberg Intended Status changed to Experimental from None
2014-08-15
00 Ulrich Herberg This document now replaces draft-yi-manet-olsrv2-multipath instead of None
2014-08-15
00 Jiazi Yi New version available: draft-ietf-manet-olsrv2-multipath-00.txt