Subject: [Roll] comments on draft-ietf-roll-applicability-ami-01

From: Ietf Roll <[email-masked]>
Date: Thu, 28 Jul 2011 21:44:45 -0700 (PDT)

I can be silent no more... Since no one else has really spoken up about the state of this draft I feel that I must...

This is the most amazing marketing fluff piece trying to pass itself off as a serious document that I have read in quite a while. With all the hot air I'm surprised that it hasn't risen to RFC status of it's own accord - It shouldn't have needed the WG Chairs to skip standard accepted procedures for promoting WG documents. [Perhaps there is some unseen agenda in their rush to move the document forward without due process.]

We have been told that "the IESG" requested it. Really, the entire IESG asked for this doc to jump normal protocol and move forward. I suspect that this an unsubstantiated assertion like much of draft-ietf-roll-applicability-ami-01.

It seems to me that an AS should be based on real world experiences but that is not possible since I have seen no actual deployments of RPL. There have been some simulations attempting to show that it works and some laboratory experiments that would indicate it might work - there are other experiments that also show that it doesn't seem to perform as expected.

One academic paper written by some of the authors of the RPL ID (BTW it is not yet an RFC) clearly states that RPL should be limited to 30 node networks. This seems far less than requirement listed in the this document - e.g. 100s to 10000s nodes - for AMI networks.

On that topic it seems that the authors of this draft have confused AMI with AMR. Where AMR networks are primarily MP2P (unidirectional) which RPL might do well and might scale (if it weren't for the need of sending back ACKs and the lossy nature of RF networks), AMI networks are truly bidirectional with as many, if not more, messages flowing to the meter and home as away. Here RPL is known to be severely lacking.  In fact the whole idea of packets flowing down a DAG (isn't that an Oxymoron) was an after-thought as evidenced by the fact that multiple other drafts had to be written to make RPL work in a downward direction.

Before this WG moves this draft forward I would request that we see more than assertions and claims that RPL can perform as "designed" (I use that term loosely). The draft "says" RPL was designed to meet all the requirements in the various routing requirement use cases. This is a claim that is simple to make but where has it been shown to be true or proved.

Where is there an urban, home, industrial or commercial building implementation - any real product, running code - to show that any of these claims are in fact true or just baseless wishful thinking.

This would seem a critical piece for any AS and part of a proper procedure but, as we all know, when have the Chairs ever acted on proper procedure in the Working Group. Certainly not all the way back on the issues of IPR disclosures, nor the rush to push out the ID to the IETF, the abandonment of the only draft that tried to justify the work in the first place, ... So would I or why should we expect it now.

I have gone on too long in this message. I will get to the factual problems (like mixing up AMI and AMR) in my next message.

Thoroughly fed up,
  RAV

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 29 Jul 2011 06:52:51 -0700

RAV, (the mysterious person hiding behind an unrecognizable name),

Let me respond to the more technical comments:

> It seems to me that an AS should be based on real world experiences but that is not possible since I have seen no actual deployments of RPL. There have been some simulations attempting to show that…

There may not yet be a large scale production deployment that conforms to the RPL specification.  However, I guarantee you that there are large-scale production deployments that utilize the same broad concepts as RPL (i.e. proactively building routes to a border router/DAP/egress/etc using a distance vector protocol, proactively reversing those routes using either source route or hop-by-hop routing).

> One academic paper written by some of the authors of the RPL ID (BTW it is not yet an RFC) clearly states that RPL should be limited to 30 node networks. This seems far less than requirement listed…

You take those results out of context.  The target platform described in the paper you reference had 10KB of total SRAM.  I guarantee you that existing production deployments with >1000 node networks have devices with significantly more RAM.

> On that topic it seems that the authors of this draft have confused AMI with AMR. Where AMR networks are primarily MP2P (unidirectional) which RPL might do well and might scale (if it weren't for t…

Maybe you missed the following paragraph:

  Head-end servers generate traffic to configure smart metering devices
  or initiate queries, and use unicast and multicast to efficiently
  communicate with a single device (i.e., Point-to-Point (P2P)
  communication) or groups of devices respectively (i.e., Point-to-
  Multipoint (P2MP) communication).  The head-end server may send a
  single small packet at a time (e.g., a meter read request, or small
  configuration change) or many consecutive large packets (e.g., a
  firmware upgrade across one or even thousands of devices).

Sure, proactive mechanisms have their limit - but those *existing* production deployments that build P2MP routes proactively are properly provisioned.  Reactive mechanisms have their limits as well.

In case you are confused, the term DAG was chosen to indicate that default routes are optimized *towards* a border router.  Link reversal is not an uncommon technique.

--
Jonathan Hui

---

From: C Chauvenet <[email-masked]>
Date: Fri, 29 Jul 2011 07:51:50 -0700

Hi Dark Knight ;-),

See Inline.

> One academic paper written by some of the authors of the RPL ID (BTW it is not yet an RFC) clearly states that RPL should be limited to 30 node networks. This seems far less than requirement listed…

I can clearly state, that RPL runs over many more that 30 nodes, based on real deployments.
You may know that most of companie's experimentations are not publicly released.

> On that topic it seems that the authors of this draft have confused AMI with AMR. Where AMR networks are primarily MP2P (unidirectional) which RPL might do well and might scale (if it weren't for t…

See pascal's comment on that.

> I have gone on too long in this message. I will get to the factual problems (like mixing up AMI and AMR) in my next message.

Coffee seems to be a little strong in IETF...

>  RAV

Cédric.

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