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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 23 February 2016 06:46 UTC

Return-Path: <pthubert@cisco.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 7D0781A6FB4 for <roll@ietfa.amsl.com>; Mon, 22 Feb 2016 22:46:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.207
X-Spam-Level:
X-Spam-Status: No, score=-12.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_GIRL=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 hh5Rf0ibgqet for <roll@ietfa.amsl.com>; Mon, 22 Feb 2016 22:46:04 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34071A1B45 for <roll@ietf.org>; Mon, 22 Feb 2016 22:46:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2537; q=dns/txt; s=iport; t=1456209963; x=1457419563; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=91cWsSOtMZrh2PxAcyTJlw4v9b+wOB3cyNOmyDWj0fY=; b=byNhwRW+NsDPfkdw3oz77Fish5j5+Y39fv1nyccX/SGRLXg6sfJdTbOf izLMfiDds7Gm3Oo0e3oe21xpxj32pLDPMbMQ4cIgzH8iJGQbP7UyYxHXG mnB0SzPBeHYU6862LqizDq22ulYKIZIljlTKttJRcIqI2bIs1Qd0Oo81d 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0APBQDi/8tW/5JdJa1egzqBPwZLq16OP4FmMYIsgzACgUs5EwEBAQEBAQFkJ4RBAQEBBCdeBAIBCBEEAQEoBzIUCQgCBBMIiBO7DgEBAQEBAQEBAQEBAQEBAQEBARiGEoQ6hCOETAWHWIYKiSUBiESFEo54jkgBIQFAg2Rqhn8GN30BAQE
X-IronPort-AV: E=Sophos;i="5.22,488,1449532800"; d="scan'208";a="240582019"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2016 06:46:02 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u1N6k2PX006984 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Tue, 23 Feb 2016 06:46:02 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 23 Feb 2016 00:46:01 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Tue, 23 Feb 2016 00:46:01 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf
Thread-Index: AQHRbSRsyXI4sJtst06/NzdgD2VkoZ85L+gg
Date: Tue, 23 Feb 2016 06:45:55 +0000
Deferred-Delivery: Tue, 23 Feb 2016 06:45:02 +0000
Message-ID: <d88ab77865404790b206a61381099b4d@XCH-RCD-001.cisco.com>
References: <068.083c7610ff2ac4904b0f3d42985de0e5@trac.tools.ietf.org> <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org> <9111.1456113115@obiwan.sandelman.ca>
In-Reply-To: <9111.1456113115@obiwan.sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.98.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/StWMVYi0tjA-uHv-1XjuowmfBDk>
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 06:46:05 -0000

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>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>