[Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 22 February 2016 03:51 UTC

Return-Path: <mcr+ietf@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 2080C1B2AD6 for <roll@ietfa.amsl.com>; Sun, 21 Feb 2016 19:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.292
X-Spam-Level: **
X-Spam-Status: No, score=2.292 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MANGLED_GIRL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 LBwGVoVePmEW for <roll@ietfa.amsl.com>; Sun, 21 Feb 2016 19:51:57 -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 5493B1B2A3D for <roll@ietf.org>; Sun, 21 Feb 2016 19:51:57 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 36DA92002A for <roll@ietf.org>; Sun, 21 Feb 2016 22:52:53 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C842263750 for <roll@ietf.org>; Sun, 21 Feb 2016 22:51:55 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
In-Reply-To: <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org>
References: <068.083c7610ff2ac4904b0f3d42985de0e5@trac.tools.ietf.org> <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org>
X-Mailer: MH-E 8.6; nmh 1.6+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: Sun, 21 Feb 2016 22:51:55 -0500
Message-ID: <9111.1456113115@obiwan.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/pVI6GD2A7fmzdJCIZl9Z4iNHVqg>
Subject: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 22 Feb 2016 03:51:59 -0000

At the interim meeting last fall, we came across two problems for which we have
no clear recommendation, and which we think needs some protocol work.

The situation is described in ticket 173, and in section 5.10 of useofrplinfo.

Consider the packet flow:
   6LN --> 6LR1 --> common parent (6LR2) --> 6LR3 --> not-RPL-aware 6LN

In storing mode the packet goes up to the common parent (which may be below
the root) via typically a default route, and then follows the hop-by-hop down
the tree.  An RPI header needs to be inserted by the 6LN.

In section 5.9 (Flow from RPL-aware-leaf to RPL-aware-leaf), an IPIP is not
necessary, since the receiving node is RPL aware, it can remove the RPI.

In this case, however, the end-node is not RPI aware, so the 6LR3 needs to
remove the RPI.  In order for that to happen, the IPIP header needs to be
addressed to 6LR3, but 6LN doesn't have any idea what 6LR3's address.

here are two possible ways to deal with this issue:

1) Pascal has pointed out that we can use an IPIP header on a hop-by-hop
   basis, using either link-local addresses, or even GUA addresses, but
   each IPIP header needs to be added/removed at each hop.

2) If the definition of the RPI was changed so that it isn't a
   "discard if not recognized" type.  This change is an incompatible
   on-the-wire change, and would represent a flag day.
   However, this change could perhaps be done with the updated 6LoRH
   compression work, as that is also an incompatible on-the-wire
   change for which we presently have no way to signal.

3) These proposals are not mutually exclusive: we could do both.

I'm not looking for "yes, I like proposal X", but rather I'm looking for
replies of the form of "I can not live with proposal X because Y"

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