Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll)

[Thomas Heide Clausen <[e-mail]>]

Dear All,

I am sure that we all want to see the roll work progress in a  
constructive and conductive way, and so hereby my remarks to the  
proposed charter.
I feel that there are a couple of things which require readjustment  
in the charter, before it will be useful to the IETF and to the roll  
working group. I strongly urge that the working group rechartering  
takes the below into consideration.

(i)	Traffic characteristics and delivery semantics

	The proposed charter reads:

			Typical traffic patterns are not simply unicast flows (e.g. in some
			cases  most if not all traffic can be point to multipoint).

	Comments:

	a)	It is not clear what the exact semantics of "point-to-multipoint"  
is. On the
		[e-mail] list, it was made clear that it was "not multicast"  
as the
		destination-set for a transmission was not to be determined by the
		destinations (e.g. through subscribing to a multicast group) but  
rather
		by the source.

	b)	It is not clear by which means the source is to make this  
determination.
		I can see a number of possibilities, which entail different design
		constraint on protocol(s) for this space:
		
			o	the source has a-priori knowledge as to the destination set?
			o	an orthogonal protocol exists which can supply this
				knowledge as to the destination set?
			o	the destination-set is determined based on a service
				discovery mapping (e.g. "Send this to all gateways")?

	c)	If an orthogonal protocol exists, it should be referenced, if the WG
		intends to develop a "service discovery protocol" it should likewise
		be listed explicitly.

	d)	This "point to multipoint" delivery semantics seems a departure from
		classic unicast and multicast. Note, I am not suggesting that it is  
not
		of relevance and necessitating further reflections, simply  
observing that
		this is not a usual delivery semantics for IP networks.

	e)	The "point-to-multipoint" characteristics is brought forward
		as an important factor in ROLL networks, and is not a "classic"
		data delivery model for IP -- yet:

			o	the work items do not include definition of this "roll-cast"
				delivery semantics, including the impact this would have
				in an IP network (e.g. "how would a routing table look?" for
				such "roll-cast";

			o	the work items do not include specification of a protocol
				which accomplishes this "roll-cast".


(ii)	Applicability of existing IETF protocols

	The proposed charter reads:
		
			"These specific properties cause LLNs to have specific routing
			requirements.
			As shown in a protocol survey existing routing protocols (in their  
current
			form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific
			routing requirements."

	Comments:

	a)	Since the WGLC of this protocol survey document draft-ietf-roll- 
protocols-survey
		there have been a large amount of discussion and issues raised,  
some of which
		have raised questions regarding if indeed the above conclusion can  
be drawn
		based on this document.

		I am not taking a position on if the conclusion is justified or not  
in this email,
		however I note that there were a number of issues and questions  
raised on
		this topic on [e-mail], and that it is my impression that  
these have not all
		been closed.
		
	b)	It therefore appears advisable to, before presenting this as a  
fundamental
		assumption for the continued work of the roll working group, resolving
		the issues regarding draft-ietf-roll-protocols-survey.

(iii)	Protocol work

	The proposed charter reads:

			"Protocol work: In light of the application specific routing
			requirements, the Working Group will either specify a
			new protocol and/or will select an existing
			routing protocol (with the appropriate extensions in
			cooperation with the relevant Working Group)."

	Comments:

	a)	The working group has produced a set of 4 application specific  
requirements
		I-Ds,
			-	draft-ietf-roll-urban-routing-reqs
			-	draft-ietf-roll-indus-routing-reqs
			-	draft-ietf-roll-home-routing-reqs
			-	draft-ietf-roll-building-routing-reqs

		These are relatively diverse and verbose.

	b)	The current and proposed charter does not stipulate if one or  
multiple (up to 4?)
		distinct protocols are to be developed for routing in each of these  
application
		specific scenarios.

	c)	Conversely, the current and proposed charter does not include  
among the work
		items to identify and extract, from these application specific  
scenario descriptions,
		a common set of requirements that will guide the protocol design.

	d)	On the same token, protocol design is often a matter of making  
acceptable
		trade-offs. For example, routing protocols often trade off the  
overhead of control
		traffic, state necessary for representing the network topology and  
computational
		power for calculating routing paths, for the benefit of providing  
shortest-paths for
		data traffic.

		The protocol survey document  draft-ietf-roll-protocols-survey, as  
well as the four
		application specific requirements documents listed above, does not  
make it clear
		what acceptable trade-offs are for ROLL networks, and so it is  
difficult to extract
		what proposed protocols make the right or the wrong trade-offs.


(iv)	Timeline and milestones

	The proposed charter has as its final milestone for the protocol to  
be developed:

				Feb 2010   Submit the ROLL routing protocol specification to the  
IESG as
				Proposed Standard.

	a)	I realize that milestones first and foremost are a contract  
between the ADs and the
		WG; still I feel that as such may be used to set the pace for the  
working group, and
		so I make a couple of comments hereon.

	b)	Considering the amount of work to be undertaken, the diverse  
application scenario,
		and the fact that at present only a single an recently submitted  
protocol proposal (-00
		individual submission) exists, less than a year for a protocol to  
be proposed, tested,
		understood well enough and widely enough to reach consensus and  
developed to
		the point of attaining the maturity of a proposed standard is, at  
best, very very optimistic.

	c)	I note that Dave Ward, as AD for roll, said on the [e-mail]  
mailing list as recent as
		February 3:

			``I expect "wild swings" of the design pattern of the protocol  
during the first year
			of the design effort. I attempted to make this clear at the mic in  
Minneapolis that
			the current trajectory is very complex problem domain that hasn't  
born a lot of fruit
			but, that in the design phase reducing the complexity must occur. ''

		I find myself to be in agreement with this statement: I would  
expect the first year
		to be an exercise in narrowing down the complexity and evaluate  
potentially
		many different proposals and approaches at developing a protocol  
(set) for the roll
		problem space, and that protocol maturity would follow once these  
"wild swings" had
		dampened.

Hope this helps,

Thomas



On 4Mar , 2009, at 16:39 , IESG Secretary wrote:

> A modified charter has been submitted for the Routing Over Low  
> power and
> Lossy networks working group in the Routing Area of the IETF.  The  
> IESG
> has not made any determination as yet.  The modified charter is  
> provided
> below for informational purposes only.  Please send your comments  
> to the
> IESG mailing list ([e-mail]) by Wednesday, March 11, 2009.
>
> Routing Over Low power and Lossy networks (roll)
> ==================================================
> Last Modified: 2009-02-04
>
> Current Status: Active Working Group
>
> Additional information is available at tools.ietf.org/wg/roll
>
> Chair(s):
>
> JP Vasseur <[e-mail]>
> David Culler <[e-mail]>
>
> Routing Area Director(s):
>
> Ross Callon <[e-mail]>
> David Ward <[e-mail]>
>
> Routing Area Advisor:
> David Ward <[e-mail]>
>
> Mailing Lists:
>
> General Discussion: [e-mail]
> To Subscribe: http://www.ietf.org/mailman/listinfo/roll
> Archive: http://www.ietf.org/mail-archive/web/roll/
>
> Description of Working Group:
>
> Low power and Lossy networks (LLNs) are made up of many
> embedded devices with limited power, memory, and processing
> resources. They are interconnected by a variety of links, such as
> IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low
> power PLC (Powerline Communication) links. LLNs are transitioning
> to an end-to-end IP-based solution to avoid the problem of
> non-interoperable networks interconnected by protocol translation
> gateways and proxies.
>
> Generally speaking, LLNs have at least five distinguishing
> characteristics:
> - LLNs operate with a hard, very small bound on state.
> - In most cases, LLN optimize for saving energy.
> - Typical traffic patterns are not simply unicast flows (e.g. in some
> cases
>   most if not all traffic can be point to multipoint).
> - In most cases, LLNs will be employed over link layers with  
> restricted
>   frame-sizes, thus a routing protocol for LLNs should be specifically
> adapted
>   for such link layers.
> - LLN routing protocols have to be very careful when trading off
> efficiency
>   for generality; many LLN nodes do not have resources to waste.
>
> These specific properties cause LLNs to have specific routing
> requirements.
> As shown in a protocol survey existing routing protocols (in their  
> current
>
> form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific
> routing requirements.
>
> The Working Group is focused on routing issues for LLN.
>
> There is a wide scope of application areas for LLNs, including  
> industrial
>
> monitoring, building automation (HVAC, lighting, access control,  
> fire),
> connected homes, healthcare, environmental monitoring, urban sensor
> networks (e.g. Smart Grid), asset tracking. The Working Group focuses
> on routing solutions for a subset of these: industrial, connected  
> home,
> building and urban sensor networks for which routing requirements have
> been specified. These application-specific routing requirement  
> documents
> will be used for protocol design.
>
> The Working Group focuses only on IPv6 routing architectural framework
> for these application scenarios. The Framework will take into
> consideration
> various aspects including high reliability in the presence of time  
> varying
> loss
> characteristics and connectivity while permitting low-power  
> operation with
>
> very modest memory and CPU pressure in networks potentially comprising
> a very large number (several thousands) of nodes.
>
> The Working Group will pay particular attention to routing security  
> and
> manageability (e.g., self routing configuration) issues. It will  
> also need
> to
> consider the transport characteristic the routing protocol messages  
> will
> experience. Mechanisms that protect an LLN from congestion collapse or
> that establish some degree of fairness between concurrent  
> communication
> sessions are out of scope of the Working Group. It is expected that
> upper-layer applications utilizing LLNs define appropriate mechanisms.
>
> Work Items:
>
> - Specification of routing metrics used in path calculation. This
> includes
>   static and dynamic link/node attributes required for routing in  
> LLNs.
>
> - Provide an architectural framework for routing and path selection at
>   Layer 3 (Routing for LLN Architecture) that addresses such issues as
>   whether LLN routing require a distributed and/or centralized path
> computation
>   models, whether additional hierarchy is necessary and how it is  
> applied.
>
>   Manageability will be considered with each approach, along with  
> various
>
>   trade-offs for maintaining low power operation, including the  
> presence
>
>   of non-trivial loss and networks with a very large number of nodes.
>
> - Produce a routing security framework for routing in LLNs.
>
> - Protocol work: In light of the application specific routing
> requirements, the
>   Working Group will either specify a new protocol and/or will  
> select an
> existing
>   routing protocol (with the appropriate extensions in cooperation  
> with
> the
>   relevant Working Group).
>
> - Documentation of applicability statement of ROLL routing protocols.
>
> Goals and Milestones:
>
> Done Submit Routing requirements for Industrial applications to the  
> IESG
> to be considered as an Informational RFC.
>
> Done Submit Routing requirements for Connected Home networks  
> applications
> to the IESG to be considered as an Informational RFC.
>
> Done Submit Routing requirements for Building applications to the  
> IESG to
> be considered as an Informational RFC.
>
> Done Submit Routing requirements for Urban networks applications to  
> the
> IESG to be considered as an Informational RFC.
>
> July 2009 Submit Routing metrics for LLNs document to the IESG to be
> considered as a Proposed Standard.
>
> Feb 2009 Submit Protocol Survey to the IESG to be considered as an
> Informational RFC.
>
> April 2009 Submit Security Framework to the IESG to be considered  
> as an
> Informational RFC
>
> May 2009   Submit the Routing for LLNs Architecture document to the  
> IESG
> as an Informational RFC.
>
> July 2009  Submit first draft of ROLL routing protocol  
> specification as
> Proposed Standard.
>
> Nov 2009   Submit first draft of the MIB module of the ROLL routing
> protocol specification.
>
> Feb 2010   Submit the ROLL routing protocol specification to the  
> IESG as
> Proposed Standard.
>
> March 2010 Submit the MIB module of the ROLL routing protocol
> specification to the IESG as Proposed Standard.
>
> April 2010 Evaluate WG progress, recharter or close.
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll