[Roll] processing of multiple SRH-6LoRH
Michael Richardson <mcr+ietf@sandelman.ca> Fri, 22 April 2016 13:48 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 1877712ED22 for <roll@ietfa.amsl.com>; Fri, 22 Apr 2016 06:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level:
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] 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 msDxbmvJwQJa for <roll@ietfa.amsl.com>; Fri, 22 Apr 2016 06:48:41 -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 8A1D312EC65 for <roll@ietf.org>; Fri, 22 Apr 2016 06:48:41 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 562C32002A; Fri, 22 Apr 2016 09:53:08 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AF54863755; Fri, 22 Apr 2016 09:48:40 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
X-Attribution: mcr
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: Fri, 22 Apr 2016 09:48:40 -0400
Message-ID: <3835.1461332920@obiwan.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/ToAdpwJiABh4F9zHAbM0Mg2ATyc>
Subject: [Roll] processing of multiple SRH-6LoRH
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: Fri, 22 Apr 2016 13:48:43 -0000
Pascal,
section 5.5 of routing-dispatch says:
Else (meaning that this is the last entry in the SRH-6LoRH header),
and if there is no next SRH-6LoRH header after this then the SRH-
6LoRH is removed.
Fair enough.
Else, if there is a next SRH-6LoRH of a Type with a larger or equal
value, meaning a same or lesser compression yielding same or larger
compressed forms, then the SRH-6LoRH is removed.
okay, so when the new SRH provides more bytes, we remove the consumed one.
Else, the first entry of the next SRH-6LoRH is popped from the next
SRH-6LoRH and coalesced with the first entry of this SRH-6LoRH.
To get here, the next SRH-6LoRH must be of a higher level of compression,
so it encodes addresses with fewer bytes. What is the logic to making the
next next 6LoRH smaller (popping), and keeping the larger current 6LoRH?
Why not just drop the current 6loRH here and have fewer bytes, period?
Or am I mis-reading this. Maybe I have to write an example of what I think
this is saying.
--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
- [Roll] processing of multiple SRH-6LoRH Michael Richardson
- Re: [Roll] processing of multiple SRH-6LoRH Pascal Thubert (pthubert)
- Re: [Roll] processing of multiple SRH-6LoRH Michael Richardson