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

[Tim Chown <[e-mail]>]

Hi Bala'zs,

Many thanks, that addresses my comments.

Tim

> On 18 Feb 2021, at 07:53, Balázs Varga A <[e-mail]> wrote:
> 
> 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