Re: [Detnet] Comparing DetNet YANG models - Application Part

["Gengxuesong (Geng Xuesong)" <[e-mail]>]

Hi WG,

In DetNet YANG Model Call meeting of yesterday,  we together further analyzed the difference between current two yang modules: one from the current draft,  and the other one from what Don has uploaded in github. Here are some conclusion which could also be treated as feedback of questions raised by Don’s previous email:

1.       It is still under discussion about what should be included in  DetNet “service sub-layer” instance, especially whether the parameters in service sub-layer encapsulation should be included, e.g. flow identification and sequence number, which could be included in service sub-layer or in forwarding sub-layer, together with all other encapsulation relevant parameters (The authors agree to go back to  the RFC8655 and try to figure out which one will be more propitiate based on the design of DetNet architecture)

2.       There are two options about how to organize the parameters inside each DetNet node (including edge node/relay node/transit node):

1)       current draft: there are in-segment and out-segment for each sub-layer in DetNet node

-          Edge node: application in-segment -> application out-segment -> forwarding in-segment->forwarding out-segment

-          Relay node: forwarding in-segment->forwarding out-segment->service in-segment->service out-segment->forwarding in-segment->forwarding out-segment

-          Transit node: forwarding in-segment->forwarding out-segment

2)       Don’s proposal: try to make it simple, and there is only one direction in each sub-layer

-          Edge node: [in: application flow, service sub-layer] [out: forwarding sub-layer]

-          Relay node: [in: service sub-layer] [out: forwarding sub-layer]

-          Transit node: [out: forwarding sub-layer]
(The summary above is based on my understanding. If there is anything wrong, please correct me.)
The discussion will be continued in the next call meeting. If anyone in WG is interested in DetNet YANG Model are welcome to join us.

Best Regards
Xuesong
From: Don Fedyk [mailto:[e-mail]]
Sent: Friday, April 10, 2020 12:21 AM
To: 'DetNet WG' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; 'DetNet Chairs' <[e-mail]<mailto:[e-mail]>>; 'Janos Farkas' <[e-mail]<mailto:[e-mail]>>; '유연철' <[e-mail]<mailto:[e-mail]>>; 'Lou Berger' <[e-mail]<mailto:[e-mail]>>; 'Balázs Varga A' <[e-mail]<mailto:[e-mail]>>; Mach Chen <[e-mail]<mailto:[e-mail]>>
Subject: Comparing DetNet YANG models - Application Part

Hi

Here is some more details from my notes on the DetNet Applications YANG comparisons.

Differences between these YANG Models comparing the tree
1)      Current Detnet YANG Model ietf-detnet-config v5
2)      Prototype Detnet YANG proposed by me in Github repo.
https://github.com/detnet-wg/draft-ietf-detnet-yang/files/4250955/ietf-detnet-flow.tree.txt


It looks like the two trees have different starting assumptions.
Here is my starting Assumptions:

  *   Much of the YANG for DetNet exists and we are pulling together existing pieces.
The Detnet Architecture models the Application as a source and destination of traffic.

  *   My assumption is DetNET does not need to model the complete application – just the DetNet portion.
Consider a voice over IP application.  This is an application that receives voice data perhaps in analog or digital form.
There are parameters about encoding the voice, the service the control plane etc. that are external to DetNet.
The Voice application adds an IP header to the packet.
Another example would be a voice application that is on a remote node and now the IP arrives a the DetNet domain edges.
It is an application because it is using a non DetNET header (or a DetNet header form a different domain) .  This ignores interworking scenarios between DetNet domains. They are out of scope for now.
Given that what does and Application do? It identifies flows by labels. Then it assigns traffic parameters and forwards to the Service Sub layer.
On application ingress(in-segment).

Where the DetNet Application comes in:
At some point in the application there is an IP flow with certain bandwidth and delay characteristics for the voice packets.
This is the starting point for the DetNET application YANG.
A ingress stream of packet with a header and traffic characteristics.
(Also an egress stream of packets with the native header IP).
In other words the application may be the generator of traffic but the part DetNet needs to model already has a packet with a headers.
Similarly we never pull off the full header on egress even though a part of the application may well do this.
The egress just passes the packet back to the application.

Functionally the DetNet application portion is identifying flows to be carried by DetNet on ingress.
The flows arrive in a native format.
It is forwarding on those flow back to there native format.

Looking at the models:
For the model for 2.
On ingress I match on Flow model parameters (IP and MPLS)  (Ethernet was intentionally not in my models but would be added one we agree).
And there are traffic parameters that are configured for this flow.
In the model I currently call both of these interfaces. I’m assuming some could be internal interfaces and others are physical interfaces or virtual interfacing on physical ports.
On egress from the application there is nothing to do but follow the next hop base on the native header.
An Egress packet arriving from the service-sub layer is now the original packet header because the service and forwarding sub-layer have terminated and we have the packet as it was formatted by the far end applications.

Comparing Model 1) on Application ingress
Application IP matching In-segment.
In 2 )I reused RFC 8519 as a matching input.  (Not all fields are used just those mentioned in Detnet Flow Document)
In 1 )there are parts of RFC 8519 but it seems to jump to ports without discriminating on protocol (TCP-UDP)
There are also fields that go beyond the flow model. It also seems to be tied right into the application

Application MPLS header
On application ingress(in-segment)
In1 There is a stack from RFC 8294 in the non-platform label space and only a single label under the platform label space.
In 2) I reused RFC 8294 MPLS label stack under the interface or platform label space.

On application egress (out-segment)
In 2) We have an egress next hop.  This the application address space IP or MPLS.
This is straight from a routed next hop.
The forwarding sublayer has remove any DetNet sublayer header form this domain.

In 1) I think there is a lot that does not need to be there.
To me it looks like the model assumes it was the whole application. (It it’s trying to adjust packet headers)
It has a Detnet header – the application should not see a Detnet header It should not see layers.
It has refences to the service and forwarding sub-layers. -Why?

Some Specific Items
In 2) I use an Application name and added  AppID  to application (serviceID)s .  My feeling was although any application can uniquely identified by name a system generated ID would be useful.  However that we can pulled the AppID and leave it to vendors.  The flow document uses identifier.

In 2) the term TSN is used. We agreed on the call it should be Ethernet.

Please feel free to comment.  We can go over these points in the  next call.
Cheers
Don