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

Simon Duquennoy <simonduq@sics.se> Tue, 23 February 2016 17:39 UTC

Return-Path: <simon.duquennoy@gmail.com>
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 8C5EE1B3B88 for <roll@ietfa.amsl.com>; Tue, 23 Feb 2016 09:39:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.023
X-Spam-Level: *
X-Spam-Status: No, score=1.023 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_GIRL=2.3, 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 d8Hn7jTEfqSG for <roll@ietfa.amsl.com>; Tue, 23 Feb 2016 09:39:55 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BF01B3B82 for <roll@ietf.org>; Tue, 23 Feb 2016 09:39:54 -0800 (PST)
Received: by mail-wm0-x233.google.com with SMTP id g62so4940170wme.0 for <roll@ietf.org>; Tue, 23 Feb 2016 09:39:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=payfXBSsSbIAgap0d18aMNj2moO5ImOBs6p96Gx/BmA=; b=MUWOBJLVfe4zHERNbiskB9xbEa5MC2TLJ24EH7vZ6mT8TpIKJ1EvsryJcwxLGTzGJH K5b9sRFCYATYElN+m5E371lfigIlR5r77uZyc2r7RuaPRrXoawOkyn94nUQK3p5ga4fY RjWY3RU6hYgdxKF2yt+dQQTNynVu+93+BkQwhCcFSmzUPafPddbbYPD2B3c+d8ydmoGz 5ULsSR0W6myG4KwjS3mSMc5siOgv4v8MRN04F4rSlFCTJlY4vOEcv5GlCNaheq+ArpGY rkI5q5gwrpWa4xaEUm6fYfXKAah6e038mFlXO0Ln6JnWDzEVlJKRSdQdPkCFQYW/uiGz UG1A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=payfXBSsSbIAgap0d18aMNj2moO5ImOBs6p96Gx/BmA=; b=k1LGIdH3tumyPN5RbujKLT5hLLXQz3ElfpIKf/AUppN0l6y+qt3eJhEJ1auNa6T+Vt ra7cqm7cMNu/ZPMbPPyDqf3RBd30Z4NVYSX3RoT9M5Ua2MfFkW6SmWkyyigNC3N+OsOX aNuFD2VMRWnc+H2WtTjt/XC/SDsfBFxwNLLinjxb5iH+WIs8Sok+bGf6kD9xeP213/wP SNLy52zznglWimZZs2e2NSZl/EsVq0JXYuyWQ9cCI8LECHsXPlALVauyFXYpv+EpZsv5 qoX6Ejb6K2EB7hU/+wIniquXmj3zXVvjWDL/acPwhjopQeMLCaFrKedsugRRF1IaMdVw SBqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=payfXBSsSbIAgap0d18aMNj2moO5ImOBs6p96Gx/BmA=; b=eLIMNicRkIzAqoFtyNbfCL1acJgwWVE0ilpqXBdr1mHQZYjvaNvKSE25qmCXid6U6S GesHpXXrfIe0XKd/kSXdgsYiYT3bQUCYQ36SaRcKoGrUK8isqDInLUVNwIoRMPEISkVu BoUVCvB3pUziijqkgHS4Mz3PD0zDGrA6Pj/Hdn8FInUHAqEF10CXAAipk7AZW5O4jYlN aAUJOKraauYfNzmj4iid4c1ri9nXdDfQOfQdUgZlJQIGHJYKHKorlM8Nbr/dMyD+9Scx v5PvvO1vQo9KPz1EK6Dhy3oUN1sKUZRo96Ag7tEm+ZfOdijIAucJ37AOOXXLRZ/eoN0m LWGA==
X-Gm-Message-State: AG10YORDxHhFoddwwIzx3EjUIpkXD4o3ac12Rhsa3By/YxNoSXouUKbFRy6R+ZJ5hzy3a13UX0pnmO3fU8KGVA==
MIME-Version: 1.0
X-Received: by 10.194.189.71 with SMTP id gg7mr35117161wjc.127.1456249193431; Tue, 23 Feb 2016 09:39:53 -0800 (PST)
Sender: simon.duquennoy@gmail.com
Received: by 10.194.164.130 with HTTP; Tue, 23 Feb 2016 09:39:53 -0800 (PST)
In-Reply-To: <d88ab77865404790b206a61381099b4d@XCH-RCD-001.cisco.com>
References: <068.083c7610ff2ac4904b0f3d42985de0e5@trac.tools.ietf.org> <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org> <9111.1456113115@obiwan.sandelman.ca> <d88ab77865404790b206a61381099b4d@XCH-RCD-001.cisco.com>
Date: Tue, 23 Feb 2016 18:39:53 +0100
X-Google-Sender-Auth: Qs-wFpIKYND4m9Dy12XhtjHtZrQ
Message-ID: <CAMxvJtKmzv1m5nrFar2yC1tM15FjPr7YqYpJm9iiWz+VsY4fTA@mail.gmail.com>
From: Simon Duquennoy <simonduq@sics.se>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary=047d7bb03ac2e10b4a052c736fe0
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/LHfsOYBKEvGFglVh4rJ1dqMU0EA>
Subject: Re: [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: Tue, 23 Feb 2016 17:39:57 -0000

Michael, Pascal,

I think we need at least #1 in order for the problem to be solved not only
in a 6LoRH context.
Having both #1 and #2 is even more appealing, for more simplicity in the
6LoRH case.

Thanks,
Simon


On Tue, Feb 23, 2016 at 7:45 AM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> For completeness, Michael,
>
> The change Nb2 reverses a decision that makes sure that if a packet with
> an HbH header / RPI escapes the RPL domain, it is immediately discarded.
> This impact has to be weighted.
>
> Cheers,
>
> Pascal
>
>
> > -----Original Message-----
> > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael
> Richardson
> > Sent: lundi 22 février 2016 04:52
> > To: roll@ietf.org
> > Subject: [Roll] how to solve flow from RPL-aware-leaf to
> non-RPL-aware-leaf
> >
> >
> > 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 =-
> >
> >
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>