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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
