Re: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-04.txt

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 06 April 2016 13:38 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61F012D1C2 for <roll@ietfa.amsl.com>; Wed, 6 Apr 2016 06:38:31 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0oVoQ-cqG7OW for <roll@ietfa.amsl.com>; Wed, 6 Apr 2016 06:38:30 -0700 (PDT)
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 4A71712D522 for <roll@ietf.org>; Wed, 6 Apr 2016 06:37:13 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 182122002A for <roll@ietf.org>; Wed, 6 Apr 2016 09:40:44 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0CBCD6375A for <roll@ietf.org>; Wed, 6 Apr 2016 09:37:12 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <23332.1459885282@obiwan.sandelman.ca>
References: <20160405193517.7205.97237.idtracker@ietfa.amsl.com> <23332.1459885282@obiwan.sandelman.ca>
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: Wed, 06 Apr 2016 09:37:12 -0400
Message-ID: <32389.1459949832@obiwan.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/QJvhPAgjK0gqdoRnLdpvPwPG6rw>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-04.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 06 Apr 2016 13:38:31 -0000

Michael Richardson <mcr+ietf@sandelman.ca>; wrote:
    > Again: my point from before, we can get rid of hop-by-hop IPIP headers by
    > changing the Option Type, or by creating some signal that there
    > are no non-RPL nodes.

The revised proposal at 6man this morning (not yet in text of a draft) is
that all current Option Types become ignore if node does not understand.
(A note can be configured to understand a HbH and drop it)

This means that we do not need to change our Option Type to get the behaviour
that I think we would like.

It also means that we do not need to remove the RPI header before sending
traffic to the Internet.  This is significant because it means that we do not
need an extra IPIP header for traffic leaving the LLN.
We still need an IPIP (+RPI+ RH3-for-non-storing) for incoming traffic, and
we still want to compress it.

That incoming traffic *COULD* now include an RPI from another LLN, but that's
okay, we probably have to encapsulate in IPIP to add our own RPI.
Could we reuse an RPI that is already there, I'm not sure.

A really important result is that we can remove all cases and consideration
of cases where the target is not known to support RPI.

If this WG agrees with the 6man proposal, I will remove those cases from
useofrpi and explain why.

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