Re: [6tisch] TSV-ART review of draft-ietf-6tisch-architecture

["Pascal Thubert (pthubert)" <[e-mail]>]

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.

> 
>  > 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.

"

>  > * "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.


>  >
> 
>  > * 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.

"

> 
> 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!