Hi Tim,
Many thanks for the responses.
Proposed changes inline.
Thanks
Bala'zs
-----Original Message-----
From: Tim Chown <Tim.Chown@xxxxxxxxxx>
Sent: Wednesday, February 17, 2021 11:53 AM
To: Balázs Varga A <balazs.a.varga@xxxxxxxxxxxx>
Cc: int-dir@xxxxxxxx; last-call@xxxxxxxx; detnet@xxxxxxxx; draft-ietf-detnet-ip-over-tsn.all@xxxxxxxx
Subject: Re: [Detnet] Intdir telechat review of draft-ietf-detnet-ip-over-tsn-05
Hi,
Thanks, a few responses in line….
> On 16 Feb 2021, at 16:24, Balázs Varga A <balazs.a.varga@xxxxxxxxxxxx> wrote:
>
> Hi Tim,
>
> Many thanks for the review and the nits.
> Updates will be done according to comments added inline.
>
> Thanks
> Bala'zs
>
> -----Original Message-----
> From: detnet <detnet-bounces@xxxxxxxx> On Behalf Of Tim Chown via
> Datatracker
> Sent: Sunday, February 14, 2021 4:22 PM
> To: int-dir@xxxxxxxx
> Cc: last-call@xxxxxxxx; detnet@xxxxxxxx;
> draft-ietf-detnet-ip-over-tsn.all@xxxxxxxx
> Subject: [Detnet] Intdir telechat review of
> draft-ietf-detnet-ip-over-tsn-05
>
> Reviewer: Tim Chown
> Review result: Ready with Nits
>
> Hi,
>
> Re: INT-DIR review of draft-ietf-detnet-ip-over-tsn-05
>
> This draft details how a DetNet IP data plane can run over a TSN sub-network.
>
> I have reviewed this document and believe it is Ready for publication, with Nits. Note I am not overly familiar with specifics of the DetNet architecture.
> There are some hopefully simple questions that might be addressed and some minor editorial nits as detailed below.
>
> Nits:
>
> p.2
> Expand TSN on first use, rather than on page 4.
> <Bala'zs> Ack.
>
> p.3
> Is “6-tuple” well-defined? Perhaps expand for clarity.
> <Bala'zs> 6-tuple is defined in detail in rfc8939 (it is referred in this document).
It would be good I think to make that explicit, i.e (“as defined in RFC 8939”) after the first mention of 6-tuple.
<Bala'zs> OK, I will add an explicit reference (as You have proposed) at end of first paragraph in section 3.
OLD TEXT
[RFC8939] describes how IP is used by DetNet nodes, i.e., hosts and
routers, to identify DetNet flows and provide a DetNet service. From
a data plane perspective, an end-to-end IP model is followed. DetNet
uses "6-tuple" based flow identification, where "6-tuple" refers to
information carried in IP and higher layer protocol headers.
NEW TEXT
[RFC8939] describes how IP is used by DetNet nodes, i.e., hosts and
routers, to identify DetNet flows and provide a DetNet service. From
a data plane perspective, an end-to-end IP model is followed. DetNet
uses "6-tuple" based flow identification, where "6-tuple" refers to
information carried in IP and higher layer protocol headers as defined
in [RFC 8939].
END
> p.4
> Is there a specific reason to show a multi-homed TSN node?
> Are there implications if it is multi homed in TSN but not IP?
> <Bala'zs> No specific reasons, just shows that "TSN-aware Talker" nodes may be multi-homed.
> No implications if multi-homed in TSN but not in IP, that is a valid TSN-aware Talker scenario.
OK, I just wondered why the example showed that; it begs the question how multi-homing is handled and the implications if it’s in principle transparent to the IP layer.
<Bala'zs> OK, I will add an explicit note to the end of the paragraph before figure 1, as follows:
OLD TEXT
... Node-1 is single homed and Node-2 is dual-homed
to the TSN sub-network.
NEW TEXT
... Node-1 is single homed and Node-2 is dual-homed
to the TSN sub-network and they are treated as Talker or
Listener inside the TSN sub-network. Note, that from TSN
perspective dual-homed characteristics of Talker or Listener
nodes are transparent to the IP Layer.
END
> p.5
> Not being familiar with DetNet in detail it might be useful to expand on the rationale for mapping to multicast given the statement that the flow is “directed”.
> <Bala'zs> OK. It is quite usual to use multicast addresses for TSN Streams. And they are "directed" within the TSN sub-network.
OK, I’m no expert in this area, it just seemed odd to talk of multicast being “directed” in that way.
<Bala'zs> Yes, terminology may need some improvement. I will change "direct" to "forward":
> p.6
> covers required -> covers the required I note it says there are no
> requirements stated for TSN-unaware nodes in the document, but is it worth adding something about requirements to ensure the TSN Relay can be reached?
> <Bala'zs> Text change is OK. In case of TSN-unaware nodes, reaching
> the TSN relay is a task for the TSN sub-network. :--))
But how does it handle that if the node is unaware? It just wasn’t clear to me, but maybe it is to experts in TSN :)
<Bala'zs> OK, that is a requirement on control and management plane. TSN networks management
have a "Talker/Listener group" information set, where "EndStationInterfaces" parameter group
(see 46.2.3.3 in IEEE 802.1Qcc) specifies the distinct point of attachment of the TSN-unaware
node to the TSN network. So the control/management entities of the TSN network can setup
the e2e connection via a TSN Relay.
> p.7
> Implementations must -> implementation must (twice) FRER function ->
> The FRER function <Bala'zs> OK.
>
> p.8
> of the document -> of this document
> challanges -> challenges
> Are member -=> are members
> <Bala'zs> OK.
>
> p.9
> In some case -> in some cases
> <Bala'zs> OK.
Best wishes,
Tim
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
