Re: [Detnet] Intdir telechat review of draft-ietf-detnet-ip-over-tsn-05

[Tim Chown <[e-mail]>]

Hi,

Thanks, a few responses in line….

> On 16 Feb 2021, at 16:24, Balázs Varga A <[e-mail]> 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 <[e-mail]> On Behalf Of Tim Chown via Datatracker
> Sent: Sunday, February 14, 2021 4:22 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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