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

[Lou Berger <[e-mail]>]

Janos,

I suggest a minor clarification below.

On 11/25/2022 1:57 PM, Janos Farkas wrote:
>
> 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 statement 
> <https://datatracker.ietf.org/liaison/1800/> 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.
>      1. 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.
>      2. 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.
>
How about:

DetNet does not specify the method to be used for topology discovery 
from 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, explicit routing information may be provided by an SDN 
controller to the network nodes. While not needed for all SDN use cases, 
network nodes can provide both explicit and dynamic routing information 
to an SDN controller (e.g., according to RFC 8349).

Lou

> 1.
>
> We look forward to continued collaboration between our organizations.
>
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet