Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks
draft-ietf-roll-routing-metrics-19
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
19 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
2012-08-22
|
19 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2012-08-22
|
19 | (System) | post-migration administrative database adjustment to the Abstain position for Lars Eggert |
2012-08-22
|
19 | (System) | post-migration administrative database adjustment to the No Objection position for Ronald Bonica |
2011-03-07
|
19 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2011-03-07
|
19 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2011-03-07
|
19 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2011-03-04
|
19 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2011-03-01
|
19 | (System) | New version available: draft-ietf-roll-routing-metrics-19.txt |
2011-02-28
|
19 | (System) | IANA Action state changed to In Progress |
2011-02-28
|
19 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-02-25
|
19 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-02-25
|
19 | Amy Vezza | IESG has approved the document |
2011-02-25
|
19 | Amy Vezza | Closed "Approve" ballot |
2011-02-25
|
19 | Adrian Farrel | Ballot writeup text changed |
2011-02-25
|
19 | Adrian Farrel | Approval announcement text changed |
2011-02-25
|
19 | Adrian Farrel | Approval announcement text regenerated |
2011-02-25
|
19 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2011-02-21
|
18 | (System) | New version available: draft-ietf-roll-routing-metrics-18.txt |
2011-02-20
|
19 | Jari Arkko | [Ballot discuss] I dislike the complexity and the large number of options that this draft defines. But I have become convinced that they are necessary. … [Ballot discuss] I dislike the complexity and the large number of options that this draft defines. But I have become convinced that they are necessary. I was particularly swayed by the argument that existing proprietary protocols have the same features. However, I have one remaining concern: given the number of options and different capabilities, I would like to see the draft what options and functionality is mandatory to implement for interoperability. |
2011-02-07
|
19 | Amy Vezza | Approval announcement text regenerated |
2011-02-01
|
19 | Dan Romascanu | [Ballot comment] |
2011-02-01
|
19 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss |
2011-01-31
|
19 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to Abstain from Discuss |
2011-01-30
|
19 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-01-30
|
17 | (System) | New version available: draft-ietf-roll-routing-metrics-17.txt |
2011-01-21
|
19 | (System) | Removed from agenda for telechat - 2011-01-20 |
2011-01-20
|
19 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
2011-01-20
|
19 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Discuss |
2011-01-20
|
19 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded |
2011-01-20
|
19 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-19
|
19 | Peter Saint-Andre | [Ballot comment] Based on the reviews provided by IESG members more expert than I in the technology under consideration, I am ballotting "No Objection". That … [Ballot comment] Based on the reviews provided by IESG members more expert than I in the technology under consideration, I am ballotting "No Objection". That said, based on my own review I concur with the DISCUSS raised by Jari Arkko regarding the complexity of the system. |
2011-01-19
|
19 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-19
|
19 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-19
|
19 | Ron Bonica | [Ballot discuss] This may be a DISCUSS-DISCUSS. I believe that in order to achieve loop-free routing, the following conditions must be true: - all nodes … [Ballot discuss] This may be a DISCUSS-DISCUSS. I believe that in order to achieve loop-free routing, the following conditions must be true: - all nodes must construct identical link state data bases (LSDB) - all nodes must run identical (or at least equivalent) SPF algorithms over that LSDB While I understand how ROLL devices might construct identical LSDBs, I don't understand how all nodes will run and identical (or even equivalent) SPF algorithms. The first problem is that all nodes don't neccessarily understand all metrics advertised with C-bit == 0. So, if all SPFs don't understand all of the same inputs, how can they be expected to produce the same outputs? THe second problem is an SPF with multiple inputs is pretty complex. Is it documented well enough that multiple vendors may produce interworking implementations? Finally, a node might advertise a metric with C-bit = 0 and then override that same metric with C-bit =1. When that happens, does the old advertisement disappear from the LSDB. |
2011-01-19
|
19 | Ron Bonica | [Ballot Position Update] New position, Discuss, has been recorded |
2011-01-19
|
19 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-18
|
19 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-18
|
19 | Jari Arkko | [Ballot discuss] I am concerned about the complexity of the RPL system. The set of attributes is relatively complex, 8 different attributes (The BGP parameters … [Ballot discuss] I am concerned about the complexity of the RPL system. The set of attributes is relatively complex, 8 different attributes (The BGP parameters registry has 26, but RPL is expected to be run in environments where there is no experts to monitor its operation or fine-tune the parameters.) The large set of attributes, dynamically changing parameters, complex topologies, and unattended operation seems like a recipe for operational and interoperability problems. I do recognize the need to have dynamic metrics, power-aware routing, and many of the other things in this specification, however. My question is whether this is the absolute minimum set that we should define. Do we need Section 2.1 A field? Section 3.1 A or O flags? The mid-complexity solution from Section 3.2? Section 4.3.1 *and* Section 4.3.2 reliability metrics? A few more specific concerns: Section 3.1: o A Flag: data Aggregation Attribute. Data fusion involves more complicated processing to improve the accuracy of the output data, while data aggregation mostly aims at reducing the amount of data. This is underspecified. And why do you talk about data fusion, if the attribute signals data aggregation. Please define what the semantics of the bit and the participant's behaviour is with respect to data aggregation, or point to a reference. |
2011-01-18
|
19 | Jari Arkko | [Ballot comment] I agree with Lars Eggert's Discuss. Section 4.3: In LLNs, link reliability is degraded by external interference and multi-path interference (wireless … [Ballot comment] I agree with Lars Eggert's Discuss. Section 4.3: In LLNs, link reliability is degraded by external interference and multi-path interference (wireless links). Multipath typically affects both directions on the link equally, whereas external interference is sometimes unidirectional. I'm not sure I understand the term "multi-path interference" in this context. Perhaps you should use some other term. Multi-path usually refers to the use of multiple paths simultaneously. Radio interference from multiple links can certainly occur in ROLL networks. But I'm not sure why you call it "multi-path interference". I would probably just say "... degraded by attenuation (due to distance and objects) and interference (from external objects or within the RPL network)". |
2011-01-18
|
19 | Jari Arkko | [Ballot comment] I agree with Lars Eggert's Discuss. |
2011-01-18
|
19 | Jari Arkko | [Ballot discuss] Section 3.1: o A Flag: data Aggregation Attribute. Data fusion involves more complicated processing to improve the accuracy of … [Ballot discuss] Section 3.1: o A Flag: data Aggregation Attribute. Data fusion involves more complicated processing to improve the accuracy of the output data, while data aggregation mostly aims at reducing the amount of data. This is underspecified. And why do you talk about data fusion, if the attribute signals data aggregation. Please define what the semantics of the bit and the participant's behaviour is with respect to data aggregation, or point to a reference. |
2011-01-18
|
19 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded |
2011-01-18
|
19 | Dan Romascanu | [Ballot comment] 1. The way the Flag field is defined in Figure 1 is confusing. The field is defined as length 16 bits, but then … [Ballot comment] 1. The way the Flag field is defined in Figure 1 is confusing. The field is defined as length 16 bits, but then there are 5 bits labelled Flags on the diagram which are actually the currently reserved or un-allocated Flags. The A field and PRec filed are part of the Flag field, but there is no indication or indent to make this clear. 2. Expand DIO at first occurence 3. Section 4.1 - the Throughput object seems to be mis-named. Looks more like Link Capacity. |
2011-01-18
|
19 | Dan Romascanu | [Ballot comment] 1. The way the Flag field is defined in Figure 1 is confusing. The field is defined as length 16 bits, but then … [Ballot comment] 1. The way the Flag field is defined in Figure 1 is confusing. The field is defined as length 16 bits, but then there are 5 bits labelled Flags on the diagram which are actually the currently reserved or un-allocated Flags. The A field and PRec filed are part of the Flag field, but there is no indication or indent to make this clear. 2. Extend DIO at first occurence 3. Section 4.1 - the Throughput object seems to be mis-named. Looks more like Link Capacity. |
2011-01-18
|
19 | Dan Romascanu | [Ballot discuss] A few issues need to be addressed before I can ballot favorably this document: 1. Section 2.1 - Value: variable for Routing Metric/Constraint … [Ballot discuss] A few issues need to be addressed before I can ballot favorably this document: 1. Section 2.1 - Value: variable for Routing Metric/Constraint TLVs. What is the length range. 255 is maximum I assume, but is zero an acceptable length value? 2. Section 3.1 - An implementation MAY decide to add optional TLVs (not currently defined) to further describe the node traffic aggregator functionality. It is not clear to me how an implementation can make such a decision. Two different implementations would not be interoperable if this is not defined some place. Is this about extensibility? 3. Section 3.2 - it is not clear from the text that estimating the 'energetic happiness' - actually the remaining power battery for battery operated devices is always possible, and if not how this metrics is being filled in. Will just the E bit be cleared and no estimation provided? 4. Section 4.2 - the latency metric is unsufficiently defined. What is the measurement observation point? is buffering taken into consideration? 5. Section 4.3.1 > The Link Quality Level (LQL) object is used to quantify the link reliability using a discrete value, from 0 to 7 where 0 indicates that the link quality level is unknown and 1 reports the highest link quality level. The mechanisms and algorithms used to compute the LQL are implementation specific and outside of the scope of this document. This seems broken. How can interoperability be ensured between two independent implementations if the metric is a discrete value whose algorithm of determination is implementation specific? |
2011-01-18
|
19 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded |
2011-01-17
|
19 | Lars Eggert | [Ballot comment] Section 1., paragraph 16: > flexibility to use link and node characterisics either as constraints Nit: s/characterisics/characteristics/ Section 1., paragraph 21: … [Ballot comment] Section 1., paragraph 16: > flexibility to use link and node characterisics either as constraints Nit: s/characterisics/characteristics/ Section 1., paragraph 21: > and unneccessary routing changes. Nit: s/unneccessary/unnecessary/ Section 3., paragraph 1: > objet MUST silently be ignored. Nit: s/objet/object/ Section 4.1., paragraph 0: > 4.1. Throughput I think you mean (link) capacity here and not throughput. See the definition in RFC5136; could you adopt this definition here? Section 4.2., paragraph 0: > 4.2. Latency See the definitions in RFC2679, can they be adopted here? Also, is this metric supposed to include buffering/queueing delay (which is load dependent) or is it purely supposed to capture the link transmission delay? If the former, that can vary quite a bit more... Section 4.3.2., paragraph 12: > the path (cummulative path ETX calculated as the sum of the link ETX Nit: s/(cummulative/(cumulative/ Section 7., paragraph 1: > consist of making intermitment attacks on a link in an attempt to Nit: s/intermitment/intermittent/ Section 8., paragraph 1: > valuable comments. Special thank to Adrian Farrel for his thourough Nit: s/thourough/thorough/ |
2011-01-17
|
19 | Lars Eggert | [Ballot discuss] DISCUSS: My high-level concern with this document is that it focuses on how metrics are encoded in RPL TLVs, rather than giving … [Ballot discuss] DISCUSS: My high-level concern with this document is that it focuses on how metrics are encoded in RPL TLVs, rather than giving formal and therefore unambiguous definitions of the metrics. Not in all cases, but in several. For example, the misnamed "throughput" metric doesn't make it clear whether it describes nominal link capacity or residual capacity, or whether it is an instantaneous metric or averaged over some period, etc. The "delay" metric leaves it open whether buffering delays are supposed to be included or not. The link reliability metric is much too open; when does e.g. a ZigBee link have a reliability of 5? When of 6? Hat about a BT-LE link? And so on. The reason I'm bringing this up is that in oder to have route selection pick paths for end systems based on these metrics, it needs to be understood what these metrics concretely *mean*. I don't think that's currently possible, and I believe that makes them rather less useful that advertised. If IPPM has taught us anything it's that metrics really do need to be unambiguously defined for them to be useful. I realize this discuss isn't really actionable. I plan to clear it after discussing my concern with the IESG call. |
2011-01-17
|
19 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded |
2011-01-16
|
16 | (System) | New version available: draft-ietf-roll-routing-metrics-16.txt |
2011-01-15
|
19 | Alexey Melnikov | [Ballot comment] In 2.1: The A field has no meaning when the C Flag is set (i.e. when the Routing Metric/Constraint object refers … [Ballot comment] In 2.1: The A field has no meaning when the C Flag is set (i.e. when the Routing Metric/Constraint object refers to a routing constraint) and he only valid when the R bit is cleared. Otherwise, the A field MUST Is "he" should be here at all? be set to 0x00 and MUST be ignored on receipt. 4.1. Throughput Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format, In network byte order? (Also in 4.2) expressed in bytes per second. |
2011-01-15
|
19 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded |
2011-01-14
|
19 | David Harrington | Closed request for Last Call review by TSVDIR with state 'No Response' |
2011-01-14
|
19 | Adrian Farrel | Ballot writeup text changed |
2011-01-13
|
15 | (System) | New version available: draft-ietf-roll-routing-metrics-15.txt |
2011-01-13
|
19 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead::Revised ID Needed. |
2011-01-13
|
19 | Adrian Farrel | Placed on agenda for telechat - 2011-01-20 |
2011-01-13
|
19 | Adrian Farrel | Ballot writeup text changed |
2011-01-13
|
19 | Adrian Farrel | Ballot writeup text changed |
2011-01-10
|
19 | Sam Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Joseph Salowey. |
2011-01-07
|
19 | Adrian Farrel | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead. |
2011-01-05
|
19 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2010-12-21
|
19 | Amanda Baber | IANA has questions about the IANA Actions requested in this document. IANA understands that, upon approval of this document, six IANA Actions need to be … IANA has questions about the IANA Actions requested in this document. IANA understands that, upon approval of this document, six IANA Actions need to be completed. The document requests that a new, top-level registry be created and that the IANA Protocol Matrix be updated to contain a pointer to this new registry. The reference in the Matrix and all subregistries will be [RFC-to-be]. IANA Question --> what should be the name of the newly created registry that contains the subregistries requested in section 6 of the document? First, a new subregistry of the new registry created above will be created. The new subregistry is called "Routing Metric/Constraint Object Types." New registrations in this subregistry require RFCs. The initial registrations in this subregistry are: Value Meaning Reference 1 Node State and Attribute [RFC-to-be] 2 Node Energy [RFC-to-be] 3 Hop Count [RFC-to-be] 4 Link Throughput [RFC-to-be] 5 Link Latency [RFC-to-be] 6 Link Quality Level [RFC-to-be] 7 Link ETX [RFC-to-be] 8 Link Color [RFC-to-be] IANA Question--> what is the range of values for Routing Metric/Constraint Object Types? Is value zero undefined, reserved or not registered? Second, a new subregistry of the new registry created above will be created. The new subregistry is called "Routing Metric/Constraint TLVs." New registrations in this subregistry require RFCs. There are no initial registrations in this subregistry. IANA Question--? what is the range of values that will be used for these TLVs? Third, a new subregistry of the new registry created above will be created. The new subregistry is called "Routing Metric/Constraint Common Headers." New registrations in this subregistry require RFCs. The initial registrations in this subregistry are: Codespace of the A field (Routing Metric/Constraint common header) Value Meaning Reference 0 Routing metric is additive [RFC-to-be] 1 Routing metric reports a maximum [RFC-to-be] 2 Routing metric reports a minimum [RFC-to-be] 3 Routing metric is multiplicative [RFC-to-be] IANA Question-->what is the range of the common header values? Fourth, a new subregistry of the new registry created above will be created. The new subregistry is called "Routing Metric/Constraint Common Header Flag Field." New registrations in this subregistry require IETF Consensus. The initial registrations in this subregistry are: Routing Metric/Constraing Common Header Flag field Bit Description Reference 12-15 Precedence [RFC-to-be] 9-11 Additive/Max/Min/Multi [RFC-to-be] 8 Recorded/Aggregated [RFC-to-be] 7 Optional Constraint [RFC-to-be] 6 Constraint/Metric [RFC-to-be] 5 P (Partial) [RFC-to-be] IANA Question-->how should bits 0-4 be marked in this subregistry? Fifth, a new subregistry of the new registry created above will be created. The new subregistry is called "NSA Object Flag Field." New registrations in this subregistry require IETF Consensus. The initial registrations in this subregistry are: NSA Object Flag field Bit Description Reference 14 Aggregator [RFC-to-be] 15 Overloaded [RFC-to-be] IANA Question --> how should bits 0-13 be marked? Sixth, a new subregistry of the new registry created above will be created. The new subregistry is called "Hop Count Object Flags." New registrations in this subregistry require IETF Consensus. There are no initial registrations in this subregistry. IANA Question--> is the bit range for these flags 0 - 15? IANA understands that these are the only actions required upon approval of this document. |
2010-12-17
|
19 | David Harrington | Request for Last Call review by TSVDIR is assigned to Henk Uijterwaal |
2010-12-17
|
19 | David Harrington | Request for Last Call review by TSVDIR is assigned to Henk Uijterwaal |
2010-12-16
|
19 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2010-12-16
|
19 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2010-12-13
|
19 | Amy Vezza | Last call sent |
2010-12-13
|
19 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Routing Metrics used for Path Calculation in Low Power and Lossy Networks) to Proposed Standard The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Routing Metrics used for Path Calculation in Low Power and Lossy Networks' as a 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 2011-01-05. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-routing-metrics/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-routing-metrics/ |
2010-12-13
|
19 | Adrian Farrel | Last Call was requested |
2010-12-13
|
19 | Adrian Farrel | State changed to Last Call Requested from AD Evaluation::AD Followup. |
2010-12-13
|
19 | Adrian Farrel | Last Call text changed |
2010-12-13
|
19 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2010-12-13
|
19 | Adrian Farrel | Ballot has been issued |
2010-12-13
|
19 | Adrian Farrel | Created "Approve" ballot |
2010-12-13
|
19 | (System) | Ballot writeup text was added |
2010-12-13
|
19 | (System) | Last call text was added |
2010-12-13
|
19 | (System) | Ballot approval text was added |
2010-12-13
|
19 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-12-13
|
14 | (System) | New version available: draft-ietf-roll-routing-metrics-14.txt |
2010-12-08
|
19 | Adrian Farrel | State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup. |
2010-12-06
|
19 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-12-06
|
13 | (System) | New version available: draft-ietf-roll-routing-metrics-13.txt |
2010-11-26
|
19 | Adrian Farrel | State changed to AD Evaluation::Revised ID Needed from AD Evaluation. AD Evaluation Hi, I have performed an AD review of your draft. Don't panic! I … State changed to AD Evaluation::Revised ID Needed from AD Evaluation. AD Evaluation Hi, I have performed an AD review of your draft. Don't panic! I review all drafts that I am responsible for before putting them forward for IETF last call. The main objective is to catch nits and minor issues that would show up during the last call or in IESG review. The intention is to help polish your document and make sure it is clean and shiny so that other reviewers will stick to the technical details. Thanks for an important component of the RPL family. Most of my comments are pretty trivial, but a couple have more meat on them and I'd like to see a quick respin of the document before I issue the IETF last call. As soon as I see a new revision posted, I'll set the ball in motion. Of course, all of my issues are up for discussion. Thanks for the work, Adrian --- I am slightly worried about the complexity inherent in this spec. Although individual implementations and deployments might choose to use a very limited subset of the available (and flexible) options, it seems that an implementation must support a much wider subset of options, metrics, and constraints in order to be deployable into a wide range of networks. Does this flexibility impact simplicity of implementation? --- I think [I-D.ietf-roll-rpl] should be a normative reference. --- Section 1 One of the prime objectives of this document is to propose a flexible s/propose/define/ --- DODAG is used without expansion On the other hand, DAG is expanded more than once. --- Section 1 The best path is the path with the lowest cost with respect to some metrics that satisfies all constraints (if any). Slightly ambiguous. What satisfies the constraints: the path, the cost, the metrics? Suggest... The best path is the path that satisfies all supplied constraints and that has the lowest cost with respect to some specified metrics. --- Section 1 OLD Routing metrics falls into the following sets of characteristics: NEW Routing metrics may be categorized according to the following characteristics: END (English) --- Section 1 OLD Some link or node characteristics (e.g. link reliability flag, NEW Some link or node characteristics (e.g. link reliability, END (the flag is not a characteristic) --- Section 1 OLD remaining energy on the node) may either be used by RPL either as routing constraints or metrics. NEW remaining energy on the node) may be used by RPL either as routing constraints or as metrics. OLD (English) --- Section 1 OLD exclusive (e.g. it is for example possible to advertise a "hop count" NEW exclusive (e.g. it is possible to advertise a "hop count" END (English) --- Section 1 s/dynimicity/dynamicity/ --- Section 1 It must be noted that the use of dynamic metrics is not new and has been experimented in ARPANET 2. The use of dynamic metrics is not trivial and great care must be given to the use of dynamic metrics since it may lead to potential routing instabilities. That being said, lots of experience has been gained over the years on the use of dynamic routing metrics, which have been deployed in a number of (non IP) networks. Can you add a couple of references? One for ARPANET 2 experimentation, and one for the "lots of experience gained". --- Use of RFC 2119 language. The first use (SHOULD) shows up late in Section 1 after a number of lower case "must". I think that the best way to smooth this out is to not use any 2119 language in the Introduction. --- Section 1 OLD nodes in LLN, it is particularly critical to ensure the use of NEW nodes in LLN, it is critical to ensure the use of END (critical is a superlative) --- Please capitalise all section headers --- Figure 1 This is a copy of figure 22 in draft-ietf-roll-rpl. I strongly recommend that you do not duplicate protocol bit/byte definitions as this can lead to accidental discrepancies. Why not replace this figure with a reference? --- Bit numberings in fields. Please align the numbers so that we count bits in base 10. --- Section 2.1 Routing Metric/Constraint object field descriptions. Convention is to list these under the figure in the same order as they appear in the figure. The most disruptive, in this case, is the dislocation of the P field (which should probably also be called the P flag). --- Section 2.1 I think the A flag needs a little more constraint. Not only is it only valid when C=1 (as stated), but it is only valid when R=0. Also OLD and MUST be written to 0x00. NEW and MUST be set to 0x00 and MUST be ignored on receipt. END --- Section 2.1 Unrecognized TLVs MUST be ignored. Do you want to clarify that "ignoring" includes leaving the TLVs in place in the object when it is forwarded along the DAG? --- Section 2.2 Have you considered the case that the recording of metrics causes the Routing Metric/Constraint object to overflow? --- Section 3.1 The Node State and Attribute (NSA) object is used to provide information on node's characteristics. s/node's/node/ --- Section 3.1 The NSA object MAY be present in the DAG Metric Container. There MUST be no more than one NSA object as a constraint per DAG Metric Container, and no more than one NSA object as a metric per DAG Metric Container. This is fine, but you will need to define somewhere what happens when a formatting error is detected. This can either be done on a case-by- case basis, or can be a general statement in Section 3. See also, Section 3.2 The NE object MAY be present in the DAG Metric Container. There MUST be no more than one NE object as a constraint per DAG Metric Container, and no more than one NE object as a metric per DAG Metric Container. etc., etc. Incidentally, it might be more graceful to use "MUST NOT" instead of "MUST". For example: OLD The HP object MAY be present in the DAG Metric Container. There MUST be no more than one HP object as a constraint per DAG Metric Container, and no more than one HP object as a metric per DAG Metric Container. NEW The HP object MAY be present in the DAG Metric Container. There MUST NOT be more one HP object as a constraint per DAG Metric Container, and there MUST NOT be more than one HP object as a metric per DAG Metric Container. END --- Section 3.1 There seems to be some duplication of the definition of the O and A flags. --- Section 3.1 Is IANA expected to track the flags in the NSA object? Are the Type values for the TLVs chosen from a common registry across all objects, or is there a separate registry for each object? --- Section 3.2 Whenever possible, a node with low residual energy should not be selected as a router Do you have a reference for this? --- Section 3.2 Given the complexity of trying to address such a broad collection of constraints, this document defines three levels of fidelity in the solution. I only find two levels defined in the section: - The simplest solution relies on a 2-bit field - The mid-complexity solution is a single parameter Did I miss one, or did you? --- Section 3.2 For scavenging nodes, the 8 bit quantity is the power provided by the scavenger divided by the power consumed by the application, H=P_in/P_out, in units of percent. and For battery powered devices, H is the current expected lifetime divided by the desired minimum lifetime. Is the second case also expressed as a percentage? --- Section 3.2 I'm slightly confused by the difference (or not) between the term 'H' and the term 'E-E'. Firstly, E-E looks like an arithmetic expression. But, more to the point, I *think* you put the value of H in the field E-E, so why have two names for the same thing? --- Objects, sub-objects, and TLVs I think you have some inconsistency in naming. At the top level we have "Routing Metric/Constraint object" The "object body" of this object is defined as: The object body carries one or more sub-objects defined later in this document. So I expect everything that follows in Sections 3 and 4 to be termed sub-objects. But you have also termed these things as "objects". Some of the objects/sub-objects in Sections 3 and 4 can, themselves have sub-objects, while others launch straight into contained TLVs. This is all a bit confusing (although there is nothing technically wrong) and it would be really nice to achieve some consistency of terminology. --- Section 3.2 The format of the NE sub-object body is as follows: And what Type value does this sub-object use? --- Section 3.2 o T (node Type): 2-bit field indicating the node type. E=0x00 designates a mains-powered node, E=0x01 a battery-powered node and E=0x02 a node powered by an energy scavenger. Do you mean T=0x00 etc.? --- Section 3.2 empty is that I bit is an inclusion. s/is that/if that/ --- Section 3.2 Future addenda to this document may include more complex solutions involving a half dozen TLV parameters representing energy storage, consumption, and generation capabilities of the node, as well as desired lifetime. Can you rephrase this to avoid mentioning "addenda" which we don't really do? How about: Future documents may define more complex solutions involving TLV parameters representing energy storage, consumption, and generation capabilities of the node, as well as desired lifetime. --- Section 3.3 No Flag is currently defined. Need the usual "set to zero, ignored on receipt" text. --- Section 3.3 The HP object may be used as a constraint or a metric. When used as a constraint, the DAG root indicates the maximum number of hops that a path may traverse. When that number is reached, no other node can join that path. When used as a metric, each visited node simply increments the Hop Count field. Are you counting nodes or hops? Does the first node send the Hop Count as one or zero? --- Section 3.3 It looks to me that if the object is used as a constraint, it MUST also be present as a metric. This seems to be different from the burble at the top of the section. (and obviously, we can think of more optimal ways of signaling this - such as decrementing the hop count at each hop). --- Section 4.1 For the deeply duty-cycled links found in many LLNs Will this term be clear to the reader? --- Section 4.1 OLD There are several MAC layer protocols which allow for the effective bit rate and power consumption of a link to vary over more than three orders of magnitude, with a corresponding change in power consumption. NEW There are several MAC layer protocols which allow for the effective bit rate of a link to vary over more than three orders of magnitude with a corresponding change in power consumption. END --- Section 4.1 With special reference to my comment (above) about objects, sub-objects, and TLVs, it is really not helpful to have an object (which is actually a sub-object) and a sub-object of that object both called Throughput! --- Section 4.1 Figure 9: Throughput sub-object format And what Type value does this sub-object use? But, I might ask why you need sub-objects when the content is well-known to be 32-bit values, and the parent object has a length field. --- Section 4.1 Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format, expressed in bytes per second. Are you sure this is enough? Yes, it seems like it today. How future- proof is this? --- Section 4.2 Similarly to throughput, the latency of many LLN MAC sub-layers can vary over many orders of magnitude, again with a corresponding change in current consumption. s/current/power/? --- Section 4.2 Ditto object and sub-object names. Ditto sub-object Type value. --- Section 4.2 Again, it looks like the use of this object as a constraint is only possible if it is also used as a metric. So (again) it looks like the rules for object presence are broken. But that depends how it is used as a constraint! It might be used to mean that no link with unsatisfactory latency may be added to the DAG, or it might mean that the cumulative latency must not grow beyond the the constrained limit. You need to clarify meaning and usage. --- Section 4.3 Note that an RPL implementation MAY either use the LQL, the ETX or both. This immediately makes me worry about interoperability. --- Section 4.3.1 By contrast, the LQL link metric may be aggregated, in which case the sum of all LQLs may be reported (additive metric) How can this possibly be useful? Unless you know how many hops are traversed, the aggregate is meaningless! --- Section 4.3.1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Res | LQL sub-object +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... The Res field does not appear to be described. --- Section 4.3.1 It seems to me that a type 0x02 aggregation is not very helpful because "unknown" will hide the otherwise 'best' link quality. But maybe this doesn't matter because 'worst' link quality is more interesting. --- Section 4.4.1 Ditto Res field --- Section 4.4.1 How come the LC field in the two sub-objects have different sizes? --- Section 4.4.1 The use of the LC object is outside the scope of this document. It seems to me you have gone off half cocked :-( There is some description at the top of the section that implies a little about how LC is used. It seems closer to a color (a la ToS) than to a bit array (a la resource affinities). If you are determined that this is out of scope for your document, I wonder why the object is defined, and I wonder why the section has preamble on the use of the meaning of LC. And I really wonder about the presence of section 4.4.2. --- Section 6 There doesn't seem to be any tracking of sub-object Type values. --- Section 7 You really need a reference to draft-ietf-roll-security-framework. I think that you made a key security comment in a previous section where you said that it is recommended that the algorithms used do not cause excess information flapping. A significant security attack might be mounted by periodically attacking the quality of a link resulting in the routing protocol flapping. This would cause wider damage than simply the disruption to the local link. |
2010-11-23
|
19 | Adrian Farrel | State changed to AD Evaluation from Publication Requested. |
2010-11-09
|
12 | (System) | New version available: draft-ietf-roll-routing-metrics-12.txt |
2010-11-04
|
19 | Cindy Morgan | Routing Metrics used for Path Calculation in Low Power and Lossy Networks draft-ietf-roll-routing-metrics-12 Intended status : Standard Track > (1.a) Who is the … Routing Metrics used for Path Calculation in Low Power and Lossy Networks draft-ietf-roll-routing-metrics-12 Intended status : Standard Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? David Culler is the document shepherd. He has personally reviewed the document and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? Yes, the document has had adequate review. It has gone through several revisions, extensive open discussion, and a full LC process. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? The shepherd has no such concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. Initial versions of this document were incredibly fluffy and full of irrelevant jargon. Given that the other co-chair was an author, this chair had to ride hard to produce a credible document of substance. Some reviewers may have been turned off by those early drafts. This one is reasonable, so it is important that it be read without prejudice of its history. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? It represents strong consensus of a large group. There is a camp that view it as unnecessary complexity and also those that view it as essential. The core RPL spec defines the basics that are sufficient for the former. This defines the options for the latter. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? Checks have been made. No Known Errors. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. Yes. References split. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? Yes. The IANA section of this document includes a detailed list of new IANA registries. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) 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 > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. Low power and Lossy Networks (LLNs) have specific routing characteristics compared with traditional wired or ad-hoc networks that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and [RFC5867]. These involve selecting routes that optimize for particular metrics under non-trivial constraints. Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have used quantitative static link metrics. Other mechanisms such as Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see [RFC2702] and [RFC3209]) make use of other link attributes such as the available reserved bandwidth (dynamic) or link affinities (most of the time static) to compute constrained shortest paths for Traffic Engineering Label Switched Paths (TE LSPs). This document specifies routing metrics and constraints to be used in path calculation by the Routing Protocol for Low Power and Lossy Networks (RPL) specified in [I-D.ietf-roll-rpl]. It propose a flexible mechanism for the advertisement of routing metrics and constraints used by RPL. Some RPL implementations may elect to adopt an extremely simple approach based on the use of a single metric with no constraint whereas other implementations may use a larger set of link and node routing metrics and constraints. This specification provides a high degree of flexibility and a set of routing metrics and constraints, including node state and attributes, node energy, hop-count, estimated transmission count, throughput, latency, link reliability, mode of operation, or generic 'color'. Extensions are anticipated should ew routing metrics and constraints be defined in the future. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? No. It took several iterations before we had a solid technical document. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? Good. It is basically defining a type representation, so implementation is trivial. |
2010-11-04
|
19 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2010-11-04
|
19 | Cindy Morgan | [Note]: 'David Culler (culler@eecs.berkeley.edu) is the document shepherd.' added by Cindy Morgan |
2010-10-24
|
11 | (System) | New version available: draft-ietf-roll-routing-metrics-11.txt |
2010-10-20
|
10 | (System) | New version available: draft-ietf-roll-routing-metrics-10.txt |
2010-09-05
|
09 | (System) | New version available: draft-ietf-roll-routing-metrics-09.txt |
2010-07-09
|
08 | (System) | New version available: draft-ietf-roll-routing-metrics-08.txt |
2010-06-11
|
07 | (System) | New version available: draft-ietf-roll-routing-metrics-07.txt |
2010-04-28
|
06 | (System) | New version available: draft-ietf-roll-routing-metrics-06.txt |
2010-03-22
|
05 | (System) | New version available: draft-ietf-roll-routing-metrics-05.txt |
2009-12-03
|
04 | (System) | New version available: draft-ietf-roll-routing-metrics-04.txt |
2009-10-26
|
03 | (System) | New version available: draft-ietf-roll-routing-metrics-03.txt |
2009-10-26
|
02 | (System) | New version available: draft-ietf-roll-routing-metrics-02.txt |
2009-10-24
|
01 | (System) | New version available: draft-ietf-roll-routing-metrics-01.txt |
2009-05-11
|
00 | (System) | New version available: draft-ietf-roll-routing-metrics-00.txt |