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