Re: [6tisch] #36 (architecture): Last call comments: MCR comments
"6tisch issue tracker" <trac+6tisch@tools.ietf.org> Tue, 07 April 2015 17:10 UTC
Return-Path: <trac+6tisch@tools.ietf.org>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9389F1B3857 for <6tisch@ietfa.amsl.com>; Tue, 7 Apr 2015 10:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 guX4h-ljvzIX for <6tisch@ietfa.amsl.com>; Tue, 7 Apr 2015 10:10:42 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDCB1B3855 for <6tisch@ietf.org>; Tue, 7 Apr 2015 10:10:42 -0700 (PDT)
Received: from localhost ([::1]:56894 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+6tisch@tools.ietf.org>) id 1YfX1N-0000Dd-Oj; Tue, 07 Apr 2015 10:10:41 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: 6tisch issue tracker <trac+6tisch@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-6tisch-architecture@tools.ietf.org, pthubert@cisco.com
X-Trac-Project: 6tisch
Date: Tue, 07 Apr 2015 17:10:41 -0000
X-URL: http://tools.ietf.org/6tisch/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36#comment:1
Message-ID: <074.718987bbccf3ec32f456f505fb956088@tools.ietf.org>
References: <059.e2bc8dd2f10bac6793e7ecd7268ffea6@tools.ietf.org>
X-Trac-Ticket-ID: 36
In-Reply-To: <059.e2bc8dd2f10bac6793e7ecd7268ffea6@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-6tisch-architecture@tools.ietf.org, pthubert@cisco.com, 6tisch@ietf.org
X-SA-Exim-Mail-From: trac+6tisch@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-6tisch-architecture@ietf.org
Resent-Message-Id: <20150407171042.0BDCB1B3855@ietfa.amsl.com>
Resent-Date: Tue, 07 Apr 2015 10:10:42 -0700
Resent-From: trac+6tisch@tools.ietf.org
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/FuDTzMmyl6T5VwW3zKAh_0WfrPE>
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] #36 (architecture): Last call comments: MCR comments
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2015 17:10:45 -0000
#36: Last call comments: MCR comments Comment (by pthubert@cisco.com): Replying to [ticket:36 shwethab@…]: > If it is going to proceed in volumes (I suggest "editions" is the correct term), then I think that most things which are speculation should either be removed to a later edition, or something specific should be said, with the understanding that it might change later. Presciption rather than speculation should be the goal. We agreed on volume after all, since this is effectively volume 1 of a story to be continued > > 1) I find it odd that there is so much emphasis of the backbone router function... IN THE ABSTRACT. I suggest that the last sentence: Backbone Routers perform proxy Neighbor Discovery operations over the backbone on behalf of the wireless devices, so they can share a same subnet and appear to be connect= ed to the same backbone as classical devices. be removed from the abstract. Probably by the end of this review that I'll suggest a different thing that could be included. > This text is commented out in the abstract > 2) end of section 1, what does it mean: "in the round of this document."? > Means volume, fixed. Says now " Hints are provided on a security framework that will be completed in an upcoming volume of this architecture." > 3) I don't think that [I-D.ietf-roll-rpl-industrial-applicability] will ever get published. If there is terminology there that we still need, I think it should be extracted into the 6tisch-terminology document. While it is an informative reference, the fewer references to IDs the better in my opinion. > But this one is really key on why we do RPL on TSCH at 6TiSCH. I'd rather keep it. > 4) section 4, seems to ignore the possibility to simply run RPL across the subnet backbone. I understand why the ND mechanism are nice, because they permit the backbone to just be ethernet, but the case where the backbone is really dedicated (and given VLANs, it's hard to know why you'd do anything else), one can just run RPL across it. I think that this ultimately matters to any of the later architecture, but I wouldn't want to later argue with someone who might claim that the newer ND mechanisms are REQUIRED. > I agree, anything goes. Routing, MIP/NEMO, ND proxy. Can be anything. New text says: " The Backbone Routers may perform proxy IPv6 Neighbor Discovery (ND) [RFC4861] operations over the backbone on behalf of the wireless devices (also called motes), so they can share a same IPv6 subnet and appear to be connected to the same backbone as classical devices. The Backbone Routers may alternatively redistribute the registration in a routing protocol such as OSPF [RFC5340] or BGP [RFC2545], or inject them in a mobility protocol such as MIPv6 [RFC6275], NEMO [RFC3963], or LISP [RFC6830]." > 5) the security words include: "will be studied in the next round of this document." and I'm not sure what a reader should make of this. Perhaps it should simply summarize section 13 in one sentence and say that PANA is a possibility, but that the choice of protocol is out of scope for this document. (well, 5.0 then explains about volumes. So perhaps the explanation about volumes should go much earlier, most probably into the abstract as well. Also, will the volumes build on the previous work, or will they replace it? if they will replace it, then I think correct word is "edition") I suggest we remove the term debate and say this as follows: " PANA (Layer-3), IEEE802.1x (Layer-2) or some light weight variation of those could be used in the join process. Regardless, the security model must ensure that, prior to a join process, packets from a untrusted device are controlled in volume and in reachability. This piece of the architecture is also deferred to a subsequent volume of the architecture. A status of the work can be found in Section 13. " > > 6) I don't think that the Note: about DETNET really still belongs in a document that might be read in 5-10 years. Maybe a reference to the charter for DETNET would make more sense. > But there is no charter published at the IETF since there is not even a WG forming BoF I reworded as follows " The 6TiSCH Architecture extends the concepts of Deterministic Networking on a Layer-3 network. At the time of this writing, work has started on this general problem under the name DetNet. The 6TiSCH Architecture should inherit from that work and thus depends on it. In turn, DetNet is expected to integrate and maintain consistency with the work that has taken place and is continuing at IEEE802.1TSN and AVnu. " > 7) I don't understand why PANA lives above ACE in figure 3. I think that ACE lives above CoAP/DICE (DTLS is missing, but perhaps understood by DICE). I think that while technically PANA lives on top of UDP, there is of course a layer of EAP, and TLS above it, and perhaps a layer of ACE as well. So I'm not saying that this picture needs to be changed, just to observe this. I suggested one, but please come back to me. I think ultimately we need to move all to COMI, including PANA if we adopt it, but none of that is clear now. > > 8) I think remove: "COMI and the dependent specifications are still work in progress, but getting stable enough at the time of this writing." > OK, removed the whole sentence including the words on DICE. It is really unclear to me where DICE is going at this time. > 9) I am happy with the paragraph on join security in section 5. > > 10) I think that this is confused (bottom of page 9, section 6): > > This architecture expects that a 6LoWPAN node can connect as a leaf to a RPL network, where the leaf support is the minimal functionality to connect as a host to a RPL network without the need to participate to the full routing protocol. The support of leaf can be implemented as a minor increment to 6LoWPAN ND, with the additional capability to carry a sequence number that is used to track the movements of the device, and optionally some information about the RPL topology that this device will join. > > I think that either a minimal RPL permits leaf attachment OR the EARO 6lowPAN ND. I don't think that both are needed? > changed to " This architecture expects that a 6LoWPAN node can connect as a leaf to a RPL network, where the leaf support is the minimal functionality to connect as a host to a RPL network without the need to participate to the full routing protocol. The architecture also expects that a 6LoWPAN node that is not aware at all of the RPL protocol may also connect as a host. This can be achieved with an extension to 6LoWPAN ND, adding the capability to carry a sequence number that is used to track the movements of the device, and optionally some abstract information about the RPL instance (topology) that this device will be reachable over. " > I'm also think that some may confuse this with the join process requirements, which maybe this started out describing, but I don't think that does that. It might describe how nodes which have already joined (been imprinted upon the newtork) can form a network. > Yes the suggestion above removes up the term "join" > Figure 4 seems to do it all without RPL, even though RPL is mentioned, and I don't understand that. It also says DAR and then DAO. That's because a DAR/DAC is needed to carry the unique ID, that must be cached at the root. The DAO takes over after that first exchange, but has only the sequenceNB, but not the ID. > > 11) Reading section 6.1/6.2, I wonder if this just too much detail for an architecture. I also don't see how VLANID is involved (we are talking 802.1q here, right?). I am not saying that the TID and EARO aren't good things; I'm just finding that they just JUMP out here, and I'm not sure a reader has any idea why they are here yet. I think that 6.3 should be far more specific: proxy-ND? LISP? or MIPv6? which is going to be used... I think that reviewers will push back here a lot. Yes, I commented a lot out On the backbone, the InstanceID is expected to be mapped onto a an overlay that matches the instanceID, for instance a VLANID. <!-- out goes: Neither WiFi nor Efficient ND do provide a mapping to VLANIDs, and it is unclear, when a wireless node attaches to a backbone where VLANs are defined, which VLAN the wireless device attaches to. Considering that a VLAN is effectively the IP link on the backbone, adding the InstanceID to both specifications could be a welcome addition. --> > > 12) I think that 6.4 needs be prescriptive, not speculative/suggestive. 6.5 needs to say, "the 6LBR and RPL root functionality are to be co- located in order that the address of the 6LBR be indicated by RPL DIO messages" OK, the section becomes: " When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL root functionalities are co-located in order that the address of the 6LBR be indicated by RPL DIO messages and to associate the unique ID from the DAR/DAC exchange with the state that is maintained by RPL. The DAR/DAC exchange becomes a preamble to the DAO messages that are used from then on to reconfirm the registration, thus eliminating a duplication of functionality between DAO and DAR messages. " > > 13) I think that 6.6 is saying that SEND can not be applied. I think it should be clearer in saying something like: "The threats against IPv6 ND as described in RFC3971 apply as well, but the solution can not work as the route over network does not permit direct peer to peer communication. As can be seen in Figure 4..." > What about " A typical attack against IPv6 ND is address spoofing, whereby a rogue node claims the IPv6 Address of another node in and hijacks its traffic. The threats against IPv6 ND as described in SEcure Neighbor Discovery (SEND) [RFC3971] are applicable to 6LoPWAN ND as well, but the solution can not work as the route over network does not permit direct peer to peer communication. Additionally SEND requires considerably enlarged ND messages to carry cryptographic material, and requires that each protected address is generated cryptographically, which implies the computation of a different key for each Cryptographically Generated Address (CGA). SEND as defined in [RFC3971] is thus largely unsuitable for application in a LLN. With 6LoWPAN ND, as illustrated in Figure 4, it is possible to leverage the registration state in the 6LBR, which may store additional security information for later proof of ownership. If this information proves the ownership independently of the address itself, then a single proof may be used to protect multiple addresses. " > > 14) I think that the relevant parts of [I-D.ietf-roll-rpl-industrial- applicability] need to imported into this document, since this sure looks like a normative reference to me. > I agree that this spec is fundamental to us. But importing it? > 15) section 8 seems to be really the key aspects of the architecture. I think that rather than say, "if the scheduling entity explicitely..." =3D> "hard". I think that it should instead say that there are hard cells and soft cells, and say that 6top can not move hard cells. (but, how would the PCE set them up, if 6top can't move them?) > " The architecture defines "soft" cells and "hard" cells. "Hard" cells are owned and managed by an separate scheduling entity (e.g. a PCE) that specifies the slotOffset/channelOffset of the cells to be added/moved/deleted, in which case 6top can only act as instructed, and may not move hard cells in the TSCH schedule on its own. " > "6top contains a monitoring process which monitors the performance of cells, and can move a cell in the TSCH schedule when it performs bad." > > this seems pretty important an architectural thing, and I think it at least deserves it's own section number. > done > 16) 8.2, insert something to the effect: Most RPL Objective Functions require metrics about reachability, such as the ETX. 6top creates and maintains an abstract neighbor table, and this may be leveraged. ... This information ... > > " 6top also enables the RPL OF to influence the MAC behaviour, for instance by configuring the periodicity of IEEE802.15.4e Extended Beacons (EB's). By augmenting the EB periodicity, it is possible to change the network dynamics so as to improve the support of devices that may change their point of attachment in the 6TiSCH network. " > > But, we aren't using the Enhanced Beacons (they are enhanced, not extended, aren't they? or did I get that backwards again?) for production network use... > > I would write: Consideration was given towards finding a way to embed the Route Advertisements and the RPL DIO messages (both of which are multicast) into the IEEE802.15.4e Enhanced Beacons. It was determined that this produced undue timer coupling among layers, that the resulting packet size was potentially too large, and required it is not yet clear that there is any need for Enhanced Beacons in a production network. > added > > [and then go on to explain how to configure the LinkType, however, I think that this is too much detail for the architecture, and it needs to say something like: The 6TISCH adaptation document will explain the details of confuring a broadcast channel that can accomodate EB, RPL DIOs and Router Advertisements ] > > but, maybe I mis-understand the entire section. > > 17) I think that 8.3 should actually say how the TSGI should be created, and also how the various layers can be synchronized such that the RPL management traffic can provide for the needed frame-based synchronization. I expect that this simply means that 6top needs to be able to trigger(override) the trickle timer if no other traffic has occured in "too long" a time. > > "After consultation with IEEE authors, it was asserted that 6TiSCH can make a full use of the octet to carry an integer value up to 0xFF." > > -> does this need some kind of clear liason statement? > > I think that the concepts introduced in section 6.4 and 6.5 should perhaps be more clearly. While not trying to duplicate the terminology document, I found the way that the CDU concept is introduced was awkward. Perhaps this isn't very important. Maybe moving figure 5 earlier? > > 18) I think that the 4 scheduling paradigms should be mentioned in the introduction as well! To first order, I think that is perhaps the most important thing in the document. > > " If the size of a bundle is configured to fit an average amount of bandwidth, peak emissions will be destroyed." > > (I don't think the word you want is "destroyed". I think that it means that packets will be dropped, but I don't think that describing the dropped packets as destroyed is the correct IETF idiom here, even though it might be grammatically correct) > > 19) 6TiSCH supports three different forwarding model, G-MPLS Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding (6F). > > also should be mentioned in the introduction... > > 20) last comment on section 13. (the bullet (*) has become an ASCII "A", the high bit was likely removed) > > Device Authentication: The JN and the JA mutually authenticate each other and establish a shared key, so as to ensure on-going authenticated communications. This may involve a server as a third party. > > I again say that this is incorrect, the JA will never be able to authenticate itself to the JN. It may be able to present some authorization from the network owner, that the JA is authorized to act on behalf of the network owner. > > Unless you consider un-authenticated DH exchange "authentication", or you decide that it's okay for the JA to just not accept any public (some kind of leap of faith), the JA will not have an identity that a JN will accept. > > I have also repeatedly complained that figure 10 is inaccurate, because it fails to depict that authorization begins before authentication finishes. Perhaps the second two unidirectional arrows are part of the authentication phase, I don't know. > > I suggest that the sentence: > > "The join protocol consists of three phases:" > > be replaced with: > > "The join protocol has three major activities:" ("phases" implies some ordering such that one phase might finish before the next begins, while activities implies no such ordering) > > I suggest that figure 10 be omitted. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6tisch- shwethab@cisco.com | architecture@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: | Version: architecture | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36#comment:1> 6tisch <http://tools.ietf.org/6tisch/>
- [6tisch] #36 (architecture): Last call comments: … 6tisch issue tracker
- Re: [6tisch] #36 (architecture): Last call commen… 6tisch issue tracker
- Re: [6tisch] #36 (architecture): Last call commen… 6tisch issue tracker
- Re: [6tisch] #36 (architecture): Last call commen… Michael Richardson
- Re: [6tisch] #36 (architecture): Last call commen… 6tisch issue tracker
- Re: [6tisch] #36 (architecture): Last call commen… 6tisch issue tracker
- Re: [6tisch] #36 (architecture): Last call commen… Pascal Thubert (pthubert)
- Re: [6tisch] #36 (architecture): Last call commen… Michael Richardson
- Re: [6tisch] #36 (architecture): Last call commen… 6tisch issue tracker
- Re: [6tisch] #36 (architecture): Last call commen… 6tisch issue tracker
- Re: [6tisch] #36 (architecture): Last call commen… 6tisch issue tracker