IETF Logo Mail Archive

Re: [6lo] Fwd: New Version Notification for draft-toutain-6lo-local-extensions-00.txt

Carsten Bormann <cabo@tzi.org> Mon, 04 August 2014 08:45 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DF01B28B8 for <6lo@ietfa.amsl.com>; Mon, 4 Aug 2014 01:45:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 DPufBLMiBn4z for <6lo@ietfa.amsl.com>; Mon, 4 Aug 2014 01:45:28 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA721A000C for <6lo@ietf.org>; Mon, 4 Aug 2014 01:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s748jFAh008565; Mon, 4 Aug 2014 10:45:15 +0200 (CEST)
Received: from [192.168.217.145] (p54891648.dip0.t-ipconnect.de [84.137.22.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C93F1B77; Mon, 4 Aug 2014 10:45:14 +0200 (CEST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <81B5F86C-4E20-4E3B-8E00-D50259F4A45A@cisco.com>
Date: Mon, 04 Aug 2014 10:45:13 +0200
X-Mao-Original-Outgoing-Id: 428834713.289014-cb1e3790e069352567bb33c9f5fd1f31
Content-Transfer-Encoding: quoted-printable
Message-Id: <35DE7DA2-9903-4E40-97BA-969D31D38CD4@tzi.org>
References: <20140627091254.30936.25418.idtracker@ietfa.amsl.com> <CABONVQaLyO7VYiUW7SKFK7FRi++O5tfbwuOW-y1ifS21_TykUQ@mail.gmail.com> <CAK=bVC_yYe+au_4AvBoGCi_d2FSOUa=UkGadX+WqSf5jRdXrCQ@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD842D04B39@xmb-rcd-x01.cisco.com> <B015BB2A-A797-4193-AFF6-F701B5CC9D4E@tzi.org> <E045AECD98228444A58C61C200AE1BD842D04E3D@xmb-rcd-x01.cisco.com>, <5AFFA89F-1D05-4037-B9A7-1F989596A2F9@tzi.org> <81B5F86C-4E20-4E3B-8E00-D50259F4A45A@cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/6lo/5fmPN3KoiqdroBecpNPkOI7Ouj8
Cc: "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [6lo] Fwd: New Version Notification for draft-toutain-6lo-local-extensions-00.txt
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 08:45:35 -0000

On 03 Aug 2014, at 15:19, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

> Good start Carsten…

Thanks!

> We need to include source routing, talk about fragments etc…

Fragments are covered in the current draft.

I didn’t try to include RFC 6554 source routing because I first wanted to cover the functionality of the flow label draft, which is WGLCing over in ROLL/6man.  Obviously, given the dominance of non-storing mode, source routing is important.  Before designing this (probably as a separate dispatch type):

— Are there packet captures available that we could use as a corpus to discuss encoding choices?
— What are values of CmprI and CmprE that we are seeing in real networks (i.e., that this should be optimized for)?
— Do we need the segments left feature, or can we simply discard segments in each forwarding router?
— Can we use the hop limit field of the encapsulated IP packet, or do we need our own hop limit like in the RFC 4944 mesh header?
— How is ICMP error message generation done in real-world RPL implementations?  How much of that needs to be preserved?

This obviously is a bit more work than covering the information in the flow label draft, so I’m not sure it should be done now given the urgency that is being attached to that draft.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email