Re: [6tisch] TSV-ART review of draft-ietf-6tisch-architecture
G Fairhurst <gorry@erg.abdn.ac.uk> Wed, 19 June 2019 09:57 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE453120479; Wed, 19 Jun 2019 02:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 ilHcv4IZHZqH; Wed, 19 Jun 2019 02:57:31 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 288BD120478; Wed, 19 Jun 2019 02:57:30 -0700 (PDT)
Received: from G-MacBook.local (unknown [163.173.88.236]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 538D81B00056; Wed, 19 Jun 2019 10:57:25 +0100 (BST)
Message-ID: <5D0A0708.1080404@erg.abdn.ac.uk>
Date: Wed, 19 Jun 2019 11:57:28 +0200
From: G Fairhurst <gorry@erg.abdn.ac.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
CC: "6tisch@ietf.org" <6tisch@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>
References: <MN2PR11MB35657DADCBD430CFBB60F617D8EB0@MN2PR11MB3565.namprd11.prod.outlook.com> <5D08E8ED.3030909@erg.abdn.ac.uk> <MN2PR11MB35657708BF55060550DF93C1D8E50@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35657708BF55060550DF93C1D8E50@MN2PR11MB3565.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/FbN7DtDL278JE1p2o6k2wJBYYtc>
Subject: Re: [6tisch] TSV-ART review of draft-ietf-6tisch-architecture
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Wed, 19 Jun 2019 09:57:35 -0000
See below, On 19/06/2019, 11:50, Pascal Thubert (pthubert) wrote: > Hello Gorry > > I removed the items that appear to be resolved. Please see more below indexed with<PT1> > >> It was originally intended informational. The discussion for the DetNet >> architecture lead to a different track because of external visibility - this spec is >> highly related to IEEE work. >> >> As editor I'm agnostic, up to the A-Ds and I'll respect their decision. >> >> [GF1]: There may be good reasons why this standards-track, but these should >> be clear. At least for me, this means my review will be more detailed. > <PT1> That decision belongs to Suresh. I'll welcome your more detailed review if it comes. > Please note that most of the authors and the editor are non-native, but that we have an excellent RFC editor and this will compensate that I'm sure. [GF2]: I am confident you and Suresh will make a good proposal. >> > Section 3.2 makes reference to an individual draft to describe multicast >> >> > [ID.thubert...] Section 4.1.1 makes a reference to an individual draft that >> >> > appears to target the ROLL WG, mentioned twice as defining something, >> >> > Section 4.1.1 makes a reference to an individual draft that appears to target >> >> > the ROLL WG. >> >> > >> >> [I-D.thubert-6lo-unicast-lookup] is an optimization. I cannot fathom its success >> as RFC. But it is interesting as an architectural construct. >> >> Explaining that what this draft does is an architectural possibility is of interest >> in an architecture document, feels incomplete to ignore it. >> Note that the feature ships using non-standard methods (e.g., derived from >> LISP). I'd rather cite an open document, be it a draft. >> >> The bottom line is that 6TiSCH has been trying to build a complete architecture >> and doing so, found overlaps and gaps between existing RFCs. >> >> We started a number of document in several WGs and int and rtg and working >> hand in hand with experts in others e.g., sec. >> >> Some of those documents are RFCs, e.g., 8505. Others passed WGLC like the >> backbone router and AP ND that are cited in this spec. >> >> This one is only in inception but still addresses a gap that must be discussed in >> the architecture. >> >> Maybe I could rephrase from: >> >> " >> >> A 6LBR located on the backbone may contribute to Duplicate Address >> >> Detection as well as Address Lookup and save multicast operations >> >> [I-D.thubert-6lo-unicast-lookup]. >> >> " >> >> To >> >> " >> >> The use of multicast can also be reduced on the backbone with an optional >> >> registrar that would contribute to Duplicate Address Detection as well as >> >> Address Lookup using only unicast request/response exchanges. >> >> <xref target="I-D.thubert-6lo-unicast-lookup"/> provides an example of how >> >> that can be achieved with an extension of<xref target="RFC8505"/>, using a >> >> 6LBR as a SubNet-level registrar. >> >> " >> >> [GF1]: Thanks this is heading in a good direction, but I think your response >> makes me suggest the context of the citation needs to be clear. >> The word /optional/ doesn't really help. Is it possible to say something more >> like " this is a proposed method that presents an example of how to .... " - to >> clearly show this is NOT a thing yet being progressed in the IETF. >> > <PT1> Sure. Removed optional and inserted your proposed language. > The proposed text is now as follows > " > The use of multicast can also be reduced on the backbone with a > registrar that would contribute to Duplicate Address Detection as > well as Address Lookup using only unicast request/response exchanges. > [I-D.thubert-6lo-unicast-lookup] is a proposed method that presents > an example of how to this can be achieved with an extension of > [RFC8505], using a 6LBR as a SubNet-level registrar. > > " [GF2]: Looks good to me, although maybe this could be: /how to this can be /how this could be/. >> > * "Transport Mode" >> >> > >> >> > Section 4.7.1 describes a "transport mode", but from the perspective of the >> >> > IETF transport area is not a transport. While there have been many >> >> > interpretations of "transports" by SDOs and IETF Specs, I suggest it would >> >> > beneficial to add a few words refining the meaning of the words in the >> present >> >> > usage: e.g. that this does not provide a "transport protocol", but provides a >> >> > way to send and receive IPv6 packets that carry a transport protocol. >> >> The language is inherited from IPSec >> http://www.firewall.cx/networking-topics/protocols/870-ipsec-modes.html >> >> I agree we should migrate to a different terminology as DetNet did in a similar >> collision situation recently. >> >> Would "native" work? By default I'll migrate to that. >> >> >> [GF1]: "Native" is fine, explaining "transport mode" could also fine (it's too late >> to claim we can fix this definition consistenly in all documents, so I am only >> insisting that you explain your meaning of the term. > <PT1> I think it's OK to migrate to native. The work on that piece has not started > yet. This is expected t come from RAW, for which a WG-forming BoF that will > not happen in Montreal. > [GF1]: Please do the right thing, thanks. >> > >> >> > * The IPv6 Flow Label may be zero >> >> > >> >> > Section 4.7.1.1 seems to imply that IPv6 packets carry a non-zero flow label >> >> > value. Whilst I would support that desire, there are still cases where no flow >> >> > label is set, and this casts should be described (or >> >> > noted) in the text. >> >> In general hope it's zero since a non-zero cannot be compressed : ) >> >> But for a Track we need a flow ID. DetNet has immensely progressed on IP and >> now >> >> We have a reference for the words in that section, so I changed to: >> >> " >> >> In native mode, the Protocol Data Unit (PDU) is associated >> >> with flow-dependent meta-data that refers uniquely to the Track, >> >> so the 6top sublayer can place the frame in the appropriate cell >> >> without ambiguity. In the case of IPv6 traffic, this flow >> >> identification may be done using a 6-tuple as discussed in >> >> [I-D.ietf-detnet-ip]. >> >> The flow identification is validated at egress before restoring >> >> the destination MAC address (DMAC) and punting to the upper layer. >> >> " >> >> [GF1]: The new text is fine. I would also not have objected to "Implementations >> of this document SHOULD support identification of DetNet flows based on the >> IPv6 Flow Label field" - esepcillay, if you wish endpoints to set a non-zero >> value. >> > <PT1> Added the text. Note that this creates a ref to BCP 14. To keep it > (std vs info) Track agnostic, I lowercased the SHOULD. Also restored text > That indicates the RPL way to signal a flow. Note that the original design > was to encode the Instance ID in the Flow label but this faced too much > headwinds at 6MAN. The section now reads: > > " > In native mode, the Protocol Data Unit (PDU) is associated with flow- > dependent meta-data that refers uniquely to the Track, so the 6top > sublayer can place the frame in the appropriate cell without > ambiguity. In the case of IPv6 traffic, this flow identification may > be done using a 6-tuple as discussed in [I-D.ietf-detnet-ip]. In > particular, implementations of this document should support > identification of DetNet flows based on the IPv6 Flow Label field. > The flow identification may also be done using a dedicated RPL > Instance (see section 3.1.3 of [RFC6550]), signaled in a RPL Packet > Information (more in section 11.2.2.1 of [RFC6550]). The flow > identification is validated at egress before restoring the > destination MAC address (DMAC) and punting to the upper layer. > > " [GF2]: This seems appropriate, thanks. >> 4.8.3. Differentiated Services Per-Hop-Behavior >> >> >> >> A future document could define a PHB for Deterministic Flows, to be >> >> indicated in the IANA registry where IETF-defined PHBs are listed. >> >> " >> >> The reference was removed. >> >> [GF1]: Sure. (By the way, should there be consensus, such work could be >> proposed in TSVWG.) >> > Shitanshu presented at TSVWG some years ago but the draft was stalled since. > DetNet has taken over the whole subject so I'd say it is in good hands. > > Please let me know if the changes are OK and I'll publish a revision. > > Again, many thanks Gorry! [GF2]: From my side you have addressed my comments, thanks for the prompt action. Gorry
- [6tisch] TSV-ART review of draft-ietf-6tisch-arch… G Fairhurst
- Re: [6tisch] TSV-ART review of draft-ietf-6tisch-… Pascal Thubert (pthubert)
- Re: [6tisch] TSV-ART review of draft-ietf-6tisch-… Pascal Thubert (pthubert)
- Re: [6tisch] TSV-ART review of draft-ietf-6tisch-… G Fairhurst
- Re: [6tisch] TSV-ART review of draft-ietf-6tisch-… Pascal Thubert (pthubert)
- Re: [6tisch] TSV-ART review of draft-ietf-6tisch-… G Fairhurst