--- 1/draft-ietf-roll-efficient-npdao-11.txt 2019-06-03 18:13:09.680867418 -0700 +++ 2/draft-ietf-roll-efficient-npdao-12.txt 2019-06-03 18:13:09.736868837 -0700 @@ -1,22 +1,22 @@ ROLL R. Jadhav, Ed. Internet-Draft Huawei Intended status: Standards Track P. Thubert -Expires: November 26, 2019 Cisco +Expires: December 5, 2019 Cisco R. Sahoo Z. Cao Huawei - May 25, 2019 + June 3, 2019 Efficient Route Invalidation - draft-ietf-roll-efficient-npdao-11 + draft-ietf-roll-efficient-npdao-12 Abstract This document describes the problems associated with No-Path Destination Advertisement Object (NPDAO) messaging used in Routing Protocol for Low power and lossy networks (RPL) for route invalidation and signaling changes to improve route invalidation efficiency. Status of This Memo @@ -27,21 +27,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 November 26, 2019. + This Internet-Draft will expire on December 5, 2019. 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 @@ -356,21 +356,21 @@ Figure 2: Updated Transit Information Option (New I flag added) I (Invalidate previous route) flag: The 'I' flag is set by the target node to indicate to the common ancestor node that it wishes to invalidate any previous route between the two paths. [RFC6550] allows parent address to be sent in the Transit Information Option depending on the mode of operation. In case of storing mode of operation the field is usually not needed. In case of DCO, the - parent address field MUST not be included. + parent address field MUST NOT be included. The common ancestor node SHOULD generate a DCO message in response to this I-flag when it sees that the routing adjacencies have changed for the target. I-flag governs the ownership of the DCO message in a way that the target node is still in control of its own route invalidation. 4.3. Destination Cleanup Object (DCO) A new ICMPv6 RPL control message type is defined by this @@ -544,25 +544,25 @@ message MUST be dropped. The scope of DCOSequence values is unique to each node. 4.5. Unsolicited DCO A 6LR may generate an unsolicited DCO to unilaterally cleanup the path on behalf of the target entry. The 6LR has all the state information namely, the Target address and the Path Sequence, required for generating DCO in its routing table. The conditions why - 6LR may generate an unsolicited DCO is beyond the scope of this + 6LR may generate an unsolicited DCO are beyond the scope of this document but some possible reasons could be: - 1. On route expiry of an entry, a 6LR may decide to gracious cleanup - the entry by initiating DCO. + 1. On route expiry of an entry, a 6LR may decide to graciously + cleanup the entry by initiating DCO. 2. 6LR needs to entertain higher priority entries in case the routing table is full thus resulting in an eviction of existing routing entry. In this case the eviction can be handled graciously using DCO. Note that if the 6LR initiates a unilateral path cleanup using DCO and if it has the latest state for the target then the DCO would finally reach the target node. Thus the target node would be informed of its invalidation.