Re: [Roll] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt

Martin Turon <mturon@nestlabs.com> Mon, 01 December 2014 16:17 UTC

Return-Path: <mturon@nestlabs.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 C8B781A6F2E for <roll@ietfa.amsl.com>; Mon, 1 Dec 2014 08:17:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
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 G-WL-PPCnb5H for <roll@ietfa.amsl.com>; Mon, 1 Dec 2014 08:17:41 -0800 (PST)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64DA1A6F20 for <roll@ietf.org>; Mon, 1 Dec 2014 08:17:40 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id rp18so9357928iec.24 for <roll@ietf.org>; Mon, 01 Dec 2014 08:17:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j/oZfQjb6VR2G54q5zNrEbV74jEhpLvC5oxEHSNpC1k=; b=XP6XTNi57hAnlMAS1IsovJkHJrz77bW0c+/4r1H0urvTjJCPM132PQ63oH1dmV//Rx X18PL5tMktlVf+VA00ha1XG/sgliLGu7TMQ+snqqdPNj4qsZPYro0weMAnFK2kHpBSAv QI9Is4l8ub/x7TBgDEJ4AGUVwgFN2wa2mkBR8ZtWtQTZcdLzwB9BRac/0rPZ2F/vOaJh xUal0VT0J6+7fQ90eOpdxTiWUlvrDmRL9JdijhrzJCgL3WMFugNTMi2PEvKVP8x3D/PB KX2etYU1ypkrASVBZBag8a0kvcpqXyTVGnhLrcsT0Jo2etLUkngH6JSww2j0Fb5o6IDq 3IZg==
X-Gm-Message-State: ALoCoQkQIgZiELIXAs7cZbQpJpzkESzQStB+ox/qwj1zAVJafDGWtk9jH85r3rvC8KWlJUb17yAq
MIME-Version: 1.0
X-Received: by 10.107.5.76 with SMTP id 73mr16183299iof.74.1417450659925; Mon, 01 Dec 2014 08:17:39 -0800 (PST)
Received: by 10.42.128.72 with HTTP; Mon, 1 Dec 2014 08:17:39 -0800 (PST)
In-Reply-To: <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com>
References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <E045AECD98228444A58C61C200AE1BD848A7DE36@xmb-rcd-x01.cisco.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com>
Date: Mon, 1 Dec 2014 08:17:39 -0800
Message-ID: <CAH=LnKRe3OUnTtWzWdwmBP_kyyR81Q_VWYgtYzWr5EUmrzTxWQ@mail.gmail.com>
From: Martin Turon <mturon@nestlabs.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary=001a113ef748128ed2050929f33d
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/qk2bifADlVgBsw_XJBjkBABBxmQ
X-Mailman-Approved-At: Mon, 01 Dec 2014 10:51:10 -0800
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [Roll] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt
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: <http://www.ietf.org/mail-archive/web/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: Mon, 01 Dec 2014 16:17:45 -0000

Hi Pascal,


On Sun, Nov 30, 2014 at 12:59 AM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> The discussion already caused a rethinking of the idea. If it is not
> enough we can dig further.
>

Ok, this is certainly reassuring.  I'll admit my initial reaction to the
draft was based more on the understanding of intent from the call than on a
thorough read of the text.  Some of the initial text describes reassigning
the 10 bits that signal a mesh header, and that spawned the concern.


> The idea as presented in the draft now is not to deprecate the mesh header
> but to allow in a different network to use the bits differently knowing
> that devices will have to be homogeneous inside one network.
>

Yes, providing a path to not preclude existing mesh header networks to live
on in isolation is certainly a requirement.  That mixed networks would have
to adopt this new draft seems reasonable.


> You were the advocate to protect the future by not consuming too many bits
> in the NHC proposal. You also realize that the mesh header consumes 1/3 of
> the whole dispatch space, without a way to extend what's done inside. This
> is not protecting the future.
>

I won't argue with you there.  I remain an advocate for protecting the
future, while not overtly forcing deprecation on existing deployments.
Given a a clear upgrade path, and proper forward support path for mesh
header networks, your proposal certainly deserves proper review and
consideration.


> The new proposal allows to encode the existing MH with limited change but
> now it is extensible. The price to pay is different network. And the
> question to the group is whether that is acceptable.
>

Splitting old and new across different networks is certainly reasonable.

One question inspired by this is how would newer dispatch implementations
deploy to a legacy dispatch network?  Imagine a large open network spanning
a city, with multiple versions of 6lo, and multiple routing protocols
running on top.  It's a very academic, futuristic example, but triggers
some basic questions like: how is versioning handled in 6lo?  I believe
versioning in 6lo currently is always done at deployment time.  It may be
worth considering a way to add an optional version dispatch in RHI to
signal what version of 6lo is being used, so mixed version networks in the
future can have a better chance of coexisting.


> Even if there are implementations today, RFC 4944 is not an internet std
> and we have just seen the very beginning of the IoT. Better fix things now
> than later...
>

Only HC1 and HC2 were deprecated from RFC4944 as far as I know.
Deprecating those was the right decision.  There may be more in RFC4944
that can be changed or improved, but the point is that the assumption must
be that most of it is in use today, and consideration for those networks
that use it should be made.  It sounds like you have been making those
considerations, which is appreciated.

Martin


> Pascal
>
> > Le 29 nov. 2014 à 20:24, Martin Turon <mturon@nestlabs.com> a écrit :
> >
> > Hi Pascal,
> >
> > I thought the call where this idea of overloading the mesh header was
> presented was met with general discontent.
> >
> > Also, the rfc4944 calls it the mesh header, it isn't called the
> mesh-under header.  The mesh header is very much in use today, and not
> purely for mesh-under conceptual designs.
> >
> > I would be wary of proposals that greatly alter the 6lo header,
> especially the dispatch bits, rather than extend it in very general ways.
> >
> > Martin
> >
> >> On Nov 27, 2014, at 6:03 AM, "Pascal Thubert (pthubert)" <
> pthubert@cisco.com> wrote:
> >>
> >> Dear all:
> >>
> >> This is a response to the question about the compression of RFC 6553 on
> top of RFC 6554.
> >> It seems exaggerated to consume a dispatch type for the RPL option only.
> >> But here, we introduce a routing header which is the equivalent of the
> mesh header in RFC 4944; we propose a compressed TLV format that can encode
> RH3, RPL option, IP-in-IP, and is further extensible, for instance for
> upcoming  BIER.
> >> As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressable
> space for application only in Mesh-under.
> >> This draft reuses that space in Route-over with the assumption that
> Route-over will not co-exist in a sma enetwork with Mesh-under encoded in
> the RFC 4944 fashion.
> >> If there is effectively a need for co-existence, devices have to
> implement the new Mesh-under format that is also proposed in the draft.
> >>
> >> Comments welcome,
> >> Pascal
> >>
> >>
> >> -----Original Message-----
> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >> Sent: jeudi 27 novembre 2014 14:36
> >> To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent
> Toutain; Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann
> >> Subject: New Version Notification for
> draft-thubert-6lo-routing-dispatch-00.txt
> >>
> >>
> >> A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt
> >> has been successfully submitted by Pascal Thubert and posted to the
> IETF repository.
> >>
> >> Name:        draft-thubert-6lo-routing-dispatch
> >> Revision:    00
> >> Title:        A Routing Header Dispatch for 6LoWPAN
> >> Document date:    2014-11-25
> >> Group:        Individual Submission
> >> Pages:        19
> >> URL:
> http://www.ietf.org/internet-drafts/draft-thubert-6lo-routing-dispatch-00.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-thubert-6lo-routing-dispatch/
> >> Htmlized:
> http://tools.ietf.org/html/draft-thubert-6lo-routing-dispatch-00
> >>
> >>
> >> Abstract:
> >>  This specification provides a new 6LoWPAN dispatch type for use in
> >>  Route-over and mixed Mesh-under and Route-over topologies, that
> >>  reuses the encoding of the mesh type defined in RFC 4944 for pure
> >>  Mesh-under topologies.  This specification also defines a method to
> >>  compress RPL Option (RFC6553) information and Routing Header type 3
> >>  (RFC6554), an efficient IP-in-IP technique and opens the way for
> >>  further routing techniques.  This extends 6LoWPAN Transmission of
> >>  IPv6 Packets (RFC4944), and is applicable to new link-layer types
> >>  where 6LoWPAN is being defined.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>
> >> The IETF Secretariat
> >
> > _______________________________________________
> > 6tisch mailing list
> > 6tisch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tisch
>