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/