Re: [6tsch] Finalized charter
Thomas Watteyne <watteyne@eecs.berkeley.edu> Tue, 06 August 2013 20:08 UTC
Return-Path: <twatteyne@gmail.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD60D21E80AB for <6tsch@ietfa.amsl.com>; Tue, 6 Aug 2013 13:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.459
X-Spam-Level:
X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_43=1, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpRJ-+FdqRgN for <6tsch@ietfa.amsl.com>; Tue, 6 Aug 2013 13:08:52 -0700 (PDT)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEAB21E80AA for <6tsch@ietf.org>; Tue, 6 Aug 2013 13:08:52 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id z11so627117pdj.3 for <6tsch@ietf.org>; Tue, 06 Aug 2013 13:08:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=jLNiVYhQ0Kz0NpS0Fgd5GUwB8/wZqVLV4D2CWBYwFFk=; b=u9h7u+1WWlrHiyu5TijVRPd4k0AnUMgqhvZnZT7Xfwaakx0/hrW6xF2/TxP8Ncd6ep e8pWdGKDQLH4pL53u+B8PQ1Kon4xNpm0SxX/I7JAyisdnfbZIDGFRpJdqoWHC7KBm2vZ AWW8zgl0mDm1PoqE96hi+2kqlRNpMpLeEYFojdVPkQaw35+QvaPYBIlqeHycH+tjdhOh W3JgNDyurBew/h2+25cSJdtrko0yOxS8+ZmmLBR+mgJHRmsoQyvk13oHqUVvYq5fBqjG cyAOhp8DWEDL/cc0iEYNKZVFnbeA8B+mPNPVNGB/x1tazT+xsp5x23Kk8ALCx3PrKBh4 6dkQ==
X-Received: by 10.66.122.99 with SMTP id lr3mr440114pab.187.1375819731783; Tue, 06 Aug 2013 13:08:51 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.147.193 with HTTP; Tue, 6 Aug 2013 13:08:30 -0700 (PDT)
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77236C036B@xmb-rcd-x02.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD8413D32E4@xmb-rcd-x01.cisco.com> <F53FB05E-F897-4E20-BF57-2A34C483004B@viagenie.ca> <59D0F1BC-0A1C-4F7C-94ED-95C3C597CB13@viagenie.ca> <8D23D4052ABE7A4490E77B1A012B6307752430E4@mbx-01.win.nominum.com> <09CE48E0-35A4-46BA-98F9-9EDD3A1C13D5@tzi.org> <03B78081B371D44390ED6E7BADBB4A77236C036B@xmb-rcd-x02.cisco.com>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Tue, 06 Aug 2013 13:08:30 -0700
X-Google-Sender-Auth: INvf_Q4t7Oz11QlVvXcRxJUO8Js
Message-ID: <CADJ9OA-5J_ANSTv5bJp_2PwgQOu1scKm7z=DMCu6FyZQMQFrdQ@mail.gmail.com>
To: 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b2e0e8f63559c04e34cfe4e"
Cc: Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [6tsch] Finalized charter
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2013 20:08:53 -0000
JP, Carsten, Thanks for the very valuable input on the charter. Let me try to summarize your comments and provide an answer to the issues you raise below. *BBR->LBR* *Suggestion from JP. Changing BBR to LBR would align terminology with the ROLL WG.* For reference, here are the definitions in the latest versions of the drafts: - *LBR* (draft-ietf-roll-terminology-12): Low power and Lossy Network Border Router. The LBR is a device that connects the Low power and Lossy Network to another routing domain such as a Local Area Network (LAN), Wide Area Network (WAN) or the Internet where a possibly different routing protocol is in operation. The LBR acts as a routing device and may possibly host other functions such as data collector or aggregator. - *BBR* (draft-thubert-6lowpan-backbone-router-03): An IPv6 router that federates the LLN using a Backbone link as a backbone. A BBR acts as a 6LoWPAN Border Routers (6LBR) and an Energy Aware Default Router (NEAR). These are indeed very close terms. Whatever the name, I believe we are talking about an entity which plays several roles, including handling downstream routes where applicable (RPL), compacting 6LoWPAN header (6LoWPAN), and federating several LLNs under one prefix (ND). As usual, these functions can be co-located in the same box. While I don't have a strong opinion on this, I tend to agree that LBR is a more established term than BBR, and maybe a bit more generic according to the definitions above. Yet, we have already sent the proposed charter to the ADs for review. What I have done is filing https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/5/bbr-lbr, to keep track of your suggestion. We can integrate it if requested during future discussion about the charter with the IESG. *Add PCE to WG to interact with* *Suggestion from JP. The idea is to list PCE as a WG to interact with.* The reason we did not include it in the text is because the definition of the node<->PCE interaction is not within scope of this charter. Work item 1 covers the format of the payload (e.g. the bits and bytes to describe a cell), but not the exact transport solution or interaction. That being said, this is absolutely what we tend towards, and when we explicitly work on that, we will be interacting with the PCE WG. I understand you are suggesting to list PCE right away. I have filed https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/6/add-pce-to-wg-to-interact-with to cover this. *Interaction between Work Item 1 and 2* *Clarifying question from Carsten.* The goal of work item 1 is to describe a format for the PCE to be able to send commands to the nodes, and for the nodes to send statistics and topological information to the PCE. In this version of the charter, we assume that the schedule is static, i.e. we do not address the PCE->nodes traffic yet. That being said, statistics and topological information can flow from node to PCE in a network resulting from work item 2. This for example allows for close monitoring of the health of the network. That being said, the scope of work item 1 is very clear and very "atomic". Management includes setup, update, tear down, as well as getting reports. The scope of work item 1 is not to focus on "network management" as a whole, only to produce formats and methods that can be used by all points of command, including PCE, node configuration, network management, etc. *hard-coded -> pre-configured* *Suggestion from Carsten.* The term "pre-configured" is indeed more elegant than the term "hard-coded". Would you agree, however, that both terms end up expressing the same idea? I have filed https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/7/hard-coded-pre-configured to track and remember this suggestion. Note that there is an intent that we provide a basic schedule that would operate without any configuration. Then through the methods in item 1 we propose to optionally set up an initial schedule that the node will use instead. *changing RPL?* *Clarifying question from Carsten.* The goal of the work at 6TSCH is absolutely not to change RPL, just to describe how RPL can be be used on these time slotted networks. This is probably going to be the biggest piece of the work done in work item 2. What we might do is define some metrics and maybe even an OF, but NOT to request any changes to RPL itself. I would argue that, if the goal were to change RPL, this would appear clearly in the charter text. In the absence of the statement "we want to change RPL", we assume that the reader understands that the goal is to not change RPL. We may study objective functions and new options, in particular to transport a schedule, but we are not chartering to standardize work there. *security in scope?* *Clarifying question from Carsten.* We have had numerous discussion about this last week, including in-person with Yoshihiro, Subir, Rafa, and by e-mail with Rene. I believe we had a very similar discussion with Rene, which you can find at http://www.ietf.org/mail-archive/web/6tsch/current/msg00985.html. Rene agreed with the discussion. In very short, work on security and management is welcome but we do not charter a work item for this round. I hope this answers your questions. Thomas On Mon, Aug 5, 2013 at 5:18 PM, JP Vasseur (jvasseur) <jvasseur@cisco.com>wrote: > Agree with Carsten and Pascal, I would stick to LBR and mention PCE > specifically > > On Aug 5, 2013, at 1:54 AM, Carsten Bormann <cabo@tzi.org> wrote: > > > On Aug 4, 2013, at 20:04, Ted Lemon <Ted.Lemon@nominum.com> wrote: > > > >> The normal pronunciation of this acronym at least in German > > > > For a German: TSCH = Tisch = "tish". > > Add "six" (english pronunciation), and it's "sixtish". > > Not too hard. > > > > On the charter itself: I was rather skeptical about the version we > discussed in Berlin, and I'm now less worried. > > > > I don't quite understand the text for work item 1. Why is this about > querying (which I would have expected in a garden variety management > protocol) and not about setting up? Maybe I don't understand the > relationship between 1 and 2. > > > > Work item 2: s/hard-coded/pre-configured/? > > > > I would probably stick with the "LBR" terminology as others have said. > > > > We may need to discuss how the multi-LBR technology in 6TSCH (ND-proxy?) > relates to that potentially addressed by 6Lo. Since I don't think we will > fully understand the relationship before the charters get finalized, maybe > just note that in the charter. (Maybe it is also worth highlighting any > working relationship with ROLL, if that is required. Is RPL being modified > by 6TSCH?) > > > > The charter currently does not discuss security or management, and I > would prefer a clear statement whether that is in scope (re management, see > comment about work item 1 above; security for bootstrapping a network is a > complex issue where it would surprise me if people think this is in scope). > > > > Grüße, Carsten > > > > _______________________________________________ > > 6tsch mailing list > > 6tsch@ietf.org > > https://www.ietf.org/mailman/listinfo/6tsch > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch >
- [6tsch] Finalized charter Pascal Thubert (pthubert)
- Re: [6tsch] Finalized charter Marc Blanchet
- Re: [6tsch] Finalized charter Marc Blanchet
- Re: [6tsch] Finalized charter Ted Lemon
- Re: [6tsch] Finalized charter JP Vasseur (jvasseur)
- [6tsch] New name Pieter De Mil
- Re: [6tsch] New name Marc Blanchet
- Re: [6tsch] New name Pascal Thubert
- Re: [6tsch] Finalized charter Pascal Thubert
- Re: [6tsch] Finalized charter Carsten Bormann
- Re: [6tsch] New name Mani, Mehdi
- Re: [6tsch] New name Mani, Mehdi
- Re: [6tsch] Finalized charter JP Vasseur (jvasseur)
- Re: [6tsch] Finalized charter Thomas Watteyne
- Re: [6tsch] Finalized charter JP Vasseur (jvasseur)
- Re: [6tsch] Finalized charter Thomas Watteyne