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

From: IESG Secretary <[email-masked]>
Date: Wed, 4 Mar 2009 07:39:27 -0800 (PST)

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 ([email-masked]) 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 <[email-masked]> 
David Culler <[email-masked]> 

Routing Area Director(s):

Ross Callon <[email-masked]> 
David Ward <[email-masked]> 

Routing Area Advisor:
David Ward <[email-masked]> 

Mailing Lists:

General Discussion: [email-masked]
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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 11:52:52 +0100

IESG Secretary a écrit :
[...]

> 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).

This is too unclear for a Charter: specify new?  or select existing?

The world is not short of routing protocols in general, and routing 
protocols in particular for these types of dynamic wireless networks. 
MANET - OLSR TBRPF DYMO, NEMO - many RO drafts - all come to mind.

Alex

> Done Submit Routing requirements for Industrial applications to the
> 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
> Done Submit Routing requirements for Urban networks applications 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.
> 
> Feb 2010   Submit the ROLL routing protocol specification to the IESG
> as Proposed Standard.
> 
> _______________________________________________ IETF-Announce mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 5 Mar 2009 17:54:24 +0100

Hi all,

The ROLL WG targets to operate IP under constraints that are clearly harsher
than usual within the IETF, similar only to extreme forms of network
addressed by few WGs (such as MANET or 6LOWPAN).

As far as I understand, the context in which ROLL aims to operate IP is:

- extremely limited RAM
- extremely limited CPU
- extremely limited wireless bandwidth

The typical deployment aimed at by ROLL is:

- thousands of nodes
- no assumptions on the topology

The typical usage of such deployment includes:

- unicast data flows from nodes to border routers
- unicast data flows between nodes
- multicast/flooding/?cast data flows from one node to other nodes

The proposed charter yields a slew of work-items in this context,
based on the above and on some of the applications requirements
listed in the WG documents that are currently under IESG review.

The exact set of targeted requirements are unfortunately not explicitly
mentioned in the charter, nor in any other document. However,
the work-items that are explicitly or implicitly evoked in the proposed
charter, include the following:

- self-configuration protocols in order to be "IP-ready"
and "routing-ready",
- unicast routing protocols,
- multicast/flooding/?cast (to be defined) routing protocols,
- multi-homing mechanisms/protocols,
- elaboration of metrics for wireless links,
- securing all of the above with additional mechanims/protocols,
- doing all of the above with real-time constraints (to be defined) with
additional mechanims/protocols,

While this list is already impressive  (especially within the currently
proposed time-frame),
it may not be exact or exhaustive, depending on which set of requirements
are indeed targeted.

For this reason, it seems to me that the highest priority is to clarify this
point as soon as possible. And by this I mean document:

- the precise list of requirements that are targeted within the proposed
time-frame,

- the precise list the operation conditions, deployment & usage scenarios
that are being targeted within the proposed time-frame (the charter would
benefit from some additional effort put into setting some limits for
targeted RAM and CPU, as well as more precision concerning the targeted
traffic patterns),

- the precise list the work-items that are targeted within the proposed
time-frame (here, for instance, the charter would benefit from some
additional effort put into defining what multicast/flooding/?cast is, what
real-time means for ROLL, and what additional work-item(s) they entails).

As a ROLL participant, it is necessary and urgent for me to have these
details in order to carry out further work on protocol design.

Regards,
Emmanuel

On Wed, Mar 4, 2009 at 4:39 PM, IESG Secretary <[email-masked]>wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 5 Mar 2009 18:25:11 +0100

Hi Emmanuel,

Thanks for your comments - see below.

On Mar 5, 2009, at 5:54 PM, Emmanuel Baccelli wrote:

> Hi all,
>
> The ROLL WG targets to operate IP under constraints that are clearly  
> harsher than usual within the IETF, similar only to extreme forms of  
> network addressed by few WGs (such as MANET or 6LOWPAN).
>
> - self-configuration protocols in order to be "IP-ready" and  
> "routing-ready",
> - doing all of the above with real-time constraints (to be defined)  
> with additional mechanims/protocols,
>
>
> While this list is already impressive  (especially within the  
> currently proposed time-frame),
> it may not be exact or exhaustive, depending on which set of  
> requirements are indeed targeted.
>
> - the precise list of requirements that are targeted within the  
> proposed time-frame,

The WG has produced 4 very detailed routing requirements written  
experts in the field. I think that we now have all the requirements.

>
> - the precise list the operation conditions, deployment & usage  
> scenarios that are being targeted within the proposed time-frame  
> (the charter would benefit from some additional effort put into  
> setting some limits for targeted RAM and CPU, as well as more  
> precision concerning the targeted traffic patterns),

Applicability statements is an excellent idea and I do agree with you.  
This is one of the new WG items:
- Documentation of applicability statement of ROLL routing protocols.

>
> - the precise list the work-items that are targeted within the  
> proposed time-frame (here, for instance, the charter would benefit  
> from some additional effort put into defining what multicast/ 
> flooding/?cast is, what real-time means for ROLL, and what  
> additional work-item(s) they entails).
>
>
> As a ROLL participant, it is necessary and urgent for me to have  
> these details in order to carry out further work on protocol design.
>

Please read the requirements documents, they provide a lot of data. Of  
course, more discussion will take place on the list as we move forward.

Thanks.

JP.

>
> Regards,
> Emmanuel
>
>
>
>
>
>
>
> On Wed, Mar 4, 2009 at 4:39 PM, IESG Secretary <[email-masked] 
> > wrote:
> IESG
> applications
> an
> as

---

From: "Childress, Steve" <[email-masked]>
Date: Thu, 5 Mar 2009 09:28:55 -0800

If ROLL would benefit from a real use case, drawn from a current/funded
project, needing high density mesh, battery powered routers, we'd be
glad to elaborate. It was presented in summary form at the most recent
IEEE 802.15 and ISA 100 conferences.
 
steve childress

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
JP Vasseur
Sent: Thursday, March 05, 2009 9:25 AM
To: Emmanuel Baccelli
Cc: ROLL WG; David E. Culler; [email-masked]; IETF Announcement list
Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and
Lossynetworks (roll)

Hi Emmanuel, 

	
	Hi all,

	The ROLL WG targets to operate IP under constraints that are
clearly harsher than usual within the IETF, similar only to extreme
forms of network addressed by few WGs (such as MANET or 6LOWPAN).

	As far as I understand, the context in which ROLL aims to
operate IP is:

	- extremely limited RAM
	- extremely limited CPU

	- thousands of nodes

	- unicast data flows from nodes to border routers
	- unicast data flows between nodes
	- multicast/flooding/?cast data flows from one node to other
nodes

	The proposed charter yields a slew of work-items in this
context,
	based on the above and on some of the applications requirements
	listed in the WG documents that are currently under IESG review.

	The exact set of targeted requirements are unfortunately not
explicitly
	mentioned in the charter, nor in any other document. However, 
	the work-items that are explicitly or implicitly evoked in the
proposed
	charter, include the following:

	- self-configuration protocols in order to be "IP-ready" and
"routing-ready",
	- unicast routing protocols,
	- multicast/flooding/?cast (to be defined) routing protocols,
	- multi-homing mechanisms/protocols,
	- elaboration of metrics for wireless links,
	- securing all of the above with additional mechanims/protocols,
	- doing all of the above with real-time constraints (to be
defined) with additional mechanims/protocols,

	For this reason, it seems to me that the highest priority is to
clarify this
	point as soon as possible. And by this I mean document:

The WG has produced 4 very detailed routing requirements written experts
in the field. I think that we now have all the requirements.

	- the precise list the operation conditions, deployment & usage
scenarios that are being targeted within the proposed time-frame (the
charter would benefit from some additional effort put into setting some
limits for targeted RAM and CPU, as well as more precision concerning
the targeted traffic patterns),

	

	- the precise list the work-items that are targeted within the
proposed time-frame (here, for instance, the charter would benefit from
some additional effort put into defining what multicast/flooding/?cast
is, what real-time means for ROLL, and what additional work-item(s) they
entails).

Thanks.

JP.

	Regards,
	Emmanuel

	On Wed, Mar 4, 2009 at 4:39 PM, IESG Secretary
<[email-masked]> 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 ([email-masked]) by Wednesday, March
11, 2009.

		
		Additional information is available at
tools.ietf.org/wg/roll
		
		Chair(s):

		
		
		Routing Area Advisor:
		
		Mailing Lists:

		
		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.

		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.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 5 Mar 2009 18:36:48 +0100

Thanks Steve for the offer. We'll get in touch with you soon.

Cheers.

JP.

On Mar 5, 2009, at 6:28 PM, Childress, Steve wrote:

> If ROLL would benefit from a real use case, drawn from a current/ 
> funded project, needing high density mesh, battery powered routers,  
> we'd be glad to elaborate. It was presented in summary form at the  
> most recent IEEE 802.15 and ISA 100 conferences.
>
> steve childress
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of JP Vasseur
> Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power  
> and Lossynetworks (roll)
>
> Hi Emmanuel,
>
> Applicability statements is an excellent idea and I do agree with  
> you. This is one of the new WG items:
> Please read the requirements documents, they provide a lot of data.  
> Of course, more discussion will take place on the list as we move  
> forward.
>
> Thanks.
>
> JP.
>
>>
>> Regards,
>> Emmanuel
>>
>>
>>
>>
>>
>>
>>

---

From: Kris Pister <[email-masked]>
Date: Thu, 05 Mar 2009 21:27:02 -0800

I would imagine that all of the authors of the routing requirements 
document would agree,
but speaking only for myself, I'd like to say

GREAT!!!

Let's recharter and get to work!

ksjp

---

From: Tim Winter <[email-masked]>
Date: Fri, 06 Mar 2009 10:37:22 -0500

I am in support of the modified charter.

The ROLL WG has covered a lot of ground in examining the requirements of an
LLN routing protocol with respect to various applications, and the protocol
survey effort does indicate that no existing IETF protocol without
modification will be a good fit for the requirements.

The modified charter will allow the WG to continue with its current
momentum and either specify modifications to an existing IETF protocol or a
new protocol in order to meet the demand of industry.

-Tim

IESG Secretary wrote:
> IETF-Announce mailing list
> [email-masked]

---

From: Philip Levis <[email-masked]>
Date: Fri, 6 Mar 2009 09:19:20 -0800

> new protocol in order to meet the demand of industry.

I also support the modified charter. I look forward to working in ROLL  
to help define the routing standards for LLNs. JP and others, thanks  
so much for incorporating all of the comments and feedback so quickly.

Phil

---

From: Arsalan Tavakoli <[email-masked]>
Date: Fri, 6 Mar 2009 09:26:12 -0800

I also support the modified charter; I think it does a good job of capturing
what ROLL should be doing, and I look forward to moving into the next stage
of the process.
- Arsalan

On Fri, Mar 6, 2009 at 9:19 AM, Philip Levis <[email-masked]> wrote:

> I also support the modified charter. I look forward to working in ROLL to
> help define the routing standards for LLNs. JP and others, thanks so much
> for incorporating all of the comments and feedback so quickly.
>
> Phil
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Mar 2009 18:33:34 +0100

> new protocol in order to meet the demand of industry.

What do you mean: specify modifications to existing protocol or new 
protocol?  Both?  Only one?

What's the goal of this ambiguous language?

Alex

---

From: Arsalan Tavakoli <[email-masked]>
Date: Fri, 6 Mar 2009 09:38:53 -0800

Comments inline.

> What's the goal of this ambiguous language?

I don't understand how this is ambiguous.  As has been discussed
consistently, ROLL needs a specification for a routing protocol, and this
specification can stem from modifications to an existing IETF protocol, or
from something new altogether; no stance is taken on which one it should be
(and hence the 'ambiguous' text), and I presume that when we move to the
next stage proposals of both of these types will be put forward, allowing
the working group to debate their merits.

- Arsalan

---

From: Omprakash Gnawali <[email-masked]>
Date: Fri, 6 Mar 2009 09:47:59 -0800

I support the modified charter. Lots of work to do. Lets get started.

- om_p

---

From: Dominik Kaspar <[email-masked]>
Date: Fri, 6 Mar 2009 19:00:49 +0100

I am also in favor of the modified charter.

Dominik

---

From: "M. B. Anand" <[email-masked]>
Date: Fri, 06 Mar 2009 13:04:37 -0500

I support this re-charter for ROLL.

The proposed text has gone through a lot of review on the ROLL list and 
incorporation of comments. And there are many participants waiting, 
ready and willing to contribute to the work ahead . Let's move ahead.

Regards,
Anand.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Mar 2009 19:11:41 +0100

Arsalan Tavakoli a écrit :
> Comments inline.
> 
> On Fri, Mar 6, 2009 at 9:33 AM, Alexandru Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Tim Winter a écrit :
> 
> consistently, ROLL needs a specification for a routing protocol, and 
> this specification can stem from modifications to an existing IETF 
> protocol, or from something new altogether; no stance is taken on which 
> one it should be (and hence the 'ambiguous' text), and I presume that 
> when we move to the next stage proposals of both of these types will be 
> put forward, allowing the working group to debate their merits.

What next stage?  Another round of protocols-survey to definitely answer 
debates before the July milestone "first draft of ROLL routing protocol 
spec"?

The protocols-survey draft was Last Call'ed, I suppose it will be sent 
soon to IESG (I haven't seen the write-up).  Do you mean another 
protocol evaluation document?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Mar 2009 19:14:27 +0100

Ah this impatience spells risks to me...

Lots of reviews?  HAs the multicast/multipoint been disambiguated?

What does 'multipoint' mean please?

Alex

M. B. Anand a écrit :
>> JP Vasseur <[email-masked]> David Culler <[email-masked]>
>> Ross Callon <[email-masked]> David Ward <[email-masked]>
>> Routing Area Advisor:
>> 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.
>> characteristics: - LLNs operate with a hard, very small bound on state.
>> 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.
>>
>> requirements. As shown in a protocol survey existing routing protocols 
>> (in their current
>>  
>> 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.
>>
>> consideration various aspects including high reliability in the 
>> presence of time varying
>> loss characteristics and connectivity while permitting low-power 
>> operation with
>>  
>> 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:
>>
>> includes   static and dynamic link/node attributes required for 
>> routing in LLNs.
>>
>> computation   models, whether additional hierarchy is necessary and 
>> how it is applied.
>>  
>> and/or will select an
>> existing   routing protocol (with the appropriate extensions in 
>> cooperation with
>> the   relevant Working Group).
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Mar 2009 19:49:38 +0100

Arsalan Tavakoli a écrit :
> 
> 
> On Fri, Mar 6, 2009 at 10:11 AM, Alexandru Petrescu 
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>            Tim Winter a écrit :
> 
>                LLN routing protocol with respect to various
>         applications, and
>                the protocol
>         consistently, ROLL needs a specification for a routing protocol,
>         and this specification can stem from modifications to an
>         existing IETF protocol, or from something new altogether; no
>         stance is taken on which one it should be (and hence the
>         'ambiguous' text), and I presume that when we move to the next
>         stage proposals of both of these types will be put forward,
>         allowing the working group to debate their merits.
> 
> 
>     What next stage?  Another round of protocols-survey to definitely
>     answer debates before the July milestone "first draft of ROLL
>     routing protocol spec"?
> 
>     The protocols-survey draft was Last Call'ed, I suppose it will be
>     sent soon to IESG (I haven't seen the write-up).  Do you mean
>     another protocol evaluation document?
> 
>     Alex
> 
> 
> There is only one protocols-survey, and that has been last called.  The 
> next stage is where ROLL must put forth a protocol specification (and 
> possibly more than one),

Do you mean something like this:

(1) _the_ ROLL protocol - WG item
(2) OLSR-adaptation to make it look like the ROLL protocol - a WG item
(3) DYMO-adaptation for same goal
(4) NEMO-adaptation same

Is it this?

Alex

---

From: JP Vasseur <[email-masked]>
Date: Fri, 6 Mar 2009 20:24:15 +0100

Dear Alex,

As you can see on the list, there is a good number of people  
supporting the new charter and for whom the next stage is clear. Let  
me restate the situation one more time (note that both co-chairs did  
this many many times already) and there is a good consensus. Note also  
that we addressed your points during the review of the WG charter,  
before submitting the proposal to the IESG and it looks like we are  
restarting again.

Anyway let me try one last time.

1) We were tasked to first clearly spell out the ROLL routing  
requirements: all of them are in publication request, under IESG  
review with a very good WG consensus.
2) We had to evaluate whether we could find an existing routing  
protocols that would meet our requirements (the protocol survey), this  
was the only purpose of this document. Again we had a good consensus,  
the answer being that there is no existing routing protocols  
satisfying the specific routing requirements of ROLL.
3) As pointed out MANY times on the list, this does not mean that an  
existing protocol could not be extended (e.g. MANET, ...) to satisfy  
these requirement. At this stage we are not chartered to do any  
protocol work, thus the proposal for rechartering. Thus the new  
proposed charter explicitly states that we could either adapt an  
existing protocol or design a new routing protocol. At this stage we  
will go back to the routing requirements documents of course.  
Otherwise, what would be the point of having worked for months on  
these requirements that have been written by recognized expert in the  
field.

What comes next ?

1) Wait until we get the re-chartering green light from the IESG.
2) Start working on protocol specification in light of the  
requirements. Nothing different than any regular WG.
3) If we have multiple candidates, the WG will select a solution,  
based on consensus.

The reason why you see so many people get a bit impatient is because  
we have an excellent dynamic in this WG, with lots of recognized  
experts in sensors and routing, we all agree on the requirements and  
we now need to move forward because the industry is waiting for an IP- 
based solution. Bear in mind that this is the objective, the work  
group is not putting so much effort for the sake of an intellectual  
exercise but because products are being design and a routing solution  
is required.

If this is still not clear, I'll be happy to spend some time with you  
in SFO.

Thanks.

JP.

On Mar 6, 2009, at 7:11 PM, Alexandru Petrescu wrote:

>> On Fri, Mar 6, 2009 at 9:33 AM, Alexandru Petrescu <[email-masked] 
>>  <mailto:[email-masked]>> wrote:
>>    Tim Winter a écrit :
>> and this specification can stem from modifications to an existing  
>> IETF protocol, or from something new altogether; no stance is taken  
>> on which one it should be (and hence the 'ambiguous' text), and I  
>> presume that when we move to the next stage proposals of both of  
>> these types will be put forward, allowing the working group to  
>> debate their merits.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Mar 2009 21:14:49 +0100

[SFO - I won't be there, sorry, maybe next time.]

JP thanks for the explanation of the procedure.  As you put it sounds 
reasonable, except this quirk (and another posted separately).

Requirements - then I will look again at the recently demanded feedback.

('experts' - I hear it as an overly elitist, touching arrogance, yet
  necessary attitude one has to label self before talking Routing.
  And I don't agree with it, please don't mention it.  Rant off.)

Alex

JP Vasseur a écrit :
>  this many many times already) and there is a good consensus. Note 
> also that we addressed your points during the review of the WG 
> charter, before submitting the proposal to the IESG and it looks like
>  we are restarting again.
> 
> review with a very good WG consensus. 2) We had to evaluate whether 
> we could find an existing routing protocols that would meet our 
> requirements (the protocol survey), this was the only purpose of this
>  document. Again we had a good consensus, the answer being that there
>  is no existing routing protocols satisfying the specific routing 
> requirements of ROLL. 3) As pointed out MANY times on the list, this
>  does not mean that an existing protocol could not be extended (e.g.
>  MANET, ...) to satisfy these requirement. At this stage we are not 
> chartered to do any protocol work, thus the proposal for 
> rechartering. Thus the new proposed charter explicitly states that we
>  could either adapt an existing protocol or design a new routing 
> protocol. At this stage we will go back to the routing requirements 
> documents of course. Otherwise, what would be the point of having 
> worked for months on these requirements that have been written by 
> recognized expert in the field.
> 
> What comes next ?
> 
> 1) Wait until we get the re-chartering green light from the IESG. 2)
>  Start working on protocol specification in light of the
> requirements. Nothing different than any regular WG. 3) If we have
> multiple candidates, the WG will select a solution, based on
> consensus.
> 
>  we now need to move forward because the industry is waiting for an 
> IP-based solution. Bear in mind that this is the objective, the work
>  exercise but because products are being design and a routing
> solution is required.
> 
>>> Comments inline. On Fri, Mar 6, 2009 at 9:33 AM, Alexandru 
>>> Petrescu <[email-masked] 
>>> <mailto:[email-masked]>> wrote: Tim Winter a écrit
>>>  : I am in support of the modified charter. The ROLL WG has 
>>> covered a lot of ground in examining the requirements of an LLN 
>>> routing protocol with respect to various applications, and the 
>>> protocol survey effort does indicate that no existing IETF 
>>> protocol without modification will be a good fit for the 
>>> requirements. The modified charter will allow the WG to continue
>>>  with its current momentum and either specify modifications to an
>>>  existing IETF protocol or a new protocol in order to meet the 
>>> demand of industry. What do you mean: specify modifications to 
>>> existing protocol or new protocol?  Both?  Only one? What's the 
>>> goal of this ambiguous language? Alex I don't understand how this
>>>  is ambiguous.  As has been discussed consistently, ROLL needs a
>>>  specification for a routing protocol, and this specification can
>>>  stem from modifications to an existing IETF protocol, or from 
>>> something new altogether; no stance is taken on which one it 
>>> should be (and hence the 'ambiguous' text), and I presume that 
>>> when we move to the next stage proposals of both of these types 
>>> will be put forward, allowing the working group to debate their 
>>> merits.
>> 
>> _______________________________________________ Roll mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
> 
>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 6 Mar 2009 21:43:26 +0100

> [SFO - I won't be there, sorry, maybe next time.]

Sure.

>
>
> JP thanks for the explanation of the procedure.  As you put it  
> sounds reasonable, except this quirk (and another posted separately).
>

OK glad that we are in sync.

> And I don't agree with it, please don't mention it.  Rant off.)

There was no intention of elitism or arrogance, an "expert" is usually  
known was someone with a deep knowledge in some area and a strong  
understanding of the requirements and solutions, that's all.

Thanks.

JP.

>>>> Petrescu <[email-masked] <mailto:[email-masked] 
>>>> >> wrote: Tim Winter a écrit
>>> _______________________________________________ Roll mailing list [email-masked]

---

From: Jaudelice de Oliveira <[email-masked]>
Date: Sat, 7 Mar 2009 16:44:58 -0500

I also want to express my support of the modified charter.

The protocol survey indicated that a new/modified protocol is needed  
and we should move on with the items in the modified charter as the  
need for a standard is quite pressing!

Jau.

On Mar 6, 2009, at 12:19 PM, Philip Levis wrote:

> I also support the modified charter. I look forward to working in  
> ROLL to help define the routing standards for LLNs. JP and others,  
> thanks so much for incorporating all of the comments and feedback  
> so quickly.
>
> Phil

---

From: Jaudelice de Oliveira <[email-masked]>
Date: Sat, 7 Mar 2009 15:21:25 -0500

I also want to express my support for the modified charter.

Jau.

---

From: Arsalan Tavakoli <[email-masked]>
Date: Fri, 6 Mar 2009 10:32:11 -0800

On Fri, Mar 6, 2009 at 10:11 AM, Alexandru Petrescu <
[email-masked]> wrote:

>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>    Tim Winter a écrit :
>>
> The protocols-survey draft was Last Call'ed, I suppose it will be sent soon
> to IESG (I haven't seen the write-up).  Do you mean another protocol
> evaluation document?
>
> Alex

There is only one protocols-survey, and that has been last called.  The next
stage is where ROLL must put forth a protocol specification (and possibly
more than one), that meets the requirements laid out in the protocol-survey
and will be embraced as the standard routing protocol for ROLL applications.

- Arsalan

---

From: Philip Levis <[email-masked]>
Date: Sat, 7 Mar 2009 19:35:19 -0800

Comments inline.

On Mar 6, 2009, at 10:32 AM, Arsalan Tavakoli  
<[email-masked]> wrote:

>
>
> On Fri, Mar 6, 2009 at 10:11 AM, Alexandru Petrescu <[email-masked] 
> > wrote:
> protocol, or from something new altogether; no stance is taken on  
> which one it should be (and hence the 'ambiguous' text), and I  
> There is only one protocols-survey, and that has been last called.   
> The next stage is where ROLL must put forth a protocol specification  
> (and possibly more than one), that meets the requirements laid out  
> in the protocol-survey and will be embraced as the standard routing  
> protocol for ROLL applications.
>
> - Arsalan
>
>

This is not quite right.  Protocols need to meet the requirements of  
the application documents.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Mar 2009 14:45:33 +0100

Dear chairs:

The revisited charter is already very clear and specific and I
definitely support it.

This being said, I'd appreciate a little clarification:

If the architectural framework ends up allowing for both centralized and
distributed, and/or even a hybrid of those, then we might end up with 2
protocols that make equal sense, or a suite of protocol bricks that
might be assembled in various fashions depending on the specific case we
are looking at, e.g. industrial vs. building. 

I understand that the "Protocol work" does not absolutely constrain to a
single protocol, or does it?
 
Pascal

>-----Original Message-----
>From: [email-masked]
[mailto:[email-masked]] On Behalf Of IESG Secretary
>Sent: mercredi 4 mars 2009 16:39
>To: IETF Announcement list
>Cc: [email-masked]; [email-masked]
>Subject: WG Review: Recharter of Routing Over Low power and Lossy
networks (roll)
IESG
applications
IESG
as

---

From: JP Vasseur <[email-masked]>
Date: Mon, 9 Mar 2009 15:05:12 +0100

Hi Pascal,

> single protocol, or does it?

Correct.

Thanks.

JP.

>> restricted
>> fire),
>> and

---

From: Bernard Tourancheau <[email-masked]>
Date: Mon, 9 Mar 2009 18:00:18 +0100

Hi all,
I support this rechartering too.
Regards,
Bernard.

--
LIP / ENS-Lyon
INRIA Rhone-Alpes, France

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 9 Mar 2009 11:52:43 -0700

I support this charter as well.
Thanks,
-Samita

> > 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 ([email-masked]) by Wednesday, March
> > 11, 2009.
> >
> > presence of time varying loss characteristics and connectivity while
> > permitting low-power operation with
> >
> > 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:
> >
> >   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).
> >
> > Done Submit Routing requirements for Building applications to the IESG

---

From: Adam Dunkels <[email-masked]>
Date: Tue, 10 Mar 2009 12:38:08 +0100

I chime in and support the charter.

/adam

-- 
Adam Dunkels <[email-masked]>, +46707731614
http://www.sics.se/~adam/

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 10 Mar 2009 13:17:51 +0100

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
		[email-masked] 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 [email-masked], 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 [email-masked]  
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:

> with

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 11 Mar 2009 17:37:53 -0000

The nature of the routing protocol to be created still
is not clear to me.

The comments about point to multipoint are under the nature
of the networks, not under the description of the work to
be done. If this were the only issue, that would be less than
ideal, but tolerable. But on the other hand a whole load of
effort was spent discussing unicast routing protocols, from
which one could have drawn the conclusion that is what's
wanted, even if the specific existing protocols aren't
appropriate. The combination of the two leads to a definite
lack of clarity.

All I would suggest (before getting on with the work) is that
in the future work section it is clarified, with just one
sentence perhaps, whether the group is working on:

(a) A unicast routing protocol.
(b) A IP-style multicast routing protocol.
(c) A source-driven point to multipoint routing protocol.
(d) Another distribution option I've not listed.
(e) One or more protocols doing more than one of (a) to (d).
(f) Working out which of (a) to (e) is an early work item.

If everyone is clear on what's to be done, then it should take
no time at all to pick appropriate wording for which of these
is the case, drop it in, and all will be agreed.

(I also think the timescale is definitely optimistic, but if it
can be done, without cutting unacceptable corners - which will
itself tend to cause delays anyway - fine. If not, well, this
wouldn't be the first IETF WG to overrun.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Mar 2009 22:14:34 +0100

Dearlove, Christopher (UK) a écrit :
> The nature of the routing protocol to be created still is not clear 
> to me.
> 
> The comments about point to multipoint are under the nature of the 
> networks, not under the description of the work to be done. If this 
> were the only issue, that would be less than ideal, but tolerable.

I think it is a big issue here because 802.15.4 (a silently but strongly
considered link) doesn't have link-layer multicast support.  Of
course, adding link-layer multicast support to 802.15.4 wouldn't be done 
at  IETF.  Of course too - if it existed it could help a lot ROLL. 
Which turns in circles.

Getting out of it could be by ack'ing the practical IP point-to-point 
links: they solved many similar problems in the recent past (UMTS, 
802.16 CS, IPv6-over-RS232, to name a few).

> But on the other hand a whole load of effort was spent discussing 
> unicast routing protocols,

I'm not sure even about 'unicast' routing protocols... a routing
protocol often qualified as 'unicast' (e.g. OSPF as opposed to M-OSPF,
or M-BGP) is actually _using_ multicast delivery of messages - is OSPF
unicast or multicast?  Doubt doubt.

> from which one could have drawn the conclusion that is what's wanted,
>  even if the specific existing protocols aren't appropriate. The 
> combination of the two leads to a definite lack of clarity.
> 
> All I would suggest (before getting on with the work) is that in the
>  future work section it is clarified, with just one sentence perhaps,
>  whether the group is working on:
> 
> (a) A unicast routing protocol. (b) A IP-style multicast routing 
> protocol. (c) A source-driven point to multipoint routing protocol.

Why not saying source-routing instead of pt-to-mpt routing protocol?  Or
better yet - anycast?  What's a routing protocol anyways...

> (d) Another distribution option I've not listed. (e) One or more 
> protocols doing more than one of (a) to (d). (f) Working out which of
>  (a) to (e) is an early work item.
> 
> If everyone is clear on what's to be done, then it should take no 
> time at all to pick appropriate wording for which of these is the 
> case, drop it in, and all will be agreed.

I fully agree on this part - if everyone is clear on what's to be done
it shouldn't take any time at all to pick the wording.

Alex