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

[G Fairhurst <[e-mail]>]

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