Re: [Roll] AMI applicability: storing/non-storing.

["Popa, Daniel" <[e-mail]>]

Hi Michael, all, 

Sorry for delayed answer... I will do my best to get much shorter the response time for future conversations...

PLS see reply within your lines.

Regards,
Daniel

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Michael Richardson
Envoyé : mercredi 7 août 2013 21:41
À : [e-mail]
Cc : [e-mail]
Objet : AMI applicability: storing/non-storing.


I read draft-ietf-roll-applicability-ami-07 on Monday,and I am so pleased to see this work resume.  I see that there has been some hard thinking for certain aspects, and I hope that this process will continue.

Some comments though on storing/non-storing mode.  You write:

>   As a result, different AMI deployments can vary significantly in
>   terms of memory size, computation power and communication
>   capabilities.  For this reason, the use of RPL storing or non-storing
>   mode SHOULD be deployment specific.  When meters are memory

a manufacturer that wishes to make meters for more than one market/RFP would need to put in enough memory for the worst case storing situation.  So the advice here is empty. And how many routes is enough?

The restof section 9.1.2 says, "if you have memory use storing mode, if you don't, then don't".

DP> The assumption is correct but in practice the size of the memory to put into a device is a trade-off between several constraints: e.g., cost, mechanics, power consumption, performance, .. the markets/RFPs come with different requirements and constraints, and there are many markets where the global cost of a device can severely constraint the capabilities of a device. In such cases, over-dimensioning the memory is not always a suitable solution. Also, although memory size increased considerably in AMI devices over the past few years, we should take into account that this memory is shared with other applications. Routing/RPL is one of the key pieces of the meter ecosystem , but when it comes to sharing memory resources we cannot always afford to give routing/RPL the highest slice of this memory. 
DP> It is not easy to answer the questions "how many routes is enough?". This is because it depends on metering device HW architecture, on metering device SW/FW architecture, on how efficiently one implements its FW/SW, on what type of OS is used, on how many other applications and functionalities are sharing the same memory resources, and so on. As an example, although an AMI platform  for US market is sharing some in common with an AMI platform for EU market, their requirements/constraints, functionalities and applications can be significantly different.

>   route repair latency.  However, in high-density environments, storing
>   routes can be challenging because some nodes may have to maintain
>   routing information for a large number of descendents.  When the
>   routing table size becomes challenging, it is RECOMMENDED that nodes
>   perform route aggregation, similarly to the approach taken by other
>   routing protocols, although the required set of mechanism may differ.

I'm really unclear what this means. What mechanism are you referring?
Route aggregation in BGP4 is accomplished by applocating aggregatable
addresses.   Are you suggesting that all the meters in a high-density
environment should be numbered in a /64 different from the meters in the next
building?   How would this be configured?  What device would do this?

DP> Because - as you highlighted as well - route aggregation in a mesh network is not a trivial thing we only make recommendation to implementers to consider route aggregation as a potential solution to the potential issue of routing table scalability when RPL with storing mode of operation is used in high-density environments.

It seems to me that the AMI community would be interested in the hydrid modes which have been proposed, and further R&D in that area would be waranted.

DP> By hybrid mode you mean mixing RPL storing and non-storing modes in the "same" DODAG, right ? I believe that  hybrid mode of operation deserve at least some discussions/brainstorming.. This mode of operation may - as you say - can help dealing with scalability issues as well as with supporting a mix of devices with different constraints (e.g., a mix of AC powered devices and battery operated devices)

(The lack of a compromise between storing and non-storing is why I felt that would perhaps be multiple applicability statements for urban and suburban/rural environments, and perhaps also for battery operated environments.  Your 1.3 seems to copy my text exactly, so please edit it.
I would suggest that you write a document that says something like:
  this applies to metering applications where the number of possible parents
  is > X.

(possible parents controls for differences in radio power, propogation, and physical density of meters. Or you could be specific about radio type, and just list meter density directly)

DP> Good catch. Section 1.3 will be updated accordingly for the next review. 
DP> I think that the only mode of operation that can potentially suffer from routing table scalability issues is RPL storing mode. Routing table sizes at  nodes in RPL non storing mode (except the DODAG root)  is not significantly affected by the density of nodes.
DP> It will be difficult to define the right value for "X" (i.e., number of parents >3), because - as stated previously - the potential routing table scalability issues for RPL storing mode is tightly related to specific markets and implementations. Alternatively, we can eventually narrow down this applicability statement document to only "RPL non-storing mode of operation", if this may help.
DP> I tend to agree with you that battery operated nodes are different beasts and do not have the same constraints as AC powered devices. We discussed among the authors to eventually narrow down the scope of this applicability statement to only AC powered devices. We can provide this as an update on the next revision of the document, based on feedback we get from the group.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/