Subject: [Roll] Some additional thoughts...

From: Cedric-2 LAVENU <[email-masked]>
Date: Fri, 29 Jul 2011 22:43:00 +0200

All,

Regarding the concerns I have been sharing with you during this 
afternoon's ROLL meeting, I'd just like to precise a bit more my thoughts.
As a utility, we cannot just choose a routing protocol because some people 
within a working group are just stating that it works. I think that 
everybody's aware of the important investment an AMI is representing for a 
utility... Just to say that mistakes are not allowed. The use of validated 
and mature technologies is a key requirement for a successful massive 
roll-out of a 20-year lifespan AMI. 

I'm actually not pretending to be a routing expert, but I think that we 
cannot make the right decision on the basis of the recently released AMI 
applicability statement. 
We really need some more accurate results based on simulations and 
experimentation (field, lab...) to get an idea on how RPL (either in 
storing or non-storing mode) performs for different traffic patterns. It's 
a must to get figures for certain key indicators (amount of generated 
control traffic, routing table entries and associated RAM,...). In the 
perspective of an end-user or even an AMI vendor, the limits have to be 
known to be able to judge whether the protocol is suitable or not for a 
given PHY/MAC medium (wireless, narrowband PLC, broadband PLC,...) and 
with respect to the used application protocol (which is defining the 
traffic pattern). It would also be great to get more accurate information 
on how to tune all the appropriate parameters in different environments. 

Kind regards,
Cédric

Cédric LAVENU
Ingénieur - Systèmes de comptage
EDF - R&D
Département MIRE
1 avenue du général de Gaulle
92141 Clamart
 
[email-masked]
Tél. : +33(0)1 47 65 27 29
  
Un geste simple pour l'environnement, n'imprimez ce message que si vous en 
avez l'utilité.

Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or virus-free.

---

From: JP Vasseur <[email-masked]>
Date: Sat, 30 Jul 2011 11:17:46 -0400

Hi Cedric,

On Jul 29, 2011, at 4:43 PM, Cedric-2 LAVENU wrote:

> 
> All, 
> 
> Regarding the concerns I have been sharing with you during this afternoon's ROLL meeting, I'd just like to precise a bit more my thoughts. 
> As a utility, we cannot just choose a routing protocol because some people within a working group are just stating that it works. I think that everybody's aware of the important investment an AMI is representing for a utility... Just to say that mistakes are not allowed. The use of validated and mature technologies is a key requirement for a successful massive roll-out of a 20-year lifespan AMI. 
> 
> I'm actually not pretending to be a routing expert, but I think that we cannot make the right decision on the basis of the recently released AMI applicability statement. 
> We really need some more accurate results based on simulations and experimentation (field, lab...) to get an idea on how RPL (either in storing or non-storing mode) performs for different traffic patterns. It's a must to get figures for certain key indicators (amount of generated control traffic, routing table entries and associated RAM,...). In the perspective of an end-user or even an AMI vendor, the limits have to be known to be able to judge whether the protocol is suitable or not for a given PHY/MAC medium (wireless, narrowband PLC, broadband PLC,...) and with respect to the used application protocol (which is defining the traffic pattern). It would also be great to get more accurate information on how to tune all the appropriate parameters in different environments. 

Many Thanks for sharing your thoughts Cedric, your input is critically important.
I think that we had a very fruitful discussion on the subject matter during our ROLL WG meeting yesterday.

What we now need to do is to compile the set of comments that were made at the mic yesterday and have a consensus on what needs to be described in the AMI applicability document. That will be done soon.

As a reminder, as clearly spelled out yesterday, the aim of this document is not to prove that a protocol work in an AS (applicability statement). As a reminder:

" * An Applicability Statement specifies how, and under what   circumstances, one or more TSs may be applied to support a particular Internet capability.
* An AS identifies the relevant TSs and the specific way in which they are to be combined, and may also specify particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented."

On the other hand, as discussed, we should provide guidance, explain which building blocks of the protocol should be used in light of the requirements, the implications on the protocol behavior when tuning a specific timer, etc … As pointed out by Jari, one could provide pointers on past experience, simulations papers, etc … too.

More soon, and thanks to all of you for the fruitful discussion. We will summarize it in the minutes, and authors please come back to the list to propose next steps, have all of us providing feed-back and reach a consensus.

Thanks.

JP.

>    	Un geste simple pour l'environnement, n'imprimez ce message que si vous en avez l'utilité.
> 
> 
> 
> 
> E-mail communication cannot be guaranteed to be timely secure, error or virus-free._______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll