The Optimized Link State Routing Protocol Version 2
draft-ietf-manet-olsrv2-19
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-03-31
|
19 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-03-19
|
19 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-02-26
|
19 | (System) | RFC Editor state changed to RFC-EDITOR from IESG |
2014-02-25
|
19 | (System) | RFC Editor state changed to IESG from AUTH |
2014-01-14
|
19 | (System) | RFC Editor state changed to AUTH from EDIT |
2013-12-02
|
19 | (System) | RFC Editor state changed to EDIT from MISSREF |
2013-04-17
|
19 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-04-17
|
19 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-04-14
|
19 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-04-09
|
19 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2013-04-05
|
19 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-04-03
|
19 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-04-02
|
19 | (System) | RFC Editor state changed to MISSREF |
2013-04-02
|
19 | (System) | Announcement was received by RFC Editor |
2013-04-02
|
19 | (System) | IANA Action state changed to In Progress |
2013-04-02
|
19 | Cindy Morgan | State changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2013-04-02
|
19 | Cindy Morgan | IESG has approved the document |
2013-04-02
|
19 | Cindy Morgan | Closed "Approve" ballot |
2013-04-02
|
19 | Cindy Morgan | Ballot approval text was generated |
2013-04-01
|
19 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-03-29
|
19 | Adrian Farrel | Changed consensus to Yes from Unknown |
2013-03-29
|
19 | Adrian Farrel | Ballot approval text was generated |
2013-03-29
|
19 | Adrian Farrel | Ballot writeup was changed |
2013-03-23
|
19 | Stephen Farrell | [Ballot comment] Thanks for addressing my discuss points and later comments. |
2013-03-23
|
19 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2013-03-23
|
19 | Ulrich Herberg | New version available: draft-ietf-manet-olsrv2-19.txt |
2013-03-19
|
18 | Stephen Farrell | [Ballot discuss] I'm going to clear this discuss as soon as my co-AD has had a chance to check he's ok with the argument that … [Ballot discuss] I'm going to clear this discuss as soon as my co-AD has had a chance to check he's ok with the argument that BCP107 doesn't apply here. |
2013-03-19
|
18 | Stephen Farrell | [Ballot comment] draft-ietf-manet-olsrv2-18 Just reviewing section 23 and associated docs; these are non-blocking comments - 23.1, 2nd para: "digital signature" is maybe a bad example … [Ballot comment] draft-ietf-manet-olsrv2-18 Just reviewing section 23 and associated docs; these are non-blocking comments - 23.1, 2nd para: "digital signature" is maybe a bad example since you're doing MACing (same comment about other places you say "digital signature" since a MAC is not one of those) - 23.2, maybe s/recommended/RECOMMENDED/ if you mean it in 2119 terms or s/recommended/highly useful/ if you don't - 23.2, saying a timestamp is "required" is maybe not quite accurate as other anti-replay mechanisms could be used in principle, maybe you mean a timestamp is a useful mechanism for that if you have sufficiently synchronised clocks - 23.2, this text might be confusing "In general, digital signatures and other required security information may be transmitted within the HELLO and TC messages, or within a packet header, using the TLV mechanism. Either option permits "secured" and "unsecured" routers to coexist in the same network, if desired." The confusion might arise due to the use of "may" (vs 2119 MAY) and where you elsewhere (in draft-herberg-manet-nhdp-olsrv2-sec) say that a bad or missing ICV means DROP. - 23.2, I think that 6622bis really ought be a normative reference for this. It is already via transitive inclusion as a normative ref to draft-herberg-manet-nhdp-olsrv2-sec, so won't be any more blocking that it already is. - 23.2, ICVs are, in general, not signatures. - 23.2, are we still saying that its ok to not reject a message with a bad ICV? I think you ought say that such messages must be rejected. (Where you currently say "can be used as a reason to reject") - 23.2, last para of p85, "must specify how to" is that a 2119 MUST? seems like it might be. And you're a bit ambiguous on rejection - it says "must specify how to... and to reject.." does that mean you MUST reject messages with bad ICVs or that you MUST specify how to reject messages with bad ICVs? (Where bad includes unverifiable.) - 23.2 same para typo s/their purpose/the purpose/ - 23.5 "and a single shared secret key" seems wrong, it'd work fine if all nodes had the same N shared secrets, I think you want to say "and manually managed shared secrets" - 23.5 last para, the SHOULDs there are a bit odd in 2119 terms, I'd say for the first one you want to say "[OLSRv2-integrity] SHOULD be used" and for the second one just say that mechanisms with re-keying would be needed but are not yet specified. - 23.6 1st para, "lend themselves" isn't right, you want to be saying what's needed and what's not. - 23.6 "uses only one key" is wrong again, you just need to say "uses only a small set of manually managed shared secrets" - 23.6 multicast argument, I think if you could argue that multicast key management doesn't match the baseline use-cases this would be better. I don't know if that's the case or not. - 23.6 "not kerberos" argument - this is nothing to do with bandwidth (kerberos doesn't use much at all) but about availability of a KDC. ------------- draft-herberg-manet-nhdp-olsrv2-sec-02 (this is not a full review, just a quick check that it seems ok with the olsrv2 draft above, I'll do a full review when it comes back to the IESG.) - abstract, "single shared secret" is wrong since you can handle >1 (same comment elsewhere) That'll be a DISCUSS when this comes back if you don't want to fix it. (But I think that 6622 does support key ids so this is a trivial fix.) - the diagram on p4 implies that a bad or unverifiable ICV means that packet/message is dropped (just to contrast with the above comment where you said you can mix and match unsecure and secure in the same n/w) - "MUST use different algorithms" seems too restrictive, don't you want to say MUST use a different alg or key id? ------------- draft-herberg-manet-rfc6622-bis I didn't check this one, but the diff with 6622 looks ok on first glance. |
2013-03-19
|
18 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2013-03-18
|
18 | Christopher Dearlove | New version available: draft-ietf-manet-olsrv2-18.txt |
2012-10-16
|
17 | Martin Stiemerling | [Ballot comment] Thank you for addressing my DISCUSS. |
2012-10-16
|
17 | Martin Stiemerling | [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss |
2012-10-14
|
17 | Stephen Farrell | [Ballot discuss] (Just updated to note -17 doesn't address the discuss yet) Why are "guidelines" for securing OLSRv2 sufficient and how does that meet BCPs … [Ballot discuss] (Just updated to note -17 doesn't address the discuss yet) Why are "guidelines" for securing OLSRv2 sufficient and how does that meet BCPs 61 and 107? ROLL has been stuck on this due to punting on the defintion of key management mechanisms and lots of work is having to be done to retro-fit security for routing in sidr and karp so why is it ok for us to perhaps make the same mistake (punting on security for routing) again? Is there even a proof-of-concept that OLSRv2 can be used with RFC6622 TLVs to produce a "secure" solution for routing in at least some MANETs? If there were at some "SHOUL implement" statements about some flavour of use of RFC6622 and where an accompanying key managment solution actually exists then this might be fine, but as-is, it looks like nobody is going to get interop for security without more work being done, and experiene with ROLL seems to show that getting that done can be hard to impossible. |
2012-10-14
|
17 | Stephen Farrell | Ballot discuss text updated for Stephen Farrell |
2012-10-14
|
17 | Barry Leiba | [Ballot comment] This is a well written, clear document, and I'm happy to put a YES ballot on it. The -17 version resolves all the … [Ballot comment] This is a well written, clear document, and I'm happy to put a YES ballot on it. The -17 version resolves all the questions I had, and thanks for addressing them. |
2012-10-14
|
17 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to Yes from Discuss |
2012-10-14
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-10-14
|
17 | Thomas Clausen | New version available: draft-ietf-manet-olsrv2-17.txt |
2012-10-11
|
16 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-10-11
|
16 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Tom Yu. |
2012-10-11
|
16 | Benoît Claise | [Ballot comment] No objection to the publication of this document. However, I would appreciate an answer/discussion on the following two points. 1. When reading about … [Ballot comment] No objection to the publication of this document. However, I would appreciate an answer/discussion on the following two points. 1. When reading about MPRs, the first question I asked myself was: why two distinct devices for the two MPR types (flooding and routing). I found some information in the draft: When possible (in particular if using a hop count metric) the same routers may be picked as both flooding MPRs and routing MPRs. And in section 18.1: Each router MAY select its flooding and routing MPRs independently from each other, or coordinate its selections. However, the draft doesn't really explain the pros/cons of one versus two devices. At first glance, I was thinking: "why do I want to have two different devices in dynamic topology: it simply going to add a level of complexity?". Maybe there are some other cases where link speed is involved. A few words about this would be appreciated. 2. More of clarifying question to start with. Not sure if there is a problem. Since "OLSRv2 retains the same basic mechanisms and algorithms, enhanced by the ability to use a link metric other than hop count in the selection of shortest routes", I was wondering about the metric semantic. Looking at this sentence: "This specification does not define the nature of the link metric. However, this specification allows, through use of the type extension of a defined Address Block TLV, for link metrics with specific meanings to be defined and either allocated by IANA or privately used." I was expecting an IANA registry with the different metric types. What do I miss? Or "Table 3: LINK_METRIC TLV definition" is really a placeholder for a metric, and we have no idea about the semantic? If this is the case, don't we run the risk that parts of the network have different configured metric types (hop count versus OSPF-like cost). Disclaimer 1: I'm not a MANET expert Disclaimer 2: I glanced through some parts of the draft. |
2012-10-11
|
16 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-10-11
|
16 | Stephen Farrell | [Ballot discuss] Why are "guidelines" for securing OLSRv2 sufficient and how does that meet BCPs 61 and 107? ROLL has been stuck on this due … [Ballot discuss] Why are "guidelines" for securing OLSRv2 sufficient and how does that meet BCPs 61 and 107? ROLL has been stuck on this due to punting on the defintion of key management mechanisms and lots of work is having to be done to retro-fit security for routing in sidr and karp so why is it ok for us to perhaps make the same mistake (punting on security for routing) again? Is there even a proof-of-concept that OLSRv2 can be used with RFC6622 TLVs to produce a "secure" solution for routing in at least some MANETs? If there were at some "SHOUL implement" statements about some flavour of use of RFC6622 and where an accompanying key managment solution actually exists then this might be fine, but as-is, it looks like nobody is going to get interop for security without more work being done, and experiene with ROLL seems to show that getting that done can be hard to impossible. |
2012-10-11
|
16 | Stephen Farrell | Ballot discuss text updated for Stephen Farrell |
2012-10-11
|
16 | Stephen Farrell | [Ballot discuss] Why are "guidelines" for securing OLSRv2 sufficient and how does that meet BCPs 61 and 107? ROLL has been stuck on this due … [Ballot discuss] Why are "guidelines" for securing OLSRv2 sufficient and how does that meet BCPs 61 and 107? ROLL has been stuck on this due to punting on the defintion of key management mechanisms and lots of work is having to be done to retro-fit security for routing in sidr and karp so why is it ok for us to perhaps make the same mistake (punting on security for routing) again? Is there even a proof-of-concept that OLSRv2 can be used with RFC6622 TLVs to produce a "secure" solution for routing in at least some MANETs? If there were at some "SHOUL implement" statements about some flavour of use of RFC6622 and where an accompanying key managment solution actually exists then this might be fine, but as-is, it looks like nobody is going to get interop for security without more work being done, and experiene with ROLL seems to show that getting that done can be hard to impossible. |
2012-10-11
|
16 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2012-10-11
|
16 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-10-10
|
16 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-10-10
|
16 | Pete Resnick | [Ballot comment] Throughout the document, there are references to assorted "time" values, but nowhere that I can find is there an explicit granularity requirement. Is … [Ballot comment] Throughout the document, there are references to assorted "time" values, but nowhere that I can find is there an explicit granularity requirement. Is the granularity documented elsewhere and therefore so obviously understood to be seconds by the MANET community that it is not worth mentioning in this document? If not, it might be worth mentioning. I find all of the MUSTs and MAYs in the definitions of section 2 weird. For example: A router MUST be able to distinguish a routable address from a non-routable address by direct inspection of the network address, based on global scope address allocations by IANA and/or administrative configuration. Broadcast and multicast addresses, and addresses which are limited in scope to less than the entire MANET, MUST NOT be considered as routable addresses. Anycast addresses may be considered as routable addresses. I'm trying to figure out what it would mean for a router to be unable to distinguish routable from non-routable addresses. What are the interoperability considerations here? "Considering broadcast and multicast addresses as routable" seems problematic in general, not just for this protocol. Aren't you simply saying that routers that implement this protocol will need to distinguish routable and non-routable addresses? Either way, why is this protocol instruction in the definitions section? Sounds like it should be in a "Basic Requirements" section if it needs to be a protocol requirement. 5.1 TC messages and HELLO messages [RFC6130] MUST, in a given MANET, both be using the same of either of IP or UDP, in order that it is... Don't you mean, "TC messages and HELLO messages [RFC6130] will all use either IP or UDP in a given MANET in order that it be..."? I don't see what the MUST is doing in this sentence. The sentence is a statement of fact, not a protocol directive. 16.3.3.1 - 16.3.3.4: "The router MUST update its...". I always find MUSTs of this sort weird. It's not really a protocol requirement to update the internal state of the router. It's the behavior of the router that's the protocol requirement. These probably simply don't need MUSTs, though perhaps rewording is in order. But these sorts of MUSTs seem to appear throughout sections 7 through 12 anyway (requirements for local implementation of information bases), so perhaps this ship has sailed long ago in the MANET work. |
2012-10-10
|
16 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-10-10
|
16 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-10-10
|
16 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-10-10
|
16 | Martin Stiemerling | [Ballot discuss] This is a good document and I do not object in principle to the publication of the document. However, there is a broader … [Ballot discuss] This is a good document and I do not object in principle to the publication of the document. However, there is a broader question about congestion potentially caused by this which isn't addressed in the document, especially not since it is on the Standards Track. Everything in OLSRv2 about congestion control is copied from RFC 3626. RFC 3626 is Experimental, so far so good. 1) Is there any guidance on congestion avoidance and control that was learned from deployments of RFC 3626? 2) The timers for the Message Interval Parameters (TC_INTERVAL and TC_MIN_INTERVAL) are fixed to o TC_INTERVAL := 5 seconds o TC_MIN_INTERVAL := TC_INTERVAL/4 Is there any recommendation to change the values for very low bandwidth links? Such as being used in MANETS? The point is that on very low bandwidth links the messages carrying the OSLRv2 information could already take most of the share of the available bandwidth. 3) What would be the recommendation to an OLSRv2 instance experiencing congestion? And the resulting effects for the routing. |
2012-10-10
|
16 | Martin Stiemerling | [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling |
2012-10-10
|
16 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-10-09
|
16 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-10-08
|
16 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-10-07
|
16 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-10-07
|
16 | Barry Leiba | [Ballot discuss] This is a very well written, clear document. Despite its length (or perhaps because of it), it was very easy to understand, even … [Ballot discuss] This is a very well written, clear document. Despite its length (or perhaps because of it), it was very easy to understand, even for an Apps guy. I'll be happy to enter a "yes" ballot after discussing one concern: -- Section 16.3.1 -- A router MAY recognize additional reasons for identifying that a message is invalid. An invalid message MUST be silently discarded, without updating the router's Information Bases. Does this cause any interoperability artifacts? It seems to be saying that I can consider a message invalid for any reason I decide to come up with, and therefore silently discard any message for basically any reason. Is that right? If there are some criteria or limitations relating to those additional reasons, it'd be helpful to give them. If it really is at a whim, how does that work? (I see that Section 23.2 suggests some additional reasons, but this section just seems to leave it entirely open.) I understand that this might just be a quality of implementation issue: if your router picks bogus reasons for discarding otherwise-valid messages, it'll suck and no one will use it. In that case, is there a way that such a rogue router could be used to attack or DoS a MANET? |
2012-10-07
|
16 | Barry Leiba | [Ballot comment] I also have a few non-blocking comments that I'd like you to consider, and to feel free to chat with me about. It … [Ballot comment] I also have a few non-blocking comments that I'd like you to consider, and to feel free to chat with me about. It seems odd to me that this document doesn't Obsolete 3626. Can you tell me why it doesn't? Is it expected that people will continue to experiment with or otherwise use OLSR (v1) after OLSRv2 is published as a Proposed Standard? -- Section 3 -- This isn't really an Applicability Statement, at least not in the sense described in RFC 2026, Section 3.2. This is a list of features of this protocol. It's a fine section to have in here, but it doesn't talk about how this protocol can be used in any particular situations. -- Section 5.1 -- This protocol specifies TC messages, which are included in packets as defined by [RFC5444]. These packets MAY be sent either using the "manet" protocol number or the "manet" UDP well-known port number, as specified in [RFC5498]. I don't think this is the right use of "MAY". As I read it, it says that use of either the protocol number or the port number is entirely optional. You might well do neither, as you please. Somehow, I don't think that's what you mean (though I've been wrong before, so just tell me so). I think you really want a "MUST" here: if those are the only two choices, and you MUST pick one or the other, then MUST is your guy. The next paragraph after that is a little malformed, "the same of either of" is very awkward. I think you mean this, yes?: NEW TC messages and HELLO messages [RFC6130] MUST, in a given MANET, either both be using IP or both be using UDP, in order that it is -- Section 5.4.3 -- o If TLVs with Type = INTERVAL_TIME, as defined in [RFC5497], are included in TC messages, then TC_INTERVAL MUST be representable as described in [RFC5497]. Two questions on this: 1. As described *where* in RFC 5497. I think it's Section 5, but I had to look around. Please say that ("as described in [RFC5497], Section 5," or wherever). 2. TC_INTERVAL is a number -- what does it mean for it *not* to be "representABLE" as described there? Do you mean that it must be "representED" that way? Or something else? (1) and (2) also apply to T_HOLD_TIME in 5.4.4. -- Section 5.4.8 -- A MANET using this protocol with too many routers having either willingness value equal to WILL_NEVER will not function; it MUST be ensured, by administrative or other means, that this does not happen. Well said. But is there any guidance that will help determine what "too many" means? Any way to recommend (non-normatively) some percentage of routers that need to be willing to be selected as flooding and routing MPRs? Or if not percentage, then at least some other quantitative guidance? The following constraints apply to these parameters: o WILL_FLOODING >= WILL_NEVER o WILL_FLOODING <= WILL_ALWAYS o WILL_ROUTING >= WILL_NEVER o WILL_ROUTING <= WILL_ALWAYS This is a take-it-or-leave-it comment: we often use this mechanism to indicate this sort of "this value must be in between these other two" relationship, and I think it makes the relationship even clearer: The following constraints apply to these parameters: o WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS o WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS This also could apply to 5.4.3: The following constraints apply to these parameters: o TC_INTERVAL > 0 o 0 <= TC_MIN_INTERVAL <= TC_INTERVAL -- Section 6.1 -- Link metrics are reported in messages using a compressed representation that occupies 12 bits, a 4 bit field and an 8 bit field. This sounds like it's three things. I think you mean this: NEW Link metrics are reported in messages using a compressed representation that occupies 12 bits, comprising a 4 bit field and an 8 bit field. -- Section 7.2 -- The Local Attached Network Set is not modified by this protocol. This protocol MAY respond to changes to the Local Attached Network Set, which MUST reflect corresponding changes in the router's status. The last line invites imprecision and uncertain interpretation as to the antecedent of "which". What is it that MUST reflect corresponding changes in the router's status? - Is it the Local Attached Network Set? That doesn't seem right, because you just said that it's not modified here, so a new MUST can't be applied to it, can it? - Is it the *changes* to the Local Attached Network Set? That doesn't seem to make semantic sense; how can it be changes that reflect corresponding changes? - Is it this protocol? That makes sense, but doesn't come out of the sentence that's written. Can you re-write these sentences to make this clearer? And then I presume that the "it" at the start of the next sentence is "The Local Attached Network Set". -- Section 14.3 -- The logic here seems to be (if I'm reading it right): if (1) then discard else (2) { if (2.1) then discard else (2.2) { do 2.2.1 if (2.2.2) then discard else { if (2.2.3) { do 2.2.3.1 do 2.2.3.2 do 2.2.3.3 } else *** there is no else *** } } } What must happen when the "otherwise if" in 2.2.3 is not true? -- Section 16.2 -- When sending a TC message in response to a change of advertised network addresses, a router MUST respect a minimum interval of TC_MIN_INTERVAL between generated TC messages. Sending an incomplete TC message MUST NOT cause the interval between complete TC messages to be increased, and thus a router MUST NOT send an incomplete TC message if within TC_MIN_INTERVAL of the next scheduled complete TC message. The first part of the second sentence confused me for a while, and it wasn't until I started typing this comment that I think I figured it out. You're saying that if you send an incomplete TC message when a complete TC message would be expected in less than TC_MIN_INTERVAL from now, then the complete TC message would be required to wait, and that would be bad -- so don't do that. Is that right? I think that second sentence is hard to understand as written (at least, it took me several readings and some intervening misunderstandings), and I wonder if you can try to re-phrase it. -- Appendix D -- I worry slightly that this appendix is normative, but comes after three non-normative example appendixes. Perhaps that's fine, and I worry unnecessarily. Would it be at all worthwhile to say something where Appendix D is cited, in the first bullet in Section 22 ? Maybe something as simple as adding the word "normative"?: "All updates to the elements specified in this specification are subject to the normative constraints specified in [RFC6130] and Appendix D." |
2012-10-07
|
16 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2012-10-05
|
16 | Martin Stiemerling | Assignment of request for Telechat review by TSVDIR to Rolf Winter was rejected |
2012-10-04
|
16 | Martin Stiemerling | Request for Telechat review by TSVDIR is assigned to Rolf Winter |
2012-10-04
|
16 | Martin Stiemerling | Request for Telechat review by TSVDIR is assigned to Rolf Winter |
2012-10-04
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Tom Yu |
2012-10-04
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Tom Yu |
2012-10-03
|
16 | Adrian Farrel | Ballot has been issued |
2012-10-03
|
16 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2012-10-03
|
16 | Adrian Farrel | Created "Approve" ballot |
2012-10-03
|
16 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2012-10-03
|
16 | Adrian Farrel | Placed on agenda for telechat - 2012-10-11 |
2012-10-02
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-10-02
|
16 | Christopher Dearlove | New version available: draft-ietf-manet-olsrv2-16.txt |
2012-08-24
|
15 | Tero Kivinen | Request for Last Call review by SECDIR Completed. Reviewer: Tom Yu. |
2012-08-24
|
15 | Adrian Farrel | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead |
2012-08-22
|
15 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-08-20
|
15 | Pearl Liang | IANA has reviewed draft-ietf-manet-olsrv2-15 and has the following comments: IANA has questions about the IANA actions requested in this document. IANA understands that, upon approval … IANA has reviewed draft-ietf-manet-olsrv2-15 and has the following comments: IANA has questions about the IANA actions requested in this document. IANA understands that, upon approval of this document, there are 11 actions which IANA needs to complete. First, in the Message Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges a new Message Type will be registered as follows from the 0-233 range of the subregistry: Type: [ TBD ] Description: TC : Topology Control (MANET-wide signaling) Reference: [ RFC-to-be ] Currently the Message Types subregistry is maintained through expert review as defined in RFC 5226. IANA Question -> has the document been reviewed by the Message Types subregistry expert? Second, a new registry will be created called the "Message-Type-specific Message TLVs for TC messages" registry. This new subregistry will be located in the Message Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges For Types 128 through 223 inclusive, the Description will be "Unassigned" and the Registration Procedure will be "Expert Review" as defined in RFC 5226. IANA Question ---> Are the ranges 0-127 and 224-255 to be marked "Reserved?" Third, a new registry will be created called the "Message-Type-specific Address Block TLVs for TC messages" registry. This new subregistry will be located in the Message Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges For Types 128 through 223 inclusive, the Description will be "Unassigned" and the Registration Procedure will be "Expert Review" as defined in RFC 5226. IANA Question ---> Are the ranges 0-127 and 224-255 to be marked "Reserved?" Fourth, in the Message TLV Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges two new Message TLV Types will be created as follows: Type: [ TBD ] Description: MPR_WILLING Reference: [ RFC-to-be ] Type: [ TBD ] Description: CONT_SEQ_NUM Reference: [ RFC-to-be ] Fifth, a new subregistry will be created called the "MPR_WILLING Message Type Extensions" subregistry. This new subregistry will be located in the Message Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges There are initial assignments and Registration Policies as follows (TBD in this case refers to the value created for MPR_WILLING in task four above): +-------------+------+-----------+---------------------+------------+ | Name | Type | Type | Description | Allocation | | | | Extension | | Policy | +-------------+------+-----------+---------------------+------------+ | MPR_WILLING | TBD | 0 | Bits 0-3 specify | | | | | | the originating | | | | | | router's | | | | | | willingness to act | | | | | | as a flooding MPR; | | | | | | bits 4-7 specify | | | | | | the originating | | | | | | router's | | | | | | willingness to act | | | | | | as a routing MPR. | | | MPR_WILLING | TBD2 | 1-255 | Unassigned. | Expert | | | | | | Review | +-------------+------+-----------+---------------------+------------+ Sixth, a new subregistry will be created called the "CONT_SEQ_NUM Message Type Extensions" subregistry. This new subregistry will be located in the Message Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at (TBD in this case refers to the value created for CONT_SEQ_NUM in task four above): http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges There are initial assignments and Registration Policies as follows: +--------------+------+-----------+--------------------+------------+ | Name | Type | Type | Description | Allocation | | | | Extension | | Policy | +--------------+------+-----------+--------------------+------------+ | CONT_SEQ_NUM | TBD | 0 | COMPLETE: | | | | | | Specifies a | | | | | | content sequence | | | | | | number for this | | | | | | complete message. | | | CONT_SEQ_NUM | TBD | 1 | INCOMPLETE: | | | | | | Specifies a | | | | | | content sequence | | | | | | number for this | | | | | | incomplete | | | | | | message. | | | CONT_SEQ_NUM | TBD | 2-255 | Unassigned. | Expert | | | | | | Review | +--------------+------+-----------+--------------------+------------+ Seventh, in the Address Block TLV Types subregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges Four new Address Block TLV Types will be registered from the 8 - 127 range as follows: Type: [ TBD ] Description: LINK_METRIC Reference: [ RFC-to-be ] Type: [ TBD ] Description: MPR Reference: [ RFC-to-be ] Type: [ TBD ] Description: NBR_ADDR_TYPE Reference: [ RFC-to-be ] Type: [ TBD ] Description: GATEWAY Reference: [ RFC-to-be ] Currently the Address Block TLV Types subregistry is maintained through expert review as defined in RFC 5226. IANA Question -> has the document been reviewed by the Address Block TLV Types subregistry expert? Eighth, a new registry called the "LINK_METRIC Address Block TLV Type Extensions" subregistry will be created. The new subregistry will be asubregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges Initial assignments and registration procedures are as follows: (TBD below refers to the Address Block TLV Type registered for LINK_METRIC in action seven above) +-------------+------+-----------+-------------------+--------------+ | Name | Type | Type | Description | Allocation | | | | Extension | | Policy | +-------------+------+-----------+-------------------+--------------+ | LINK_METRIC | TBD | 0 | Link metric | | | | | | meaning assigned | | | | | | by administrative | | | | | | action. | | | LINK_METRIC | TBD | 1-223 | Unassigned. | Expert | | | | | | Review | | LINK_METRIC | TBD | 224-255 | Unassigned. | Experimental | | | | | | Use | +-------------+------+-----------+-------------------+--------------+ Ninth, a new registry called the "MPR Address Block TLV Type Extensions" subregistry will be created. The new subregistry will be asubregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges Initial assignments and registration procedures are as follows: (TBD below refers to the Address Block TLV Type registered for MPR in action seven above) +------+------+-----------+----------------------------+------------+ | Name | Type | Type | Description | Allocation | | | | Extension | | Policy | +------+------+-----------+----------------------------+------------+ | MPR | TBD | 0 | Specifies that a given | | | | | | network address is of a | | | | | | router selected as a | | | | | | flooding MPR (FLOODING = | | | | | | 1), that a given network | | | | | | address is of a router | | | | | | selected as a routing MPR | | | | | | (ROUTING = 2), or both | | | | | | (FLOOD_ROUTE = 3). | | | MPR | TBD | 1-255 | Unassigned. | Expert | | | | | | Review | +------+------+-----------+----------------------------+------------+ Tenth, a new registry called the "NBR_ADDR_TYPE Address Block TLV Type Extensions" subregistry will be created. The new subregistry will be asubregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges Initial assignments and registration procedures are as follows: (TBD below refers to the Address Block TLV Type registered for NBR_ADDR_TYPE in action seven above) +---------------+------+-----------+-------------------+------------+ | Name | Type | Type | Description | Allocation | | | | Extension | | Policy | +---------------+------+-----------+-------------------+------------+ | NBR_ADDR_TYPE | TBD | 0 | Specifies that a | | | | | | given network | | | | | | address is of a | | | | | | neighbor reached | | | | | | via the | | | | | | originating | | | | | | router, if it is | | | | | | an originator | | | | | | address | | | | | | (ORIGINATOR = 1), | | | | | | is a routable | | | | | | address (ROUTABLE | | | | | | = 2), or if it is | | | | | | both | | | | | | (ROUTABLE_ORIG = | | | | | | 3). | | | NBR_ADDR_TYPE | TBD | 1-255 | Unassigned. | Expert | | | | | | Review | +---------------+------+-----------+-------------------+------------+ Eleventh, a new registry called the "GATEWAY Address Block TLV Type Extensions" subregistry will be created. The new subregistry will be asubregistry of the Mobile Ad hoc NETwork (MANET) Parameters registry located at: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges Initial assignments and registration procedures are as follows: (TBD below refers to the Address Block TLV Type registered for GATEWAY in action seven above) +---------+------+-----------+-------------------------+------------+ | Name | Type | Type | Description | Allocation | | | | extension | | Policy | +---------+------+-----------+-------------------------+------------+ | GATEWAY | TBD | 0 | Specifies that a given | | | | | | network address is | | | | | | reached via a gateway | | | | | | on the originating | | | | | | router, with value | | | | | | equal to the number of | | | | | | hops. | | | GATEWAY | TBD | 1-255 | | Expert | | | | | | Review | +---------+------+-----------+-------------------------+------------+ IANA understands that these eleven actions are the only ones that IANA needs to complete upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. |
2012-08-01
|
15 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Tom Yu |
2012-08-01
|
15 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Tom Yu |
2012-07-28
|
15 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (The Optimized Link State Routing Protocol … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (The Optimized Link State Routing Protocol version 2) to Proposed Standard The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'The Optimized Link State Routing Protocol version 2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This last call period has been extended to handle the fact that it spans the IETF-84 meeting. This last call is being re-initiated to include a notice that this document includes a normative down reference to an Informational RFC: RFC5148, "Jitter considerations in MANETs". Abstract This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-07-28
|
15 | Cindy Morgan | State changed to In Last Call from None |
2012-07-28
|
15 | Adrian Farrel | Last call announcement was changed |
2012-07-26
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2012-07-26
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2012-07-25
|
15 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (The Optimized Link State Routing Protocol … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (The Optimized Link State Routing Protocol version 2) to Proposed Standard The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'The Optimized Link State Routing Protocol version 2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This last call periodhas been extended to handle the fact that it spans the IETF-84 meeting. Abstract This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-07-25
|
15 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2012-07-25
|
15 | Adrian Farrel | Last call was requested |
2012-07-25
|
15 | Adrian Farrel | Ballot approval text was generated |
2012-07-25
|
15 | Adrian Farrel | State changed to Last Call Requested from AD Evaluation |
2012-07-25
|
15 | Adrian Farrel | Last call announcement was changed |
2012-07-25
|
15 | Adrian Farrel | Last call announcement was generated |
2012-07-25
|
15 | Adrian Farrel | Ballot writeup was changed |
2012-07-25
|
15 | Adrian Farrel | Ballot writeup was generated |
2012-06-11
|
15 | Adrian Farrel | State changed to AD Evaluation from Publication Requested |
2012-06-04
|
15 | Cindy Morgan | (1) The request is to publish this document as a Standards Track RFC, and this is indicated in the document header. OLSRv2 reflects approximately 8 … (1) The request is to publish this document as a Standards Track RFC, and this is indicated in the document header. OLSRv2 reflects approximately 8 years of experiences with OLSR, published as experimental RFC3626, and multiple independent implementations and deployments exist. It is built on the Proposed Standard "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)" (RFC 6130) that was spun-off from it. (2) Document Announcement Write-Up. Technical Summary The abstract of this document is included below. This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key optimization of OLSRv2 is that of multipoint relays, providing an efficient mechanism for network-wide broadcast of link-state information. A secondary optimization is that OLSRv2 employs partial link-state information: each node maintains information of all destinations, but only a subset of links. This allows that only select nodes diffuse link-state advertisements (i.e. reduces the number of network-wide broadcasts) and that these advertisements contain only a subset of links (i.e. reduces the size of each network-wide broadcast). The partial link-state information thus obtained allows each OLSRv2 node to at all times maintain optimal (in terms of number of hops) routes to all destinations in the network. OLSRv2 imposes minimum requirements to the network by not requiring sequenced or reliable transmission of control traffic. Furthermore, the only interaction between OLSRv2 and the IP stack is routing table management. OLSRv2 is particularly suitable for large and dense networks as the technique of MPRs works well in this context. Working Group Summary o OLSRv2 is the routing protocol, which uses as constituent parts (and from which was spun off) the already published by the MANET Working Group RFCs 5148, 5444, 5497, and 6130. The document also uses RFC 5498 - also already published by the MANET Working Group. This document is, therefore, an integral part of the Working Group deliverables, and its publication completes the charter item of a "proactive MANET protocol". o OLSRv2 was first submitted as an individual draft in July 2005 (draft-clausen-manet-olsrv2-00), and accepted as a Working Group document in August 2005. o A key difference between RFC3626 and OLSRv2 is the introduction of support for link metrics. An individual draft (draft-dearlove-olsrv2-metrics-00) was submitted in 2007, discussing the design options, culminating in 2010 with draft-dearlove-olsrv2-metrics-05 documenting Working Group consensus on this matter. Metrics support was, then, folded into OLSRv2. o This version of OLSRv2 was given a one month WGLC, so as to ensure sufficient time to review the document. o The Working Group is actively working on the associated MIB document (draft-ietf-manet-olsrv2-mib) There was an issue concerning the differences between the -14 and -15 revisions of the document, brought up by one WG member. The consensus opinion from the WG is that the document should proceed, without additional edits. Document Quality There is a number of independent implementations of OLSRv2. Those listed below have, explicitly, consented to be nominatively mentioned: o Ecole Polytechnique, France (Contact: Thomas Clausen) o CRC - Communications Research Centre Canada (Contact: Yannick Lacharite) o INRIA, France (Contact: Cedric Adjih) o Hitachi Yokohama Research Lab, Japan (Contact: Hiroki Satoh) o BAE Systems Advanced Technology Centre, UK (Contact Christopher Dearlove) Finally, in the open-source world: o Fraunhofer FKIE is working on the olsr.org implementation of OLSRv2 (Contact: Henning Rogge) o Niigata University, Japan http://www2.net.ie.niigata-u.ac.jp/nuOLSRv2/ (Contact: Hiroei Imai) Over the years, several interoperability events have been organized, in France, Canada, Japan, Austria, .... Personnel The Document Shepherd is Stan Ratliff (sratliff@cisco.com); the responsible Area Directors are Adrian Farrel and Stewart Bryant. (3) The document Shepherd has participated in review both in the Working Group, and has run the "idnits" tool against the draft. (4) The Document Shepherd has no concerns about the reviews of the document; they have been very thorough. (5) The authors do not believe that additional reviews are required, aside from the usual directorate reviews during IETF last call. (6) The Document Shepherd has no concerns with the document. (7) All authors have confirmed that they are unaware of any IPR needing disclosure; there are no known IPR claims related to this document. (8) No IPR disclosures have been filed, as none are required. (9) WG consensus appears to be strong. (10) As mentioned earlier, one WG participant has expressed displeasure to the AD's. As of this writing, the issue seems to be closed, and no further action is required. (11) No ID nits were found. (12) Mib Doctor, media type, and URI reviews are not required. (13) All references have been defined as either normative or informative. (14) No normative references exist to documents not ready for advancement. Of the normative references, all are to already published RFC's. (15) This document contains a downref to RFC5148. RFC5148 was published as "Informational", as this document provides guidance as to how to schedule message transmissions so as to avoid collisions on some common (in MANET) media types. As RFC5148 does not prescribe behavior that impacts interoperability, the understanding with the responsible AD when publishing RFC5148 was that this would not cause any process-problems so long as it was called out. (16) Publication of this document will NOT change the status of any existing RFC. (17) The Document Shepherd has reviewed the IANA considerations section of the document, and it appears wholly consistent with the body of said document. Extensions are associated with the appropriate reservations in IANA registries. All IANA registries have been clearly defined. (18) Impact on IANA registries : This specification defines one Message Type, which must be allocated from the "Message Types" repository of [RFC5444], two Message TLV Types, which must be allocated from the "Message TLV Types" repository of [RFC5444], and four Address Block TLV Types, which must be allocated from the "Address Block TLV Types" repository of [RFC5444]. Each TLV type incurs creation of a "Type Extension" registry. This document requests these registry creations, and (by way of referencing allocation procedures from [RFC5444]) also specifies allocation policies. Each Message type incurs creation of a Message-Type-specific TLV registry. This document requests these registry creations, and (by way of referencing allocation procedures from [RFC5444]) also specifies allocation policies. IANA registry creation and allocations are done exactly as in RFC6130. (19) The Document Shepherd has run the idnits tool against the document; all issues have been resolved. |
2012-06-04
|
15 | Cindy Morgan | Note added 'Stan Ratliff (sratliff@cisco.com) is the document shepherd.' |
2012-06-04
|
15 | Cindy Morgan | Intended Status changed to Proposed Standard |
2012-06-04
|
15 | Cindy Morgan | IESG process started in state Publication Requested |
2012-06-04
|
15 | (System) | Earlier history may be found in the Comment Log for draft-clausen-manet-olsrv2 |
2012-05-15
|
15 | Thomas Clausen | New version available: draft-ietf-manet-olsrv2-15.txt |
2012-04-14
|
14 | Stan Ratliff | IETF state changed to In WG Last Call from WG Document |
2012-03-08
|
14 | Stan Ratliff | A 30-day WGLC was agreed to at IETF 83. WGLC will end May 10, 2012. |
2012-03-08
|
14 | Anabel Martinez | New version available: draft-ietf-manet-olsrv2-14.txt |
2011-10-14
|
13 | (System) | New version available: draft-ietf-manet-olsrv2-13.txt |
2011-07-26
|
12 | (System) | New version available: draft-ietf-manet-olsrv2-12.txt |
2010-10-22
|
13 | (System) | Document has expired |
2010-04-20
|
11 | (System) | New version available: draft-ietf-manet-olsrv2-11.txt |
2009-09-25
|
10 | (System) | New version available: draft-ietf-manet-olsrv2-10.txt |
2009-07-13
|
09 | (System) | New version available: draft-ietf-manet-olsrv2-09.txt |
2009-03-09
|
08 | (System) | New version available: draft-ietf-manet-olsrv2-08.txt |
2008-07-10
|
07 | (System) | New version available: draft-ietf-manet-olsrv2-07.txt |
2008-06-06
|
06 | (System) | New version available: draft-ietf-manet-olsrv2-06.txt |
2008-02-25
|
05 | (System) | New version available: draft-ietf-manet-olsrv2-05.txt |
2007-07-12
|
04 | (System) | New version available: draft-ietf-manet-olsrv2-04.txt |
2007-03-02
|
03 | (System) | New version available: draft-ietf-manet-olsrv2-03.txt |
2006-06-27
|
02 | (System) | New version available: draft-ietf-manet-olsrv2-02.txt |
2006-03-09
|
01 | (System) | New version available: draft-ietf-manet-olsrv2-01.txt |
2005-10-21
|
00 | (System) | New version available: draft-ietf-manet-olsrv2-00.txt |