Re: [Detnet] response to 3GPP SA2 LS on 3GPP 5G System acting as a DetNet node

[Janos Farkas <[e-mail]>]

Hi Markus,    

Thank you for reviewing and for the additional information!

I think your comment is asked by the updates in the last paragraph, see the most recent version: https://mailarchive.ietf.org/arch/msg/detnet/wP4uddWPlWFhDT1eM-SrYZneQxA/
Is that right?

Best regards,
Janos


-----Original Message-----
From: detnet <[e-mail]> On Behalf Of Markus Isomaki (Nokia)
Sent: Thursday, December 1, 2022 3:25 PM
To: [e-mail]
Subject: Re: [Detnet] response to 3GPP SA2 LS on 3GPP 5G System acting as a DetNet node

Hi all,

Thanks for sharing the draft LS response for review. 

I have a comment and a follow-up question on one point:
	"Please note that in case of an SDN approach, the routing information is provided by the SDN controller towards the network nodes. Therefore, network nodes 	providing routing information towards the SDN controller (e.g., according to RFC 8349) is not necessary."

It is not explained in the 3GPP LS, but I believe that in the case of 5G System acting as a DetNet Node, that DetNet Node will have a special constraint (at least in 3GPP Release 18) that the SDN controller will NOT be able to provide routing information (explicit routes) to it. The Node does have routes but they are separately managed and not influenced by the controller. The open issue in 3GPP has been whether in that case it would be necessary or at least beneficial for the Node to provide its routes to the controller (e.g., according to RFC 8349) as that might still be possible to define in Release 18 beyond just providing information about the neighbour nodes. Or how else would the SDN controller be able to use such a Node on the path of a DetNet flow, as it might not know the next hop where the Node would forward the flow? 

(Note that I am commenting as an individual contributor, not on behalf of 3GPP.)

Regards,
	Markus    


-----Original Message-----
From: detnet <[e-mail]> On Behalf Of Janos Farkas
Subject: [Detnet] response to 3GPP SA2 LS on 3GPP 5G System acting as a DetNet node

WG,

As we discussed at IETF 115, we suggest responding to the LS we received from 3GPP SA2: https://datatracker.ietf.org/liaison/1800/.

Please find below an initial draft proposal for our response.

Please review and comment.

Regards,
János


Dear Colleagues,

The Internet Engineering Task Force (IETF) Deterministic Networking (DetNet) Working Group (WG) appreciates your efforts in support of our technology. We also thank for your liaison https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-d960c2e26169518c&q=1&e=c1834907-3084-4b3c-b422-f7e1b0bbb4e0&u=http%3A%2F%2Fstatement%253chttps%2F%2Fdatatracker.ietf.org%2Fliaison%2F1800%2F%253E informing us about the completion of your Study Item on "Extensions to the TSC Framework to support DetNet".

Please find below our considerations on your question items:

  1.  Please note that in general it is enough to provide the end-to-end delay requirement in the YANG configuration. An SDN controller can perform the delay engineering task and perform the appropriate configuration of the networking nodes without informing them about their delay budget. The configuration of the networking nodes by the SDN controller may also include configuration that is beyond the DetNet YANG configuration, e.g., other IETF YANG or IEEE 802.1 TSN YANG specific configuration, which may affect the delay within that specific node.
     *   For the above, there is no ongoing work in the DetNet WG to specify per node traffic requirements such as delay budget and we are not aware of any such work in any other IETF WG.
     *   It is understood that a 5G System acting as a DetNet node is a special case for which node specific requirements would be beneficial. 5G specific YANG extensions could be specified with the involvement of the appropriate expert in either of our organizations. Please note that IETF is contribution driven. Thus, contributions would be required to start and conduct the specification of the necessary YANG extensions.
  2.  DetNet does not specify the method to be used for topology discovery out of the multiple possibilities, e.g., based on Neighbor Discovery or from OSPF or IS-IS routing protocols. Please note that in case of an SDN approach, the routing information is provided by the SDN controller towards the network nodes. Therefore, network nodes providing routing information towards the SDN controller (e.g., according to RFC 8349) is not necessary.
We look forward to continued collaboration between our organizations.

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