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

[Balázs Varga A <[e-mail]>]

Hi Tim,
Many thanks for the responses.
Proposed changes inline.
Thanks
Bala'zs

-----Original Message-----
From: Tim Chown <[e-mail]> 
Sent: Wednesday, February 17, 2021 11:53 AM
To: Balázs Varga A <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
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 <[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.

<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