Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 06 January 2015 23:13 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1633B1A01CB; Tue, 6 Jan 2015 15:13:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 lDJLgH6ySPKD; Tue, 6 Jan 2015 15:13:32 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B925A1A016A; Tue, 6 Jan 2015 15:13:32 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0351320098; Tue, 6 Jan 2015 18:18:52 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 585E0637FE; Tue, 6 Jan 2015 18:13:31 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3D87A63745; Tue, 6 Jan 2015 18:13:31 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <4A5D805B-B73E-49E9-952E-8A4683E20C24@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD848AC2314@xmb-rcd-x01.cisco.com>, <CE9445B8-BA8E-4112-B892-6BCDED74D8DC@gmail.com> <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <97A18603-2934-481E-8859-711B00FB359F@gmail.com> <29592.1420563714@sandelman.ca> <4A5D805B-B73E-49E9-952E-8A4683E20C24@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 06 Jan 2015 18:13:31 -0500
Message-ID: <11092.1420586011@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/DI7SSV3u_mRSbWUDiNou9UvbH5Q
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG <ipv6@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jan 2015 23:13:36 -0000

Ralph Droms <rdroms.ietf@gmail.com> wrote:
    >> Ralph Droms <rdroms.ietf@gmail.com> wrote:
    >>> But ... in my opinion, moving the LLN artifacts to the header/dispatch
    >>> in the way defined in draft-thubert-6lo-routing-dispatch raises,
    >>> implicitly, an important architectural issue: is the information in the
    >>> dispatch header compressed IPv6 headers or headers for an independent,
    >>> sub-IP protocol?
    >>
    >> My answer is that a sub-IP protocol can encapsulate arbitrary layer-3 packets.
    >> In particular, one can have overlapping IP addressing contexts,

    > "addressing contexts"?

It's a meaningless and ambiguous term, particularly in IPv6.  Perhaps there
is a better one in some BEHAVE document.
What I mean is that you can run ten different 10.0.0.0/8 RFC1918 networks
simultaneously on the same link using one of the sub-IP protocols...

    >> In the LLN case, the l3-layer is constrained; the additional "tag" (the RPL
    >> Instance ID) is used to select a particular QoS much like the DSCP can do.
    >> Routing between instanceIDs is assumed;

    > ..instanceIDs covering intersecting sets of nodes; i.e., some nodes are
    > part of multiple instances?

Correct, any node could be part of multiple DODAGs which have been optimized
differently.  Whether those nodes will route traffic along a shorter path
than going to (respective) DODAG roots, and then out again is really outside
of our scope, let's just agree that it is a reasonable.
(Consider a powered light bulb router that participates in both the light
control DODAG, and also the TV remote control DODAG)

    >> but potentially not every node has
    >> the specific routes that permits it to do that.

    > Not sure how that relates to a sub-IP protocol for carrying source routes and RPL tags?

I guess it depends upon what you mean by "sub-IP".
I think that we are speaking about it in the former IETF AREA sense; things
which are below IP, which have a layering distinction from IP, and which
can simultaenously carry a multitude of layer-3 protocols.  MPLS for
instance.

Are you considering 6lowpan HC to be a sub-IP protocol?
Is PPP a sub-IP protocol?
Is PPP VJ compression a sub-IP protocol?

    >>> My understanding is that the IETF has made an architectural decision to
    >>> do all the mesh network forwarding and routing in IPv6, so as to reuse
    >>> as much as possible existing technology and associated infrastructure
    >>> such as OAM.  If the dispatch header does not contain compressed IPv6
    >>> headers, per se, then this architectural question would lead me to
    >>> investigate the completeness of the new protocol and the impacts of the
    >>> new protocol on IPv6 and network operations.
    >>
    >> I think that all of the HC methods *can* be implemented as Bump-in-the-Stack
    >> activities;

    > That statement gets to part of my question about
    > draft-thubert-6lo-routing-dispatch: in the abstract, is
    > draft-thubert-6lo-routing-dispatch intended to provide a mechanism
    > through which the original RPI, RH3 and IP-in-IP headers can be
    > reconstructed before sending the resulting IPv6 datagram up to the IPv6
    > stack?  At the risk of being overly concerned with the details, I
    > really mean "reconstruct the header" as opposed to "carry information
    > that can be used to perform the same function".

I think that this is the intent, and I see this as a good thing.

    >> and in particular the loop LLN->ethernet->LLN should be
    >> lossless(%).

    > ...where both LLNs and ethernet are part of the same RPL instance?

Yes, exactly: ethernet bridge of LLN between metal floors or other radio
opaque barriers.

    >> A think that concerns me is that I think that most constrained devices will
    >> not implement HC as a bump in the stack, but will uncompress the headers
    >> directly into internal control structures, and may have loose the ability to
    >> process uncompressed 6553/6554 headers.

    > Yeah.  We already see a side-effect of this form of implementation in
    > the desire for compression techniques that do not result in expansion
    > during transit, because such expansion can require re-fragmentation of
    > a datagram that might otherwise be forwarded in place without
    > explicitly uncompressing to the full IPv6 representation.

    >> One could view this as a vestigal appendix-like thing that evolved away.
    >> This could be regarded as good: less unused/untested code that will get
    >> exploited.  This could be regarded as bad: as frame sizes in LLN radios grow
    >> (802.15.4g, I'm told, has much larger frames) some systems might have no
    >> 6lowpan layer, and interoperation opportunities might become difficult.

    > I think there are also important issues to think about the interaction
    > between a sub-IP protocol and the rest of the IPv6 protocol.  If the
    > abstraction is that the sub-IP bits reconstruct into IPv6 headers, we
    > may have less collateral damage to worry about.  Documents defining
    > that behavior will beed to be careful to show the details and that the
    > conversions are lossless.

I agree completely.
One of the concerns I realized with rpl-flow-label was that it created an
alternative to 6553 which was not equivalent.  It's better actually, even on
Ethernet-like media.  It's also easier to implement in ASICs and current
protocol stacks because filters which match the flow label area available
already.  As such, if we go the rpl-flow-label way, we should probably
obsolete 6553 since we have present way to negotiate or announce what
should be used for a given network.

--
]               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    [


--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-