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 |