Re: [homenet] Support for RFC 7084 on shipping devices...

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 07 October 2019 14:40 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14773120874; Mon, 7 Oct 2019 07:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O18idDznLcV; Mon, 7 Oct 2019 07:40:13 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0451612085C; Mon, 7 Oct 2019 07:40:12 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [80.233.32.253]) by relay.sandelman.ca (Postfix) with ESMTPS id 02D861F456; Mon, 7 Oct 2019 14:40:11 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 5CF391BBA; Mon, 7 Oct 2019 16:40:54 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6MAN <6man@ietf.org>, homenet@ietf.org
In-reply-to: <AF4ECDF2-FD9D-4178-BDF1-A3C87A4D1DBE@fugue.com>
References: <FF34E138-469F-40F6-BA8F-7AE02F878B29@employees.org> <CA2AA8FF-3BC4-4359-A718-93F1FCFAE8DA@cisco.com> <AF4ECDF2-FD9D-4178-BDF1-A3C87A4D1DBE@fugue.com>
Comments: In-reply-to Ted Lemon <mellon@fugue.com> message dated "Mon, 07 Oct 2019 06:27:13 -0700."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 07 Oct 2019 16:40:54 +0200
Message-ID: <8808.1570459254@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/F5NXxQQUBUhylD-zHphLjw2Vq9k>
Subject: Re: [homenet] Support for RFC 7084 on shipping devices...
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2019 14:40:16 -0000

Ted Lemon <mellon@fugue.com> wrote:
    >> Too bad then... I still fail to see why the model cannot be
    >> generalized to more powerful nodes. 

    > Because it is maximally complex?   :]

    > You say that RPL has scaled to millions of nodes.   Where is this
    > deployed in production?   What are the leaf nodes doing?   With what
    > are they communicating?

Diagram to help:
          A               B
          |               |
     +----+-------+-------+----+ <-network 1
     |            |            |
     C            D            E
     |            |            |
   +-+-+(2)     +-+-+(3)     +-+-+(4)
   |   |        |   |        |   |
   F   G        H   I        J   K


1) the deployments I'm aware of involve many thousands (4-zeros) of
   electricity meters (Automatic Metering Infrastructure) (sometimes
   including gas or water meters as leaves). 
   I'm *unaware* of any LLNs that have 10^6 nodes in a single LLN.
   Unfortunately Pascal can't tell you who, because of NDAs he has with his
   customers.  I've been shown evidence with stuff blacked out/redacted.

2) the leaf nodes are sending readings up on a MP2P topology.  There isn't
   much cross-traffic.  So in a homenet context, this is equivalent to there
   being 30 routers in the home, and no PCs/laptops/etc, rather than 3
   routers with 10 desktops each.
   In the homenet situation, cross-traffic would be traffic that somehow goes
   from network 2(F) to network 4(K) without going across network 1.
   In an LLN there might be other paths across the radio links that would
   permit F<->K traffic without using network 1, and P2PRPL is a protocol
   that could find it.

3) the leaf nodes in AMI talk to HQ only.
   There are lighting LLNs that are all cross-traffic though.


Some other things to note:
  a) RPL is not particularly self-configuring, and probably has more
     parameters to tweak than other protocols, but getting it exactly right
     only really matters when you have to worry about bandwidth and energy.

  b) to date, RPL hasn't had a lot of "Internet Standard"-style interop
     validation.  All of the deployments I'm aware of are single-vendor, or
     involve one or two vendors working closely together.  This is sad.

  c) While RPL has a single root to which all traffic flows, in the diagram,
     both A and B would announce their own DODAG in a DODOG Information
     Object (DIO), and the DIO would include Prefix Information Object, which
     is the equivalent of an RA.
     Routes in the network are usually /128 routes, but if one used DHCPv6-PD
     or HNCP to get a /64, one could announce that equally well.
     Announcing exclusively /128s (with L=0, so offlink) does do nice things
     for wifi and mobility.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [