draft-ietf-roll-efficient-npdao-11.txt   draft-ietf-roll-efficient-npdao-12.txt 
ROLL R. Jadhav, Ed. ROLL R. Jadhav, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: November 26, 2019 Cisco Expires: December 5, 2019 Cisco
R. Sahoo R. Sahoo
Z. Cao Z. Cao
Huawei Huawei
May 25, 2019 June 3, 2019
Efficient Route Invalidation Efficient Route Invalidation
draft-ietf-roll-efficient-npdao-11 draft-ietf-roll-efficient-npdao-12
Abstract Abstract
This document describes the problems associated with No-Path This document describes the problems associated with No-Path
Destination Advertisement Object (NPDAO) messaging used in Routing Destination Advertisement Object (NPDAO) messaging used in Routing
Protocol for Low power and lossy networks (RPL) for route Protocol for Low power and lossy networks (RPL) for route
invalidation and signaling changes to improve route invalidation invalidation and signaling changes to improve route invalidation
efficiency. efficiency.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 44 skipping to change at page 8, line 44
Figure 2: Updated Transit Information Option (New I flag added) Figure 2: Updated Transit Information Option (New I flag added)
I (Invalidate previous route) flag: The 'I' flag is set by the target 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 node to indicate to the common ancestor node that it wishes to
invalidate any previous route between the two paths. invalidate any previous route between the two paths.
[RFC6550] allows parent address to be sent in the Transit Information [RFC6550] allows parent address to be sent in the Transit Information
Option depending on the mode of operation. In case of storing mode 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 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 The common ancestor node SHOULD generate a DCO message in response to
this I-flag when it sees that the routing adjacencies have changed 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 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 way that the target node is still in control of its own route
invalidation. invalidation.
4.3. Destination Cleanup Object (DCO) 4.3. Destination Cleanup Object (DCO)
A new ICMPv6 RPL control message type is defined by this A new ICMPv6 RPL control message type is defined by this
skipping to change at page 12, line 42 skipping to change at page 12, line 42
message MUST be dropped. message MUST be dropped.
The scope of DCOSequence values is unique to each node. The scope of DCOSequence values is unique to each node.
4.5. Unsolicited DCO 4.5. Unsolicited DCO
A 6LR may generate an unsolicited DCO to unilaterally cleanup the A 6LR may generate an unsolicited DCO to unilaterally cleanup the
path on behalf of the target entry. The 6LR has all the state path on behalf of the target entry. The 6LR has all the state
information namely, the Target address and the Path Sequence, information namely, the Target address and the Path Sequence,
required for generating DCO in its routing table. The conditions why 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: document but some possible reasons could be:
1. On route expiry of an entry, a 6LR may decide to gracious cleanup 1. On route expiry of an entry, a 6LR may decide to graciously
the entry by initiating DCO. cleanup the entry by initiating DCO.
2. 6LR needs to entertain higher priority entries in case the 2. 6LR needs to entertain higher priority entries in case the
routing table is full thus resulting in an eviction of existing routing table is full thus resulting in an eviction of existing
routing entry. In this case the eviction can be handled routing entry. In this case the eviction can be handled
graciously using DCO. graciously using DCO.
Note that if the 6LR initiates a unilateral path cleanup 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 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 finally reach the target node. Thus the target node would be
informed of its invalidation. informed of its invalidation.
 End of changes. 7 change blocks. 
8 lines changed or deleted 8 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/