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

From: Tim Chown via Datatracker <[email-masked]>
Date: Sun, 14 Feb 2021 07:22:03 -0800

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.

p.3
Is “6-tuple” well-defined?  Perhaps expand for clarity.

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?

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”.

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?

p.7
Implementations must -> implementation must (twice)
FRER function -> The FRER function

p.8
of the document -> of this document
challanges -> challenges
Are member -=> are members

p.9
In some case -> in some cases

--
Tim

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 15 Feb 2021 11:19:46 +0000

Thank you Tim for this INT directorate review. I will use it for my ballot.

Regards

-éric

-----Original Message-----
From: Int-dir <[email-masked]> on behalf of Tim Chown via Datatracker <[email-masked]>
Reply-To: Tim Chown <[email-masked]>
Date: Sunday, 14 February 2021 at 16:22
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Int-dir] Intdir telechat review of draft-ietf-detnet-ip-over-tsn-05

    Reviewer: Tim Chown

    Hi,

    Nits:

    p.2

    p.3

    p.4

    p.5

    p.6

    p.7

    p.8

    p.9

    --
    Tim

    _______________________________________________
    Int-dir mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/int-dir

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 16 Feb 2021 16:24:20 +0000

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 <[email-masked]> On Behalf Of Tim Chown via Datatracker
Sent: Sunday, February 14, 2021 4:22 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Detnet] Intdir telechat review of draft-ietf-detnet-ip-over-tsn-05

Reviewer: Tim Chown

Hi,

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

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.

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.

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

p.7
Implementations must -> implementation must (twice) FRER function -> The FRER function
<Bala'zs> OK.

p.8
<Bala'zs> OK.

p.9
<Bala'zs> OK.

--
Tim

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: Tim Chown <[email-masked]>
Date: Wed, 17 Feb 2021 10:52:51 +0000

Hi,

Thanks, a few responses in line….

> On 16 Feb 2021, at 16:24, Balázs Varga A <[email-masked]> wrote:
> 
> Hi Tim,
> 

It would be good I think to make that explicit, i.e (“as defined in RFC 8939”) after the first mention of 6-tuple.

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

> In some case -> in some cases

Best wishes,
Tim

---

From: Balázs Varga A <[email-masked]>
Date: Thu, 18 Feb 2021 07:53:56 +0000

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

-----Original Message-----
From: Tim Chown <[email-masked]> 
Sent: Wednesday, February 17, 2021 11:53 AM
To: Balázs Varga A <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Detnet] Intdir telechat review of draft-ietf-detnet-ip-over-tsn-05

Hi,

> Cc: [email-masked]; [email-masked]; 
> [email-masked]

<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

<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

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

<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

Best wishes,
Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 18 Feb 2021 13:22:41 +0000

Hi Bala'zs,

Many thanks, that addresses my comments.

Tim

> On 18 Feb 2021, at 07:53, Balázs Varga A <[email-masked]> wrote:
> 
> Hi Tim,