Hi Bala'zs, Many thanks, that addresses my comments. Tim > On 18 Feb 2021, at 07:53, Balázs Varga A <balazs.a.varga@xxxxxxxxxxxx> wrote: > > 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
