draft-ietf-roll-efficient-npdao-13.txt		draft-ietf-roll-efficient-npdao-14.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: January 1, 2020 Cisco		Expires: January 4, 2020 Cisco
	R. Sahoo		R. Sahoo
	Z. Cao		Z. Cao
	Huawei		Huawei
	June 30, 2019		July 3, 2019
	Efficient Route Invalidation		Efficient Route Invalidation
	draft-ietf-roll-efficient-npdao-13		draft-ietf-roll-efficient-npdao-14
	Abstract		Abstract
	This document explains the problems associated with the current use		This document explains the problems associated with the current use
	of NPDAO messaging and also discusses the requirements for an		of NPDAO messaging and also discusses the requirements for an
	optimized route invalidation messaging scheme. Further a new		optimized route invalidation messaging scheme. Further a new
	proactive route invalidation message called as "Destination Cleanup		proactive route invalidation message called as "Destination Cleanup
	Object" (DCO) is specified which fulfills requirements of an		Object" (DCO) is specified which fulfills requirements of an
	optimized route invalidation messaging.		optimized route invalidation messaging.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 January 1, 2020.		This Internet-Draft will expire on January 4, 2020.
	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 2, line 49 ¶		skipping to change at page 2, line 49 ¶
	4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13		4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13
	4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 13		4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 13
	4.6.3. DCO with multiple preferred parents . . . . . . . . . 14		4.6.3. DCO with multiple preferred parents . . . . . . . . . 14
	5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	6.1. New Registry for the Destination Cleanup Object (DCO)		6.1. New Registry for the Destination Cleanup Object (DCO)
	Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 15		Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	6.2. New Registry for the Destination Cleanup Object		6.2. New Registry for the Destination Cleanup Object
	Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 16		Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 16
	6.3. New Registry for the Destination Cleanup Object (DCO)		6.3. New Registry for the Destination Cleanup Object (DCO)
	Acknowledgment Flags . . . . . . . . . . . . . . . . . . 16		Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	8. Normative References . . . . . . . . . . . . . . . . . . . . 18		8. Normative References . . . . . . . . . . . . . . . . . . . . 18
	Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 18		Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 19
	A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 19		A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 19
	A.2. Example DCO Messaging with multiple preferred parents . . 20		A.2. Example DCO Messaging with multiple preferred parents . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	RPL [RFC6550] (Routing Protocol for Low power and lossy networks)		RPL [RFC6550] (Routing Protocol for Low power and lossy networks)
	specifies a proactive distance-vector based routing scheme. RPL has		specifies a proactive distance-vector based routing scheme. RPL has
	optional messaging in the form of DAO (Destination Advertisement		optional messaging in the form of DAO (Destination Advertisement
	Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo		Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo
	skipping to change at page 14, line 51 ¶		skipping to change at page 14, line 51 ¶
	i.e., the common ancestor can wait for updated DAOs from all possible		i.e., the common ancestor can wait for updated DAOs from all possible
	directions before initiating a DCO for route invalidation. After		directions before initiating a DCO for route invalidation. After
	timeout, the DCO needs to be generated for all the next-hops for whom		timeout, the DCO needs to be generated for all the next-hops for whom
	the route invalidation needs to be done.		the route invalidation needs to be done.
	This document recommends using a DelayDCO timer value of 1sec. This		This document recommends using a DelayDCO timer value of 1sec. This
	value is inspired by the default DelayDAO value of 1sec in [RFC6550].		value is inspired by the default DelayDAO value of 1sec in [RFC6550].
	Here the hypothesis is that the DAOs from all possible parent sets		Here the hypothesis is that the DAOs from all possible parent sets
	would be received on the common ancestor within this time period.		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		Note that there is no requirement for synchronization between DCO and
	DAOs. The DelayDCO timer simply ensures that the DCO control		DAOs. The DelayDCO timer simply ensures that the DCO control
	overhead can be reduced and is only needed when the network contains		overhead can be reduced and is only needed when the network contains
	nodes using multiple preferred parent.		nodes using multiple preferred parent.
	5. Acknowledgments		5. Acknowledgments
	Many thanks to Alvaro Retana, Cenk Gundogan, Simon Duquennoy,		Many thanks to Alvaro Retana, Cenk Gundogan, Simon Duquennoy,
	Georgios Papadopoulous, Peter Van Der Stok for their review and		Georgios Papadopoulous, Peter Van Der Stok for their review and
	comments. Alvaro Retana helped shape this document's final version		comments. Alvaro Retana helped shape this document's final version
	skipping to change at page 16, line 41 ¶		skipping to change at page 16, line 50 ¶
	+------------+----------------------------------------+-------------+		+------------+----------------------------------------+-------------+
	| Status | Description | Reference |		| Status | Description | Reference |
	| Code | | |		| Code | | |
	+------------+----------------------------------------+-------------+		+------------+----------------------------------------+-------------+
	| 0 | Unqualified acceptance | This |		| 0 | Unqualified acceptance | This |
	| | | document |		| | | document |
	| 1 | No routing-entry for the indicated | This |		| 1 | No routing-entry for the indicated | This |
	| | Target found | document |		| | Target found | document |
	+------------+----------------------------------------+-------------+		+------------+----------------------------------------+-------------+
	DCO Status Codes		DCO-ACK Status Codes
	6.3. New Registry for the Destination Cleanup Object (DCO)		6.3. New Registry for the Destination Cleanup Object (DCO)
	Acknowledgment Flags		Acknowledgment Flags
	IANA is requested to create a registry for the 8-bit Destination		IANA is requested to create a registry for the 8-bit Destination
	Cleanup Object (DCO) Acknowledgment Flags field. This registry		Cleanup Object (DCO) Acknowledgment Flags field. This registry
	should be located in existing category of "Routing Protocol for Low		should be located in existing category of "Routing Protocol for Low
	Power and Lossy Networks (RPL)".		Power and Lossy Networks (RPL)".
	New bit numbers may be allocated only by an IETF Review. Each bit is		New bit numbers may be allocated only by an IETF Review. Each bit is
End of changes. 8 change blocks.
	7 lines changed or deleted		16 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/