Re: [Detnet] Discussion Item two <draft-ietf-detnet-yang-18.txt> last call

[Don Fedyk <[e-mail]>]

Hi Florian

Inline [Don]

Thanks
Don 

-----Original Message-----
From: Florian Kauer <[e-mail]> 
Sent: Friday, January 12, 2024 3:41 AM
To: Don Fedyk <[e-mail]>; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
Subject: Re: Discussion Item two <draft-ietf-detnet-yang-18.txt> last call

Hi,
thanks for this summary Don! Just some additions below with [FK] hoping that others would chime in.

Greetings,
Florian

On 11.01.24 20:43, Don Fedyk wrote:
> This is the second item that Florian and I discussed. L2 applications have an interface.  Florian had a question about a single application and multiple interfaces. I suggested that with current configuration any number of app1-a interface eth0, app1-b eth1 could be aggregated in a single service. 
> The same happens at egress.  There is no load balancing is you allowed multiple unspecified interfaces for a single application on ingress or egress. 
> 
> That contrasts with IP and MPLS where several routed interfaces (not specified) could do ECMP on ingress or egress. 
> 
> That was design intent unless others feel there is something we need to address here. Please feel free to comment one way or another but I will take silence as agreed no change.  
> 
> Thanks, 
> Don Fedyk

[FK] Please note that this requires only a tiny change to the YANG model:

--- ietf-detnet.yang    2024-01-12 09:19:56.579591248 +0100
+++ multiple-ingress-interfaces/ietf-detnet.yang        2024-01-12 09:18:32.602683425 +0100
@@ -1058,15 +1058,15 @@
               "Status of ingress application flow. This is an
                operational status and defaults to none if 
                incomplete.";
             reference
               "RFC 9016 Sections
                4.1, 5.8";
           }
-          leaf interface {
+          leaf-list interfaces {
             type if:interface-ref;
             description
             "Interface is used for any service type when
              matching all flows to the interface.";
           }
           uses data-flow-spec;
         } //End of app-ingress


This would then allow to specify

--- case-a-1.json       2024-01-12 09:20:36.564024966 +0100
+++ multiple-ingress-interfaces/case-a-1.json   2024-01-12 09:18:50.702878690 +0100
@@ -64,9 +64,9 @@
           "outgoing-service": "ssl-1",
           "traffic-profile": "pf-1",
           "ingress": {
             "app-flow-status": "ietf-detnet:ready",
-            "interface": "eth0",
+            "interfaces": ["eth0", "eth1"],
             "ip-app-flow": {
               "src-ip-prefix": "2001:db8::1/128",
               "dest-ip-prefix": "2001:db8::8/128",
               "dscp": 6
[Don] 
It is my understanding that in this case we would not specify any interfaces - interface is optional.  I would think at some place in the overall system outside of DetNet you would define the routing instance or VPN DetNet is part of.  I have to ask my co-authors to chime in.  



The two reasons for bringing this up were:
- Symmetry (If we allow multiple egress interfaces for an app_flow, why not also for ingress?)
- Conciseness in certain applications:

I am currently trying to set up a demo for a DetNet router with 5 ingress TSN streams on 5 interfaces and 1 egress interface for the DetNet flows. I do not know ahead which TSN stream comes in via which of the 5 interfaces, so I need to identify them via TSN stream identification.
With the current model I either need to have an additional bridge which adds latency and complexity or need to configure 5*5=25 (!) app_flows to cover all potential combinations.

So it is doable with the current model, but considering the small change and since I do not see any negative side effects, I would love to see this change in the YANG model.