[Roll] AD Review of draft-ietf-roll-efficient-npdao-09
Alvaro Retana <aretana.ietf@gmail.com> Thu, 11 April 2019 21:12 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C98E120220; Thu, 11 Apr 2019 14:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDuyQhcWua9l; Thu, 11 Apr 2019 14:12:15 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B976B120165; Thu, 11 Apr 2019 14:12:11 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id j132so6201430oib.2; Thu, 11 Apr 2019 14:12:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=+lUVvRQoldCsb4S76Dv/23eALwY4tmsfSTKUilhanD8=; b=oHFnsIJkzyDVuK3mUXmphTH6WnzLp8PDuaXO2JEzepPXw/wh8JBw8aFdgWjYJ12LOR +aZ7gLN/txy1l66QjFtF0ufJlRCsqdK4S1b2dGvQGmEgqw8mPM5a5rXP9hI4nFGmR5Xr fGBGREzPNuPjcB0bdINDSGBu5md/rZHHlD/f3PN8OM39KtkAWMOcbJymYyKlRT4lZN6Z DGJdvMW6/Sc5JucsS5X0gSdNCiJnad//exRv9CpW16u15bpMl/VypeIuzsP0SDmoc59R a503BZT9StwspH49BhUm2ULeI9Iiea8tsCDq2V1LvbHYvZ159dhvIcezAg6qcDkQ0c9P H5DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=+lUVvRQoldCsb4S76Dv/23eALwY4tmsfSTKUilhanD8=; b=g+4k3w+Z1qE3DQie0OjcrYiSVwpwLVBx+EV1y90hk9OUcPK2RipFCcGwlOHlUtYOwc /wNS2b/IhHyFDFNr0DH/a51iWfBHkspC2MEdw9W3P7fykrd2RUqzUWSlzqND58cpPZub mCflwznYbWfJkAnV8Di9Za/M6GTRWElMKpuyTqbfZ7g7NYEk/5OLvgOLXv6skaAGMXW+ HvqzklsNTFrTpkJaBfPVVoZnz8UWT5JfqPShObfaOoQ8ckQ2yq1bcuhIw6w37jgP22Ar /478803112iIyiJCsTquwYsAm52qknztnqm4BdDruqJtW66meAhn8chegBHWr4mdNyc6 LEvA==
X-Gm-Message-State: APjAAAUSjnyaBT01MyF7oegGR0rq/0VeZL3VbvCmq8w/aVK6Z7IfeqZF dqE0eL67OUUL+SoHO9hYG3Ea7cdMECZhpK6UpNt1xQ==
X-Google-Smtp-Source: APXvYqx8paGriTziqKPBolEk9DimFZxiiCxzndy6bQbcXKsPGRSeRAW8PSvrxEdLQeBLQFt4Wp+mTvMQ2lqG9PBAFzA=
X-Received: by 2002:aca:ea54:: with SMTP id i81mr7791213oih.115.1555017130306; Thu, 11 Apr 2019 14:12:10 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Apr 2019 14:12:09 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Thu, 11 Apr 2019 14:12:09 -0700
Message-ID: <CAMMESsy11FvVEZ6VGRK7PYo4FXzVs8x=G-y-0U8C3bkgyK5R8A@mail.gmail.com>
To: draft-ietf-roll-efficient-npdao@ietf.org
Cc: Peter van der Stok <consultancy@vanderstok.org>, roll-chairs <roll-chairs@ietf.org>, roll <roll@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000abf257058647a36b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/U5dTAIw-Gjv1NqUad32MpmlhWn4>
Subject: [Roll] AD Review of draft-ietf-roll-efficient-npdao-09
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 21:12:21 -0000
Dear authors: Here's my review of this document. The first part of the document mostly resulted in nits, but (starting in §4) I then have some major comments. I'll wait for those to be addressed before starting the IETF Last Call. The most significant issue is the fact that the suggested values for the DCO are already assigned! The Shepherd's writeup says that a pilot implementation exists -- which, I assume uses the suggested values. What is the impact on existing implementations? Thanks! Alvaro. [Line numbers come from idnits.] ... 14 Abstract 16 This document describes the problems associated with NPDAO messaging 17 used in RPL for route invalidation and signaling changes to improve 18 route invalidation efficiency. [nit] Please expand NPDAO...you may have to do it completely (including DAO). [nit] RPL should be expanded in the Abstract as well... ... 91 1. Introduction 93 RPL [RFC6550] (Routing Protocol for Low power and lossy networks) 94 specifies a proactive distance-vector based routing scheme. RPL has 95 an optional messaging in the form of DAO (Destination Advertisement 96 Object) messages using which the 6LBR (6Lo Border Router) and 6LR 97 (6Lo Router) can learn route towards the downstream nodes. In 98 storing mode, DAO messages would result in routing entries been 99 created on all intermediate 6LRs from the node's parent all the way 100 towards the 6LBR. [nit] s/messages using which the 6LBR (6Lo Border Router) and 6LR (6Lo Router) can learn route/messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo Router) can use to learn a route [nit] s/routing entries been created/routing entries being created 102 RPL allows use of No-Path DAO (NPDAO) messaging to invalidate a 103 routing path corresponding to the given target, thus releasing 104 resources utilized on that path. A NPDAO is a DAO message with route 105 lifetime of zero, originates at the target node and always flows 106 upstream towards the 6LBR. This document explains the problems 107 associated with the current use of NPDAO messaging and also discusses 108 the requirements for an optimized route invalidation messaging 109 scheme. Further a new pro-active route invalidation message called 110 as "Destination Cleanup Object (DCO)" is specified which fulfills 111 requirements of an optimized route invalidation messaging. [nit] s/allows use of/allows the use of [nit] s/"Destination Cleanup Object (DCO)"/"Destination Cleanup Object" (DCO) ... 117 1.1. Requirements Language and Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. [major] Please use the template in rfc8174. 123 6LR: 6LoWPAN Router. This is an intermediate 6lowpan router which 124 allows traffic routing through itself in a multihop 6lo network. [nit] Please be consistent: 6LoWPAN vs 6lowpan [nit] You may have to define 6lo. [minor] In this case, the definition includes the name: "6LoWPAN Router...is an intermediate 6lowpan router..." [nit] In general, simply pointing to rfc6550 (or other documents where the terms are already defined) may be easier than redefining. ... 161 1.2. Current NPDAO messaging 163 RPL uses NPDAO messaging in the storing mode so that the node 164 changing it routing adjacencies can invalidate the previous route. 165 This is needed so that nodes along previous path can release any 166 resources (such as the routing entry) it maintains on behalf of 167 target node. [nit] s/along previous path/along the previous path ... 200 1.3. Why NPDAO is important? 202 Nodes in LLNs may be resource constrained. There is limited memory 203 available and routing entry records are one of the primary elements 204 occupying dynamic memory in the nodes. Route invalidation helps 6LR 205 nodes to decide which entries could be discarded to better achieve 206 resource utilization. Thus it becomes necessary to have efficient 207 route invalidation mechanism. Also note that a single parent switch 208 may result in a "sub-tree" switching from one parent to another. 209 Thus the route invalidation needs to be done on behalf of the sub- 210 tree and not the switching node alone. In the above example, when 211 Node (D) switches parent, the route updates needs to be done for the 212 routing tables entries of (C),(H),(A),(G), and (B) with destination 213 (D),(E) and (F). Without efficient route invalidation, a 6LR may 214 have to hold a lot of stale route entries. [nit] s/to have efficient/to have an efficient ... 225 2.2. Invalidate routes of dependent nodes 227 RPL does not specify how route invalidation will work for dependent 228 nodes rooted at switching node, resulting in stale routing entries of 229 the dependent nodes. The only way for 6LR to invalidate the route 230 entries for dependent nodes would be to use route lifetime expiry 231 which could be substantially high for LLNs. [nit] s/rooted at switching node/rooted at the switching node ... 239 2.3. Possible route downtime caused by async operation of NPDAO and DAO ... 247 In the example topology, consider Node (D) switches from parent (B) 248 to (C). An NPDAO sent via previous route may invalidate the previous 249 route whereas there is no way to determine whether the new DAO has 250 successfully updated the route entries on the new path. [nit] s/via previous route/via the previous route 252 3. Requirements for the NPDAO Optimization 254 3.1. Req#1: Remove messaging dependency on link to the previous parent 256 When the switching node sends the NPDAO message to the previous 257 parent, it is normal that the link to the previous parent is prone to 258 failure (thats why the node decided to switch). Therefore, it is 259 required that the route invalidation does not depend on the previous 260 link which is prone to failure. The previous link referred here 261 represents the link between the node and its previous parent (from 262 whom the node is now disassociating). [nit] s/thats/that's ... 278 4. Proposed changes to RPL signaling [minor] These changes are not "proposed" anymore. s/Proposed changes to RPL signaling/Changes to RPL signaling 280 4.1. Change in RPL route invalidation semantics 282 As described in Section 1.2, the NPDAO originates at the node 283 switching the parent and traverses upstream towards the root. In 284 order to solve the problems as mentioned in Section 2, the draft adds 285 new pro-active route invalidation message called as "Destination 286 Cleanup Object" (DCO) that originates at a common ancestor node 287 between the new and old path. The common ancestor node generates a 288 DCO in response to the change in the next-hop on receiving a regular 289 DAO with updated path sequence for the target. [nit] Maybe it's just me, but the "switching the parent" terminology doesn't sound great. By now I am not having to reread the text because my mind tends to think of a switch (not the switching action)...but maybe "changing", or even "switching to a new parent" may be better. Another option is to simply use the "target node" term defined above. Please take this comment for what it is: just a nit. [nit] s/draft/document/g [nit] s/adds new/adds a new [nit] s/called as /called /g 291 In Figure 1, when node D decides to switch the path from B to C, it 292 sends a regular DAO to node C with reachability information 293 containing target as address of D and a incremented path sequence 294 number. Node C will update the routing table based on the 295 reachability information in DAO and in turn generate another DAO with 296 the same reachability information and forward it to H. Node H also 297 follows the same procedure as Node C and forwards it to node A. When 298 node A receives the regular DAO, it finds that it already has a 299 routing table entry on behalf of the target address of node D. It 300 finds however that the next hop information for reaching node D has 301 changed i.e. the node D has decided to change the paths. In this 302 case, Node A which is the common ancestor node for node D along the 303 two paths (previous and new), should generate a DCO which traverses 304 downwards in the network. [major] I think that this illustration should be Normatively spelled out. There are details, for example due to the fact that a new DAO is created at every hop, that are not explicitly mentioned. As the DAO is sent up the tree, it is generated "with the same reachability information" -- I think this document should be explicit about the setting of the I flag, the Path Sequence to be used, etc.. [major] Is a DCO generated at every hop? IOW, A sends the DCO to G, which takes action based on it (invalidates the routes) and then sends another DCO (with the same information) to B... If so, then that needs to be explicitly specified as well. [nit] s/in DAO/in the DAO [nit] s/i.e. the node D/i.e. node D 306 4.2. Transit Information Option changes 308 Every RPL message is divided into base message fields and additional 309 Options. The base fields apply to the message as a whole and options 310 are appended to add message/use-case specific attributes. As an 311 example, a DAO message may be attributed by one or more "RPL Target" 312 options which specify the reachability information for the given 313 targets. Similarly, a Transit Information option may be associated 314 with a set of RPL Target options. [nit] A reference to rfc6550 somewhere in the paragraph would help the reader know that none of that is new...but a review. 316 The draft proposes a change in Transit Information option to contain 317 "Invalidate previous route" (I) bit. This I-bit signals the common 318 ancestor node to generate a DCO on behalf of the target node. The 319 I-bit is carried in the transit information option which augments the 320 reachability information for a given set of RPL Target(s). Transit 321 information option should be carried in the DAO message with I-bit 322 set in case route invalidation is sought for the correspondig 323 target(s). [nit] s/The draft proposes a change/This document specifies a change [nit] s/in Transit Information option/in the Transit Information Option [nit] s/contain "Invalidate/contain the "Invalidate [nit] s/. Transit information option/. The Transit Information Option [nit] s/correspondig/corresponding 325 0 1 2 3 326 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 5 6 7 8 9 0 1 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type = 0x06 | Option Length |E|I| Flags | Path Control | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Path Sequence | Path Lifetime | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 332 | | 333 + + 334 | | 335 + Parent Address* + 336 | | 337 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 2: Updated Transit Information Option (New I flag added) [nit] Take the "*" off -- it was used in rfc6500, but has no meaning here. [nit] Indent the definition of the fields for clarity. ... 347 The common ancestor node SHOULD generate a DCO message in response to 348 this I-bit when it sees that the routing adjacencies have changed for 349 the target. I-bit governs the ownership of the DCO message in a way 350 that the target node is still in control of its own route 351 invalidation. [major] When/why would the common ancestor not generate a DCO message? IOW, why is MUST not used? I imagine that simply the nature of the LLN may prevent it from generating one (which makes the SHOULD ok)...but I'm trying to find out if there are other reasons. 353 4.3. Destination Cleanup Object (DCO) ... 383 K: The 'K' flag indicates that the recipient is expected to send a 384 DCO-ACK back. If the DCO-ACK is not received even after setting the 385 'K', an implementation may choose to retry the DCO at a later time. 386 The number of retries are implementation and deployment dependent. 387 This document recommends using retries similar to what will be set 388 for DAO-ACK handling. [minor] Why are the retries optional? If "the recipient is expected to send a DCO-ACK", then why wouldn't the sender retry? If it doesn't matter, then just don't set the flag. Given that the DCO is akin to the DAO, maybe use similar text as what is in rfc6550/§9.3... [minor] The last sentence makes a recommendation, but with no reference. rfc6550 says that the retries are implementation specific...maybe mention something like that here too. 390 D: The 'D' flag indicates that the DODAGID field is present. This 391 flag MUST be set when a local RPLInstanceID is used. 393 Flags: The 6 bits remaining unused in the Flags field are reserved 394 for future use. These bits MUST be initialized to zero by the sender 395 and MUST be ignored by the receiver. [major] Do you expect IANA to manage the assignments of those bits? ... 404 DODAGID (optional): 128-bit unsigned integer set by a DODAG root that 405 uniquely identifies a DODAG. This field is only present when the 'D' 406 flag is set. This field is typically only present when a local 407 RPLInstanceID is in use, in order to identify the DODAGID that is 408 associated with the RPLInstanceID. When a global RPLInstanceID is in 409 use, this field need not be present. Unassigned bits of the DCO Base 410 are reserved. They MUST be set to zero on transmission and MUST be 411 ignored on reception. [minor] "This field is typically only present when a local RPLInstanceID is in use..." "typically only present" is not in line with the MUST above (describing the D flag): s/typically only present/only present [major] The last couple of sentences seem to have been left behind, or at least meant for their own paragraph... I see that similar text is used in rfc6550...but I'm not sure what bits it refers to. 413 4.3.1. Secure DCO 415 A Secure DCO message follows the format in [RFC6550] figure 7, where 416 the base message format is the DCO message shown in Figure 3. [nit] s/figure 7/Figure 7 418 4.3.2. DCO Options 420 The DCO message MAY carry valid options. This specification allows 421 for the DCO message to carry the following options: 423 0x00 Pad1 424 0x01 PadN 425 0x05 RPL Target 426 0x06 Transit Information 427 0x09 RPL Target Descriptor 429 The DCO carries a Target option and an associated Transit Information 430 option with a lifetime of 0x00000000 to indicate a loss of 431 reachability to that Target. [major] Are the RPL Target and Transit Information options mandatory? If so, then that is at odds with the MAY above. [nit] s/a Target option/an RPL Target option 433 4.3.3. Path Sequence number in the DCO 435 A DCO message may contain a Path Sequence in the transit information 436 option to identify the freshness of the DCO message. The Path 437 Sequence in the DCO MUST use the same Path Sequence number present in 438 the regular DAO message when the DCO is generated in response to DAO 439 message. The DAO and DCO path sequence are picked from the same 440 sequence number set. Thus if a DCO is received by a 6LR and 441 subsequently a DAO is received with old seqeunce number, then the DAO 442 should be ignored. [minor] To make sure I'm clear: the "DCO path sequence" refers to the Path Sequence field in the Transit Information Option, right? If so, please be clear and specific. [major] The text is not clear (I asked the same thing above) if the Transit Information Option is mandatory or not in the DCO...is it? The text above says that the "DCO message may contain a Path Sequence in the transit information option". If the Transit Information Option is present, then the Path Sequence is present too...so it sounds like the Transit Information Option is not optional. [major] "Path Sequence in the DCO MUST use the same Path Sequence number present in the regular DAO message when the DCO is generated in response to DAO message" The DAO message is obviously the one that triggered the DCO... When would a DCO *not* be originated in response to a DAO? Are there other cases when the DCO can be originated? Requiring the same Path Sequence is fine...the reason for this comment is the condition ("when the DCO..."). [minor] "The DAO and DCO path sequence are picked from the same sequence number set." I'm not sure what this means -- the text before it says that the Path Sequence number "MUST use the same...present in the regular DAO message", so in reality the Path Sequence in the DCO is not picked from the same set...it's just copied. [minor] "Thus if a DCO is received by a 6LR and subsequently a DAO is received with old seqeunce number, then the DAO should be ignored." Should this behavior be Normative? IOW, do you want to use "SHOULD" instead? Maybe even "MUST". Just wondering: it seems like an important behavior.. [major] I know that the "ancestor node SHOULD generate a DCO message in response to this I-bit" (§4.2), but what prevents a (rogue) ancestor from generating a DCO at any other time? The last sentence above opens the door to an attack where the ancestor can send a DCO with a Path Sequence in the future...and cause the route to be invalidated...*and* future updates to be ignored. Is this possible? [This risk, and any possible mitigation should be mentioned in the Security Considerations.] [nit] s/transit information option/Transit Information Option [nit] s/response to DAO/response to a DAO [nit] s/path sequence/Path Sequence [minor] s/old seqeunce number/old Path Sequence number 444 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 446 The DCO-ACK message may be sent as a unicast packet by a DCO 447 recipient in response to a unicast DCO message. [minor] "may be sent" Is this an optional response? §4.3 defines the K flag in the DCO to indicate "that the recipient is expected to send a DCO-ACK back" -- that is not a Normative statement...but it seems like a waste if no ACK is sent back. ... 477 Status: Indicates the completion. Status 0 is defined as unqualified 478 acceptance in this specification. The remaining status values are 479 reserved as rejection codes. [minor] Do you expect IANA to handle the assignment of new codes? 481 DODAGID (optional): 128-bit unsigned integer set by a DODAG root that 482 uniquely identifies a DODAG. This field is only present when the 'D' 483 flag is set. This field is typically only present when a local 484 RPLInstanceID is in use, in order to identify the DODAGID that is 485 associated with the RPLInstanceID. When a global RPLInstanceID is in 486 use, this field need not be present. Unassigned bits of the DCO-Ack 487 Base are reserved. They MUST be set to zero on transmission and MUST 488 be ignored on reception. [minor] Those last 2 sentences seem to be out of place. Also, I think all the bits are accounted for above. [nit] s/DCO-Ack/DCO-ACK 490 4.3.5. Secure DCO-ACK 492 A Secure DCO-ACK message follows the format in [RFC6550] figure 7, 493 where the base message format is the DCO-ACK message shown in 494 Figure 4. [nit] s/figure 7/Figure 7 496 4.4. Other considerations 498 4.4.1. Dependent Nodes invalidation 500 Current RPL [RFC6550] does not provide a mechanism for route 501 invalidation for dependent nodes. This document allows the dependent 502 nodes invalidation. Dependent nodes will generate their respective 503 DAOs to update their paths, and the previous route invalidation for 504 those nodes should work in the similar manner described for switching 505 node. The dependent node may set the I-bit in the transit 506 information option as part of regular DAO so as to request 507 invalidation of previous route from the common ancestor node. [major] This part is underspecified. How do the dependent nodes know of the switch? Is A (Figure 1) the common ancestor node mentioned above? I found the same question being asked during WGLC, and the answer seems to be: "the dependent nodes will always set the I-flag". Is that my correct interpretation? The behavior needs to be reflected in the specification. https://mailarchive.ietf.org/arch/msg/roll/LejLNET8Hk92wPWU3Xi6OaxCujg 509 4.4.2. NPDAO and DCO in the same network 511 Even with the changed semantics, the current NPDAO mechanism in 512 [RFC6550] can still be used, for example, when the route lifetime 513 expiry of the target happens or when the node simply decides to 514 gracefully terminate the RPL session on graceful node shutdown. 515 Moreover a deployment can have a mix of nodes supporting the proposed 516 DCO and the existing NPDAO mechanism. [major] This text sounds as if the NPDAO is made optional. Is that the intent? rfc6550 says that "when a node removes a node from its DAO parent set, it SHOULD send a No-Path DAO message". If the behavior from rfc6550 is changing, then this document should be more specific and Normative about it. 518 4.4.3. DCO with multiple preferred parents 520 [RFC6550] allows a node to select multiple preferred parents for 521 route establishment. Section 9.2.1 of [RFC6550] specifies, "All DAOs 522 generated at the same time for the same Target MUST be sent with the 523 same Path Sequence in the Transit Information". Thus a DAO message 524 with the same path sequence MUST be sent to all the parents. 525 Subsequently when route invalidation has to be initiated, RPL 526 mentions that an NPDAO must be initiated with updated path sequence 527 to all the routes to be invalidated. [major] "Thus a DAO message with the same path sequence MUST be sent to all the parents." This sentence seems to just be a repetition of what the quoted text says...but making it Normative to this document. I don't see the point since the behavior is already Normative. [major] "RPL mentions that an NPDAO must be initiated with updated path sequence to all the routes to be invalidated." I couldn't find a place in rfc6550 that says that. 529 With DCO, the Target node itself does not initiate the route 530 invalidation and it is left to the common ancestor node. A common 531 ancestor node when it discovers an updated DAO from a new next-hop, 532 it initiates a DCO. With multiple preferred parents, this handling 533 does not change. But in this case it is recommended that an 534 implementation initiates a DCO after a time period such that the 535 common ancestor node may receive updated DAOs from all possible next- 536 hops. This will help to reduce DCO control overhead i.e., the common 537 ancestor can wait for updated DAOs from all possible directions 538 before initiating a DCO for route invalidation. The time period for 539 initiating a DCO could be based on the depth of the network. After 540 timeout, the DCO needs to be generated for all the next-hops for whom 541 the route invalidation needs to be done. [major] "With multiple preferred parents...it is recommended that an implementation initiates a DCO after a time period..." How does the ancestor know if there are multiple parents or not? Should this recommendation be generic? How long is should the ancestor wait? ... 548 6. IANA Considerations 550 IANA is requested to allocate new ICMPv6 RPL control codes in RPL 551 [RFC6550] for DCO and DCO-ACK messages. [major] The name of the registry is "RPL Control Codes". s//IANA is requested to allocate new codes for the DCO and DCO-ACK messages from the RPL Control Codes registry. 553 +------+---------------------------------------------+--------------+ 554 | Code | Description | Reference | 555 +------+---------------------------------------------+--------------+ 556 | 0x04 | Destination Cleanup Object | This | 557 | | | document | 558 | 0x05 | Destination Cleanup Object Acknowledgement | This | 559 | | | document | 560 | 0x84 | Secure Destination Cleanup Object | This | 561 | | | document | 562 | 0x85 | Secure Destination Cleanup Object | This | 563 | | Acknowledgement | document | 564 +------+---------------------------------------------+--------------+ [major] The values suggested in this table are already assigned. I would suggest you simply call the codes TBD1-TBD4. Note that the corresponding figures must also be updated. https://www.iana.org/assignments/rpl/rpl.xhtml#control-codes 566 IANA is requested to allocate bit 18 in the Transit Information 567 Option defined in RPL [RFC6550] section 6.7.8 for Invalidate route 568 'I' flag. [major] The registry is called "Transit Information Option Flags"...and the requested assignment corresponds to bit 1. s//IANA is requested to allocate bit 1 from the Transit Information Option Flags registry the I-bit (Section 4.2). 570 7. Security Considerations [major] This section mostly points at rfc6550 (which is ok), but it doesn't say anything about vulnerabilities (if any) that this specification may be introducing...or why it doesn't. [See my related comment in §4.3.3.] I would like to see (perhaps after the current text) something along the lines of "This document introduces the ability to do abc. It doesn't introduce any new vulnerabilities becasue... OR ... These are the new vulnerabilities and this is how they can be mitigated...or why they are not really of concern..." ... 609 Appendix A. Example Messaging 611 A.1. Example DCO Messaging 613 In Figure 1, node (D) switches its parent from (B) to (C). The 614 sequence of actions is as follows: 616 1. Node D switches its parent from node B to node C 617 2. D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated 618 path to C [minor] The notation "DAO/DCO()" should be explained somewhere...and should be consistent throughout (it changes below). 619 3. C checks for routing entry on behalf of D, since it cannot find 620 an entry on behalf of D it creates a new routing entry and 621 forwards the reachability information of the target D to H in a 622 DAO. [nit] s/for routing entry/for a routing entry/g ... 637 7. Similarly, B processes the DCO by invalidating the routing entry 638 of target D and forwards the (un)reachability information 639 downstream to D. 641 8. D ignores the DCO since the target is itself. [?] Just curious: why will B even propagate the DCO to D? B already knows that the target is D... 642 9. The propagation of the DCO will stop at any node where the node 643 does not have an routing information associated with the target. 644 If the routing information is present and the pathseq associated 645 is not older, then still the DCO is dropped. [major] This paragraph contains information that hasn't been specified elsewhere in the document. It must be. [minor] This sentence is awkwardly worded: "If the routing information is present and the pathseq associated is not older, then still the DCO is dropped." Perhaps s/the pathseq associated is not older/its Path Sequence is higher 647 A.2. Example DCO Messaging with multiple preferred parents ... 675 2. (N32) sends DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N33) also 676 sends DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N22) learns multiple 677 routes for the same destination (N41) through multiple next-hops. 678 The route table at N22 should contain (Dst,NextHop,PS): { 679 (N41,N32,x), (N41,N33,x) }. 680 3. (N22) sends DAO(tgt=N41,PS=x,I_flag=1) to (N11). [major] The I_flag is set...but (N22) doesn't originate a DCO... I think the flag should not be set at this point. ... 687 7. (N32) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N22). (N22) has 688 multiple routes to destination (N41). It sees that a new path 689 sequence for Target=N41 is received and thus it waits for pre- 690 determined time period to invalidate another route 691 {(N41),(N33),x}. After time period, (N22) sends 692 DCO(tgt=N41,PS=x+1) to (N33). [minor] The example is incomplete: (N33) sends a DCO to (N41)...
- [Roll] AD Review of draft-ietf-roll-efficient-npd… Alvaro Retana
- Re: [Roll] AD Review of draft-ietf-roll-efficient… Rahul Jadhav
- Re: [Roll] AD Review of draft-ietf-roll-efficient… Rahul Jadhav
- Re: [Roll] AD Review of draft-ietf-roll-efficient… Alvaro Retana
- Re: [Roll] AD Review of draft-ietf-roll-efficient… Rahul Arvind Jadhav
- Re: [Roll] AD Review of draft-ietf-roll-efficient… Rahul Arvind Jadhav
- Re: [Roll] AD Review of draft-ietf-roll-efficient… Pascal Thubert (pthubert)