--- 1/draft-ietf-roll-efficient-npdao-13.txt 2019-07-03 18:13:32.147511931 -0700 +++ 2/draft-ietf-roll-efficient-npdao-14.txt 2019-07-03 18:13:32.199513251 -0700 @@ -1,22 +1,22 @@ ROLL R. Jadhav, Ed. Internet-Draft Huawei Intended status: Standards Track P. Thubert -Expires: January 1, 2020 Cisco +Expires: January 4, 2020 Cisco R. Sahoo Z. Cao Huawei - June 30, 2019 + July 3, 2019 Efficient Route Invalidation - draft-ietf-roll-efficient-npdao-13 + draft-ietf-roll-efficient-npdao-14 Abstract This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new proactive route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 1, 2020. + This Internet-Draft will expire on January 4, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -84,24 +84,24 @@ 4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13 4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 13 4.6.3. DCO with multiple preferred parents . . . . . . . . . 14 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1. New Registry for the Destination Cleanup Object (DCO) Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. New Registry for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 16 6.3. New Registry for the Destination Cleanup Object (DCO) - Acknowledgment Flags . . . . . . . . . . . . . . . . . . 16 + Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Normative References . . . . . . . . . . . . . . . . . . . . 18 - Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 18 + Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 19 A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 19 A.2. Example DCO Messaging with multiple preferred parents . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction RPL [RFC6550] (Routing Protocol for Low power and lossy networks) specifies a proactive distance-vector based routing scheme. RPL has optional messaging in the form of DAO (Destination Advertisement Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo @@ -656,20 +656,29 @@ i.e., the common ancestor can wait for updated DAOs from all possible directions before initiating a DCO for route invalidation. After timeout, the DCO needs to be generated for all the next-hops for whom the route invalidation needs to be done. This document recommends using a DelayDCO timer value of 1sec. This value is inspired by the default DelayDAO value of 1sec in [RFC6550]. Here the hypothesis is that the DAOs from all possible parent sets would be received on the common ancestor within this time period. + It is still possible that a DCO is generated before all the updated + DAOs from all the paths are received. In this case, the ancestor + node would start the invalidation procedure for paths from which the + updated DAO is not received. The DCO generated in this case would + start invalidating the segments along these paths on which the + updated DAOs are not received. But once the DAO reaches these + segments, the routing state would be updated along these segments and + should not lead to any inconsistent routing state. + Note that there is no requirement for synchronization between DCO and DAOs. The DelayDCO timer simply ensures that the DCO control overhead can be reduced and is only needed when the network contains nodes using multiple preferred parent. 5. Acknowledgments Many thanks to Alvaro Retana, Cenk Gundogan, Simon Duquennoy, Georgios Papadopoulous, Peter Van Der Stok for their review and comments. Alvaro Retana helped shape this document's final version @@ -741,21 +750,21 @@ +------------+----------------------------------------+-------------+ | Status | Description | Reference | | Code | | | +------------+----------------------------------------+-------------+ | 0 | Unqualified acceptance | This | | | | document | | 1 | No routing-entry for the indicated | This | | | Target found | document | +------------+----------------------------------------+-------------+ - DCO Status Codes + DCO-ACK Status Codes 6.3. New Registry for the Destination Cleanup Object (DCO) Acknowledgment Flags IANA is requested to create a registry for the 8-bit Destination Cleanup Object (DCO) Acknowledgment Flags field. This registry should be located in existing category of "Routing Protocol for Low Power and Lossy Networks (RPL)". New bit numbers may be allocated only by an IETF Review. Each bit is