Subject: [Roll] RPL Status

From: JP Vasseur <[email-masked]>
Date: Tue, 18 May 2010 11:47:41 +0200

Dear WG,

Here is a quick status. First, we would like to thank the WG again for  
the continuous effort and lots of fruitful and productive work ! As  
discussed in Anaheim, the plan is still to Last Call RPL before the  
next IETF. The plan is to release the next revision of the RPL I-D by  
end of next week. Rev-08 will  address the following:

1) Security section (integrating the work on the security DT)
2) New DAO mechanism (cleaner and more simple), as agreed on the  
Mailing List
3) Basic source routing  => See also companion drafts to be published  
very soon for (RH-0 like)
4) Updated manageability section
5) DAO ACK
6) Trickle algorithm removed from the core specification (in a  
separate doc), Examples removed
7) Several Edits, clarifications, ...

I had a discussion with David, and the plan is to have the P2P a  
separate ID (the current RPL specification provides basic P2P, with  
"advanced" P2P defined in that I-D), with the objective to progress  
both documents in parallel.

What else ?
We need to progress a few other documents:
1) Use of the RPL TLV: see draft-hui-6man-rpl-option (6man WG)
2) Source routing header (RH-0 like): to be published soon (Jonathan/ 
David)
3) RPL Variables (ticket #22)
4) ID related to measurement from P2P (if consensus on Mailing list)

Looking forward to your comments as soon as rev-08 will be published.

Thanks.

JP and David.

---

From: "Anders Brandt" <[email-masked]>
Date: Tue, 18 May 2010 12:11:50 +0200

hi JP

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of JP Vasseur
	Sent: Tuesday, May 18, 2010 11:48
	To: roll WG
	Subject: [Roll] RPL Status

	Dear WG, 

	Here is a quick status. First, we would like to thank the WG
again for the continuous effort and lots of fruitful and productive work
! As discussed in Anaheim, the plan is still to Last Call RPL before the
next IETF. The plan is to release the next revision of the RPL I-D by
end of next week. Rev-08 will  address the following:

	1) Security section (integrating the work on the security DT)
	2) New DAO mechanism (cleaner and more simple), as agreed on the
Mailing List
	3) Basic source routing  => See also companion drafts to be
published very soon for (RH-0 like)
	4) Updated manageability section
	5) DAO ACK
	6) Trickle algorithm removed from the core specification (in a
separate doc), Examples removed
	7) Several Edits, clarifications, ... 

	I had a discussion with David, and the plan is to have the P2P a
separate ID (the current RPL specification provides basic P2P, with
"advanced" P2P defined in that I-D), with the objective to progress both
documents in parallel.  

May I suggest:
(the current RPL specification provides rudimentary P2P, with the
required and sufficient P2P defined in that I-D) 
 
;-)

	What else ?
	We need to progress a few other documents:
	1) Use of the RPL TLV: see draft-hui-6man-rpl-option (6man WG)
	2) Source routing header (RH-0 like): to be published soon
(Jonathan/David)
	3) RPL Variables (ticket #22)
	4) ID related to measurement from P2P (if consensus on Mailing
list)

	Looking forward to your comments as soon as rev-08 will be
published.

	Thanks.

	JP and David.

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 18 May 2010 10:46:42 -0400

> From: JP Vasseur <[email-masked]>
> Date: Tue, 18 May 2010 11:47:41 +0200
> 
> next IETF.

We will have to do something about multicasts (ticket #30).
The multicast text in the current draft has a number of
limitiations; in particular, it requires that all nodes
cache DAOs.

Forwarding multicasts using unicasts makes sense if
relatively few nodes need to receive them.  For a multicast
that needs to get to most or all of a network, using
unicasts seems likely to be both unreliable and inefficient.

                                -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 May 2010 18:12:59 +0200

Hi Richard:

Good point. Would you have a suggestion for the source route world?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Richard Kelsey
> Sent: Tuesday, May 18, 2010 4:47 PM
> To: JP Vasseur
> Cc: [email-masked]
> Subject: Re: [Roll] RPL Status
> 
> The multicast text in the current draft has a number of limitiations;
in
> particular, it requires that all nodes cache DAOs.
> 
> Forwarding multicasts using unicasts makes sense if relatively few
nodes
> need to receive them.  For a multicast that needs to get to most or
all of a
> network, using unicasts seems likely to be both unreliable and
inefficient.
> 
>                                 -Richard Kelsey
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 18 May 2010 14:10:50 -0400

> Date: Tue, 18 May 2010 18:12:59 +0200
> From: "Pascal Thubert (pthubert)" <[email-masked]>
> 
> > Richard Kelsey
> > in particular, it requires that all nodes cache DAOs.
> > 
> > nodesneed to receive them.  For a multicast that needs to get to
> > most or all of a network, using unicasts seems likely to be both
> > unreliable and inefficient.

> Good point. Would you have a suggestion for the source route world?

Pascal,

It's a hard problem.

ZigBee, which has always-on routers, uses hop-limited
flooding for multicasts.  This works well for multicasts
that need to go to all or almost all nodes.

I do not know how multicasts are handled in sensor networks,
where flooding is relatively expensive.

In the source route world, for multicasts with few
subscribers, the simplest thing would to use DAOs
more-or-less as is done for downward routes.  MLD requests
would be forwarded up to the root, and the root would keep
track of which nodes were subscribed to which multicast
addresses.  Multicasts would be also forwarded to the root,
which would unicast them down to subscribers.  I suppose the
root could also make the determination as to which
multicasts could be more effectively flooded.

More complicated schemes are possible, but I don't like more
complicated schemes :-).
                                     -Richard Kelsey

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 18 May 2010 16:56:43 -0700

Hi Richard/JP,

> The multicast text in the current draft has a number of limitiations; in
[SC>]  Ticket #30 is about clarification of text regarding the multicast
operation.
Indeed it is not clear and subject to implementor's interpretation.

> Forwarding multicasts using unicasts makes sense if relatively few nodes
> need to receive them.  For a multicast that needs to get to most or all of
a
inefficient.

[SC>] BTW, is RPL also trying to solve multicast routing/forwarding
completely in all cases ? It might be better to have another id for the
detailed multicast forwarding/routing for all cases (multicast to all nodes
in LLN, multicast to nodes that are spread out under different parents far
from each other and trying communicate with each other etc.). It might be
easier for RPL draft to handle a set of common use cases with the existing
mechanism. I wonder what would be the typical applications today for RPL in
LLN ? Is it in the building network where most of the communication takes
place from one or two parent or grand-parent nodes to their descendants
using a multi-cast address?
That said, we also need to make sure the current multicast mechanism could
be extended to cover other scenarios. 

Actually the current solution of using DAO to store the multicast address
and the corresponding members of the multicast address may work out. But I
agree it is more work on each parent node to aggregate the multicast
addresses, process them and store them and might also make a decision to
prune.

If we consider LLN to be a route-over only link, then modifying MLD
hop-limit and forwarding MLD messages are an option but we still need to
consider pruning.
A generic solution for multicast routing/forwarding in LLN seems to be a
non-trivial problem to be handled in RPL draft alone.

Thanks,
-Samita

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 19 May 2010 09:39:44 +0200

All,
 
>the plan is still to Last Call RPL before the next IETF
 
I would like to poll the WG on this statement.
The home and building requirements are not met by the current RPL draft
and we have not even started discussing the P2P ID mechanisms in detail
-
or frame format modifications for that matter.
 
Does the WG agree that a RPL spec without support for home and building
applications is acceptable?
 
Thanks,
  Anders

	Dear WG, 

	What else ?

	Thanks.

	JP and David.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 May 2010 14:59:12 +0200

Hi Richard:

MLD requests are effectively turned into DAOs and will reach the root as
you suggest. From there, what do we do in source route?

The extremes (global flood/prune and as many unicast from the root) seem
both quite easy and quite expansive when applied to the wrong case.
Pruning will require states in the nodes to retain information on the
floods it has already seen and passed along. Certainly we can leave it
up to the root to select either method based on the density of
listeners.

A real multicast operation in the intermediate nodes in pure source
route would require a new form of RH encoding, that's doable but not
necessarily trivial. Would we want that in the RH spec?

Finally, if the direction for the future is states in some nodes as we
used to have it, then those can effectively multicast for their
subtrees, so maybe we can keep that piece for later...

What do you think?

Pascal

> From: Richard Kelsey [mailto:[email-masked]]
> Sent: Tuesday, May 18, 2010 8:11 PM
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]; [email-masked]
> Subject: RPL multicast (was Re: [Roll] RPL Status)
> 
> > > limitiations; in particular, it requires that all nodes cache
DAOs.
> ZigBee, which has always-on routers, uses hop-limited flooding for
> multicasts.  This works well for multicasts that need to go to all or
almost all
> nodes.
> 
> I do not know how multicasts are handled in sensor networks, where
> flooding is relatively expensive.
> 
> In the source route world, for multicasts with few subscribers, the
simplest
> thing would to use DAOs more-or-less as is done for downward routes.
MLD
> requests would be forwarded up to the root, and the root would keep
track
> of which nodes were subscribed to which multicast addresses.
Multicasts
> would be also forwarded to the root, which would unicast them down to
> subscribers.  I suppose the root could also make the determination as
to
> which multicasts could be more effectively flooded.
> 
complicated
> schemes :-).

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 19 May 2010 10:51:42 -0400

> From: "Samita Chakrabarti" <[email-masked]>
> Date: Tue, 18 May 2010 16:56:43 -0700
> 
> [SC>] BTW, is RPL also trying to solve multicast
> routing/forwarding completely in all cases?  It might be
> better to have another id for the detailed multicast
> forwarding/routing for all cases (multicast to all nodes
> in LLN, multicast to nodes that are spread out under
> different parents far from each other and trying
> communicate with each other etc.).

RPL is required to provide multicast routing/forwarding.  I
would assume that it has to handle all cases, although
clearly it need not handle them with equal efficiency.
Ideally RPL's handling of multicasts would be more or less
on par with its handling of unicasts.  In particular,
the rules for handling DAOs and DAO caching should not
change too much for multicast addresses.

As with unicasts, specialized implementations for particular
situations should go in other documents.  Exactly where to
draw the line is open to debate.

                                  -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 19 May 2010 11:05:11 -0400

> Date: Wed, 19 May 2010 14:59:12 +0200

Yes.  I think that both will have to be available, at least in
some networks.

> floods it has already seen and passed along.

Yes.  Would the flood mechanism need to go into RPL or could
it be put in a separate document?  The right way to flood
would seem to depend on the link layer and the network
topology.

> necessarily trivial. Would we want that in the RH spec?

I am not sure what you mean.

I like the image of a mixed unicast/local flooding delivery
mechanism.  The root selectively sends out unicasts that
burst into local floods when they reach their destination.
Just like fireworks, except that we have our DAGs upside
down.  Sounds like a research topic, and thus out of scope.

                                -Richard Kelsey

---

From: [email-masked]
Date: Wed, 19 May 2010 12:20:54 -0500

Hi Samita,

With regards to multicast being a separate
ID, it concerns me that if we proliferate IDs some may naturally atrophy
or be discounted in time.  I believe that RPL should cover all the
necessary IP functionality as applied to LLNs including multicast and P2P
operations.  If a given implementation determines that for whatever
reason the application does not need these features, then they need not
be implemented.  However, I think the RFC should be holistic.

That being said, please note that I
am a complete IETF neophyte.  Maybe there are ways to assure that
separate ID stay in lock-step.  If this is true then I have no qualms
about separate IDs.  If there is a chance that some IDs may fall into
disrepair, then I opt for a single fully inclusive RPL ID.

With regards to multicast in building
environments, currently there are two multicast use cases used in building
control.  The first is for discovery purposes.  There is a need
for a device to access data items from other devices.  The discovery
and binding is done using a site multicast (or broadcast).  Often
times the binding will be across two devices in the same LLN, however,
it's very possible that the binding may cross subnets.  A case in
point is the need to access the 'outdoor air temperature'.  This data
is very important to the HVAC control algorithms.  However, buildings
typically only deploy a single outdoor air temperature sensor across the
entire enterprise.  Hence most references to the device will cross
subnets.

The second use case will be for different
building subsystems (e.g. Fire, Security, HVAC) to operate independently
at the application layer, but to share the routing (meshing) capability
to increase the density of the meshing nodes.

Regards,

Jerry

From:

"Samita Chakrabarti" <[email-masked]>

To:

"'Richard Kelsey'" <[email-masked]>,
"'JP Vasseur'" <[email-masked]>

Cc:

[email-masked]

Date:

05/18/2010 06:56 PM

Subject:

Re: [Roll] RPL Status

Hi Richard/JP,

> > Here is a quick status. First, we would like to thank the WG
again for

in

[SC>]  Ticket #30 is about clarification of text regarding the
multicast

operation.

nodes

a

inefficient.

in LLN, multicast to nodes that are spread out under different parents
far

from each other and trying communicate with each other etc.). It might
be

mechanism. I wonder what would be the typical applications today for RPL
in

and the corresponding members of the multicast address may work out. But
I

prune.

consider pruning.

A generic solution for multicast routing/forwarding in LLN seems to be
a

Thanks,

-Samita

Roll mailing list

[email-masked]

---

From: JP Vasseur <[email-masked]>
Date: Wed, 19 May 2010 05:40:23 +0200

On May 18, 2010, at 8:10 PM, Richard Kelsey wrote:

>>> limitiations;

Correct.

> More complicated schemes are possible, but I don't like more

Since you asked ;-) Such schemes have been developed for other  
protocols such as MPLS,
for example in the case of P2MP Traffic Engineering Label Switched  
Path (TE LSP) where
the path is computed by the head (for some PCE) and where the computed  
paths is provided
by the signaling protocol (RSVP-TE) when setting up the TE LSP. There  
are many ways to
encode the P2MP TE LSP path so one could adopt a similar approach  
using a new RH but
that means non-negligible overheard to say the least in the data  
path ...
Note that new P2MP forwarding schemes are not within the scope of  
ROLL, which provides a
P2MP/Multicast routing solution only.

Thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 May 2010 14:40:22 +0200

Le 19/05/2010 09:39, Anders Brandt a écrit :
> and we have not even started discussing the P2P ID mechanisms in detail -

Only in part because of the failure to meet requirements - I disagree to 
pursue RPL towards LC before the next IETF: it is way too early.

We have wide technical misunderstandings about the scope of this 
protocol and its applicability.

Alex

> Thanks,
> Anders
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *JP Vasseur
>     *Sent:* Tuesday, May 18, 2010 11:48
>     *To:* roll WG
>     *Subject:* [Roll] RPL Status
>
>     Dear WG,
>
>     Here is a quick status. First, we would like to thank the WG again
>     for the continuous effort and lots of fruitful and productive work !
>     As discussed in Anaheim, the plan is still to Last Call RPL before
>     the next IETF. The plan is to release the next revision of the RPL
>     I-D by end of next week. Rev-08 will address the following:
>
>     */What else ?/*

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 May 2010 14:41:20 +0200

> subtrees, so maybe we can keep that piece for later...

What is the multicast support offered by the link layers on which RPL runs?

Alex

>>> From: "Pascal Thubert (pthubert)"<[email-masked]>
>>>
>>>> Richard Kelsey

---

From: Philip Levis <[email-masked]>
Date: Thu, 20 May 2010 10:02:58 -0700

On May 19, 2010, at 12:39 AM, Anders Brandt wrote:

> The home and building requirements are not met by the current RPL draft and we have not even started discussing the P2P ID mechanisms in detail -
> Does the WG agree that a RPL spec without support for home and building applications is acceptable?
>  
> Thanks,

I think that a core RFC that does not *include* P2P (home and building applications) is acceptable. However, it should be that supporting P2P (described in a separate document) does not require any changes to the core RFC. E.g., adding more packet types and using reserved bits is OK, modifying existing packet formats is not. This necessitates that the core RFC be aware of what P2P needs, although perhaps not every detail of how it works.

It's been two months since Anaheim; from the discussions there I thought we'd be much further along. The best way to resolve this tension is to make fast progress on P2P.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Thu, 20 May 2010 21:56:22 +0200

Hi,

> necessarily trivial. Would we want that in the RH spec?

=> This is what I was referring as a technique that was used for P2MP  
Traffic
Engineering LSP using RSVP, but be careful this means lots of  
overhead ...
That would not be in our charter too.

> subtrees, so maybe we can keep that piece for later...

I think so too ...

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 20 May 2010 19:28:53 -0700

Hi Jerald,

Thanks for the  response. Please see below.

With regards to multicast being a separate ID, it concerns me that if we
proliferate IDs some may naturally atrophy or be discounted in time.  I
believe that RPL should cover all the necessary IP functionality as applied
to LLNs including multicast and P2P operations.  If a given implementation
determines that for whatever reason the application does not need these
features, then they need not be implemented.  However, I think the RFC
should be holistic. 

That being said, please note that I am a complete IETF neophyte.  Maybe
there are ways to assure that separate ID stay in lock-step.  If this is
true then I have no qualms about separate IDs.  If there is a chance that
some IDs may fall into disrepair, then I opt for a single fully inclusive
RPL ID. 

[SC>]  There is no generic rules on id separations in IETF. But, I was
fearing that including all feature in one protocol draft may complicate the
progress of the draft.  But I was pointed out that multicast is in the RPL
charter; in that respect we may want to have  limited multicast forwarding
support in LLN for now. Later, if needed one can extend the feature for more
efficiency of multicast in LLN. Moreover in some L2-networks like 802.15.4,
there is no multicast support at the link-layer - in those cases, unicasts
and broad-casts are the only options depending on the applications - right?

With regards to multicast in building environments, currently there are two
multicast use cases used in building control.  The first is for discovery
purposes.  There is a need for a device to access data items from other
devices.  The discovery and binding is done using a site multicast (or
broadcast).  Often times the binding will be across two devices in the same
LLN, however, it's very possible that the binding may cross subnets.  A case
in point is the need to access the 'outdoor air temperature'.  This data is
very important to the HVAC control algorithms.  However, buildings typically
only deploy a single outdoor air temperature sensor across the entire
enterprise.  Hence most references to the device will cross subnets. 

[SC>] Thanks for the real-life example - very useful. Can I assume that an
enterprise will have a collection of LLNs joined by their border routers in
the backbone?

The second use case will be for different building subsystems (e.g. Fire,
Security, HVAC) to operate independently at the application layer, but to
share the routing (meshing) capability to increase the density of the
meshing nodes. 

[SC>] So, in this example, is it fair to say that the main usage would be to
address all-node-multicast in a building sub-system? Or there might be more
granular usage of multicast groups (per floor, per room etc.)?

Thanks again,

-Samita

From: 

To: 

"'Richard Kelsey'" <[email-masked]>, "'JP Vasseur'"
<[email-masked]> 

Cc: 

[email-masked] 

Date: 

05/18/2010 06:56 PM 

Subject: 

Re: [Roll] RPL Status

  _____  

Hi Richard/JP,

a
inefficient.

Thanks,
-Samita

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

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 21 May 2010 00:50:05 -0600

What ever happened to the protocol survey draft?

Samita's message about the proliferation of drafts that atrophy got me
wondering about the protocol survey draft.  This is a working group
document and is part of the milestones and charter of the ROLL WG, but
this draft has long since expired.

It was supposed to be submitted to the IESG as an informational RFC back
in Feb 2009.  It was last updated in April of 2009 so I would think that
it is complete.  Why hasn't it been submitted to the IESG?  Given that
it was THIS document that was the basis for the decision to create a new
routing protocol it is important that this information is not lost.

Did the WG ever even Last Call this document?

	geoff

---

From: JP Vasseur <[email-masked]>
Date: Fri, 21 May 2010 12:25:12 +0200

> Did the WG ever even Last Call this document?

The decision was made not to publish it as an RFC (see WG minutes), also
in agreement with our AD.

This will be reflected in the Milestone when we will work on them,  
with the WG.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 21 May 2010 12:26:19 +0200

On May 20, 2010, at 7:02 PM, Philip Levis wrote:

>> The home and building requirements are not met by the current RPL  
>> draft and we have not even started discussing the P2P ID mechanisms  
>> in detail -
> I think that a core RFC that does not *include* P2P (home and  
> building applications) is acceptable. However, it should be that  
> supporting P2P (described in a separate document) does not require  
> any changes to the core RFC. E.g., adding more packet types and  
> using reserved bits is OK, modifying existing packet formats is not.  
> This necessitates that the core RFC be aware of what P2P needs,  
> although perhaps not every detail of how it works.
>
> It's been two months since Anaheim; from the discussions there I  
> thought we'd be much further along. The best way to resolve this  
> tension is to make fast progress on P2P.

Absolutely.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 May 2010 13:52:13 +0200

One would expect that draft to have progressed and be published already.
  If it is open for discussion again then I have comments on it.

Last I remember is public discussion in february 2009 - it ended with a
Chair statement intenting to use this draft as a motivation to recharter
and develop new protocol...

Then echoes were heard publicly about private discussion on this draft
(discussion about which we don't know much), and then silence since
april 25th, 2009.

Recharter happened.  Document to IESG didn't seem so.

It's strange.

Alex

Le 21/05/2010 08:50, Geoff Mulligan a écrit :
> Samita's message about the proliferation of drafts that atrophy got
> me wondering about the protocol survey draft.  This is a working
> group document and is part of the milestones and charter of the ROLL
> WG, but this draft has long since expired.
>
> It was supposed to be submitted to the IESG as an informational RFC
> back in Feb 2009.  It was last updated in April of 2009 so I would
> think that it is complete.  Why hasn't it been submitted to the IESG?
> Given that it was THIS document that was the basis for the decision
> to create a new routing protocol it is important that this
> information is not lost.
>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

Subject: Re: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-07.txt
From: Philip Levis <[email-masked]>
To: ROLL WG <[email-masked]>
Date: Fri, 24 Apr 2009 19:08:42 -0700
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>

On Apr 24, 2009, at 2:15 PM, [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Routing Over Low power and Lossy  
> networks Working Group of the IETF.
>
> 	Title		: Overview of Existing Routing Protocols for Low Power and  
> Lossy Networks
> 	Author(s)	: A. Tavakoli, S. Dawson-Haggerty, P. Levis
> 	Filename	: draft-ietf-roll-protocols-survey-07.txt
> 	Pages		: 26
> 	Date		: 2009-4-24
> 	
> Low-power wireless devices, such as sensors, actuators and smart     
> objects, present difficult constraints: very limited memory, little
>    processing power, and long sleep periods.  As most of these devices
>    are battery-powered, energy efficiency is critically important.
>    Wireless link qualities can vary significantly over time, requiring
>    protocols to make agile decisions yet minimize topology change  
> energy
>    costs.  Routing over such low power and lossy networks introduces
>    requirements that existing routing protocols may not fully address.
>    Using existing application requirements documents, this document
>    derives a minimal and not exhaustive set of criteria for routing in
>    low-power and lossy networks.  It provides a brief survey of the
>    strengths and weaknesses of existing protocols with respect to  
> these
>    criteria.  From this survey it examines whether existing and mature
>    IETF protocols can be used without modification in these  
> networks, or
>    whether further work is necessary.  It concludes that no existing
>    IETF protocol meets the requirements of this domain.

There is one minor change in -07; DYMO's analysis for "node cost" is  
now "?" rather than "fail." Ian is very certain that DYMO could meet  
this criterion somehow. We therefore think it's safer to make it "?":  
there is a possibility that the criterion could be met within the  
specification, but doing so would require further investigation and  
specification. As there's consensus on the conclusion of the  
document, it seems more important to have it on the permanent record  
as an RFC which we can reference than spin on details.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Fri, 21 May 2010 14:37:14 +0200

Hi Alex,

Few comments. Last calling the base specification does not imply by  
all means that the work is complete,
we have other items in our charter, could be re-chartered according to  
the WG's feed-back, etc ...
We were referring to the base RPL specification and for that we have a  
ticket opened that helps
us track that the base specification meets the requirements spelled  
out in the four requirements
document. For the record, I'll resend the document, that will be  
updated after each revision of RPL.
As pointed out by Phil, if we can move forward with P2P I-D that'd be  
great.

Thanks.

JP and David.

On May 20, 2010, at 2:40 PM, Alexandru Petrescu wrote:

>> draft
> Only in part because of the failure to meet requirements - I  
> disagree to pursue RPL towards LC before the next IETF: it is way  
> too early.
>

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 21 May 2010 07:50:10 -0600

WOW.  I'll go look - I certainly don't remember this.  Was this decided
on the mailing list????  Again, I don't remember any mailing list
discussion.

Something like this should not be decided at a IETF meeting (indicted by
your use of the word "minutes").

I think that it is a real shame and mistake that the only document that
is the basis for the decision to invent a new protocol and the work that
went into that document will be lost if it not published.

Which AD approved this action and again was this published on the
mailing list?  I'll go look.

	geoff

On Fri, 2010-05-21 at 12:25 +0200, JP Vasseur wrote:
> > back

---

From: Robert Cragie <[email-masked]>
Date: Fri, 21 May 2010 18:07:44 +0100

Perhaps the title of this e-mail should have been 'wither 
draft-ietf-roll-protocols-survey-07' :-)

In all seriousness, this document should not be allowed to disappear 
from the process as I think fundamentally some of the assertions made it 
in were questionable, to put it mildly.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

---

From: [email-masked]
Date: Fri, 21 May 2010 09:12:39 -0500

Hi Samita,

Comments below ...

From:

To:

<[email-masked]>

Cc:

"'JP Vasseur'" <[email-masked]>,
"'Richard Kelsey'" <[email-masked]>, <[email-masked]>,
<[email-masked]>

Date:

05/20/2010 09:28 PM

Subject:

RE: [Roll] RPL Status

Hi Jerald,

Thanks for the  response. Please see
below.

features, then they need not be implemented.  However, I think the
RFC should be holistic.

That being said, please note that I am a complete IETF neophyte.  Maybe
there are ways to assure that separate ID stay in lock-step.  If this
is true then I have no qualms about separate IDs.  If there is a chance
that some IDs may fall into disrepair, then I opt for a single fully inclusive
RPL ID.

[SC>]  There is no generic
rules on id separations in IETF. But, I was fearing that including all
feature in one protocol draft may complicate the progress of the draft.
But I was pointed out that multicast is in the RPL charter; in that
respect we may want to have  limited multicast forwarding support
in LLN for now. Later, if needed one can extend the feature for more efficiency
of multicast in LLN. Moreover in some L2-networks like 802.15.4, there
is no multicast support at the link-layer – in those cases, unicasts and
broad-casts are the only options depending on the applications – right?

I'm not sure I understand
the question.  We are currently deploying ZigBee products which incorporate
802.15.4 radios.  ZigBee emulates broadcasts and multicasts by a controlled
flooding of the LLN with a series of link local messages.

With regards to multicast in building environments, currently there are
two multicast use cases used in building control.  The first is for
discovery purposes.  There is a need for a device to access data items
from other devices.  The discovery and binding is done using a site
multicast (or broadcast).  Often times the binding will be across
two devices in the same LLN, however, it's very possible that the binding
may cross subnets.  A case in point is the need to access the 'outdoor
air temperature'.  This data is very important to the HVAC control
algorithms.  However, buildings typically only deploy a single outdoor
air temperature sensor across the entire enterprise.  Hence most references
to the device will cross subnets.

[SC>] Thanks for the real-life
example – very useful. Can I assume that an enterprise will have a collection
of LLNs joined by their border routers in the backbone?

Exactly.  Often there will
be an LLN per floor each with an LBR.  The LBRs will be tied together
in some IP fashion, often times by the enterprise IP network.

The second use case will be for different building subsystems (e.g. Fire,
Security, HVAC) to operate independently at the application layer, but
to share the routing (meshing) capability to increase the density of the
meshing nodes.

[SC>] So, in this example, is
it fair to say that the main usage would be to address all-node-multicast
in a building sub-system? Or there might be more granular usage of multicast
groups (per floor, per room etc.)?

Yes.  A main use
case would be to segment the different building system types (e.g. HVAC,
Fire, Lighting).  As I noted above, LLNs typically don't cross floors
since the low power radios have a hard time pushing messages through floors
and ceilings.  There will be application oriented multicasts established
as well.  For example a multicast group would be established for each
bank of lights that are associated to a light switch; so when the light
switch is toggled, all the proper lights are turned on/off.

Thanks again,

-Samita

Jerry

From:

"Samita Chakrabarti"
<[email-masked]>

To:

Cc:

[email-masked]

Date:

05/18/2010 06:56 PM

Subject:

Re: [Roll] RPL Status

Hi Richard/JP,

again for

in

operation.

nodes

a

inefficient.

prune.

consider pruning.

Thanks,

-Samita

Roll mailing list

[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 May 2010 22:41:31 +0200

Le 21/05/2010 15:50, Geoff Mulligan a écrit :
> WOW.  I'll go look - I certainly don't remember this.  Was this
> decided on the mailing list????  Again, I don't remember any mailing
> list discussion.

I don't remember such discussion either and I checked archives.

> Something like this should not be decided at a IETF meeting (indicted
> by your use of the word "minutes").

I think I have never seen a WG item stopped and got rid of.

> I think that it is a real shame and mistake that the only document
> that is the basis for the decision to invent a new protocol and the
> work that went into that document will be lost if it not published.

Alex

>>> Samita's message about the proliferation of drafts that atrophy
>>> got me wondering about the protocol survey draft.  This is a
>>> working group document and is part of the milestones and charter
>>> of the ROLL WG, but this draft has long since expired.
>>>
>>> It was supposed to be submitted to the IESG as an informational
>>> RFC back in Feb 2009.  It was last updated in April of 2009 so I
>>> would think that it is complete.  Why hasn't it been submitted to
>>> the IESG?  Given that it was THIS document that was the basis for
>>> the decision to create a new routing protocol it is important
>>> that this information is not lost.
>>>
>> The decision was made not to publish it as an RFC (see WG minutes),
>> also in agreement with our AD.
>>
>>> _______________________________________________ Roll mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 22 May 2010 12:05:30 +0200

> in agreement with our AD.

I have a disagreement - I disagree to not publish this document.

Alex

> This will be reflected in the Milestone when we will work on them, with
> the WG.
>
> Thanks.
>
> JP.
>
>>
>> geoff
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 22 May 2010 12:06:42 +0200

Le 21/05/2010 14:37, JP Vasseur a écrit :
> Hi Alex,
>
> Few comments. Last calling the base specification does not imply by all
> means that the work is complete,

I would have expected to Last Call a document which we believe is almost 
done.

Alex

> We were referring to the */base/* RPL specification and for that we have
> a ticket opened that helps
> us track that the base specification meets the requirements spelled out
> in the four requirements
> document. For the record, I'll resend the document, that will be updated
> after each revision of RPL.
> As pointed out by Phil, if we can move forward with P2P I-D that'd be great.
>
> Thanks.
>
> JP and David.
>
>> Only in part because of the failure to meet requirements - I disagree
>> to pursue RPL towards LC before the next IETF: it is way too early.
>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 24 May 2010 16:21:00 +0100

Robert Craigie
> from the process as I think fundamentally some of the assertions made 
> it in were questionable, to put it mildly.

If that is the case (which I'm not commenting on here) surely that
would be a reason to let to disappear rather than not.

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