Re: [Detnet] Changes of <draft-ietf-detnet-yang-18.txt> last call

[Florian Kauer <[e-mail]>]

For me, everything looks great now, thanks a lot!
I was not able to validate every potential combination that I had in mind yet, but that would anyway take forever...
So please go ahead and thanks again for the discussion!

Greetings,
Florian

On 25.01.24 19:13, Don Fedyk wrote:
> I'm ready to upload. I will do it tomorrow or earlier if Florian agrees - giving one last chance for Florian to respond.
> 
> Thanks
> Don 
> 
> -----Original Message-----
> From: John Scudder <[e-mail]> 
> Sent: Thursday, January 25, 2024 1:11 PM
> To: Don Fedyk <[e-mail]>
> Cc: Florian Kauer <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [Detnet] Changes of <draft-ietf-detnet-yang-18.txt> last call
> 
> Hi Don,
> 
> Thanks to you and Florian for all your efforts in working through Florian’s review. I don’t mean to rush you, but I’m wondering how long you intend to wait for review before publishing a new version. A week seems reasonable to me (and thanks to Reshad for the LGTM) but use your own judgement. 
> 
> Thanks,
> 
> —John
> 
>> On Jan 18, 2024, at 12:02 AM, Don Fedyk <[e-mail]> wrote:
>>
>>
>>
>> Hi  
>> Florian Kauer proposed 3 changes to the DetNet YANG.   I’ve looked at them and they have a minimal impact.  I propose accepting them (see below) .  
>> Here is the summary of the functional changes. I have pushed the full update to the GitHub.  https://github.com/detnet-wg/draft-ietf-detnet-yang
>> I have also pasted below a test example operational data on the changed items with same data (highlighting the changes). 
>> I have verified all examples in the draft appendix are unaffected by the changes and work before and after the change.
>>  
>> For Brevity Only the functional changes and accompanying descriptions are here. See GitHub for full document  you can diff between 18-19.
>>  
>> 1st change remove choice operation type – This change is an optimization. Operation-type is a choice statement.  There is no loss of function removing it.  We had nested choice statements this flattens that logic.
>>  
>> @@ -750,22 +750,18 @@ module ietf-detnet {
>>            description
>>              "These are the flow type next hop choices.";
>>            case ip {
>> -            choice operation-type {
>> +            description
>> +              "Use IP data plane for forwarding.";
>> +            leaf next-hop-address {
>> +              type inet:ip-address-no-zone;
>>                description
>> -                "This is the IP forwarding operation choices.";
>> -              case ip-forwarding {
>> -                leaf next-hop-address {
>> -                  type inet:ip-address-no-zone;
>> -                  description
>> -                    "This is an IP address as a next hop.";
>> -                }
>> -              }
>> -              case mpls-over-ip-encapsulation {
>> -                uses ip-header;
>> -              }
>> +                "This is an IP address as a next hop.";
>>              }
>> +            uses ip-header;
>>            }
>>            case mpls {
>> +            description
>> +              "Use MPLS data plane for forwarding.";
>>              uses rt-types:mpls-label-stack;
>>            }
>>          }
>>  
>> Second instance of 1st change. 
>>  
>> @@ -792,22 +788,18 @@ module ietf-detnet {
>>              description
>>                "These are the flow type next hop choices.";
>>              case ip {
>> -              choice operation-type {
>> +              description
>> +                "Use IP data plane for forwarding.";
>> +              leaf next-hop-address {
>> +                type inet:ip-address-no-zone;
>>                  description
>> -                  "These are the next hop choices.";
>> -                case ip-forwarding {
>> -                  leaf next-hop-address {
>> -                    type inet:ip-address-no-zone;
>> -                    description
>> -                      "This is an IP address as a next hop.";
>> -                  }
>> -                }
>> -                case mpls-over-ip-encapsulation {
>> -                  uses ip-header;
>> -                }
>> +                  "This is an IP address as a next hop.";
>>                }
>> +              uses ip-header;
>>              }
>>              case mpls {
>> +              description
>> +                "Use MPLS data plane for forwarding.";
>>                uses rt-types:mpls-label-stack;
>>              }
>>            }
>>  
>> 2nd change  from an optional leaf of interface-ref to an optional leaf-list of interface-ref.   The current YANG allowed zero  or one interface per Application. Florian requested this be a list.  This allows an application to have zero, one or a set of interfaces.    
>> This is the ingress followed by egress.   (with some cleanup of description text.)
>> @@ -1061,29 +1054,40 @@ module ietf-detnet {
>>                "RFC 9016 Sections
>>                 4.1, 5.8";
>>            }
>> -          leaf interface {
>> +          leaf-list interface {
>>              type if:interface-ref;
>>              description
>> -            "Interface is used for any service type when
>> -             matching all flows to the interface.";
>> +            "Interface is optional for a service type. When
>> +             matching a flow to a single interface one
>> +             interface is specified. The list allows for
>> +             matching a subset of interfaces. When more
>> +             than one interfaces is specified, these
>> +             flows are simply aggregated and the service
>> +             sub-layer is unaware of the aggregation.";
>>            }
>>            uses data-flow-spec;
>>          } //End of app-ingress
>>          container egress {
>>            description
>> -            "Route's next-hop attribute.";
>> +            "Egress DetNet application flows or a compound flow.";
>>            uses data-flow-spec;
>>            choice application-type {
>>              description
>>                "This is the application type choices.";
>>              container ethernet {
>>                description
>> -                "This is TSN unaware traffic that maps to an
>> +                "This is Ethernet or TSN traffic that maps to an
>>                  interface.";
>> -              leaf interface {
>> +              leaf-list interface {
>>                  type if:interface-ref;
>>                  description
>> -                  "This is an Ethernet or TSN interfaces.";
>> +                  "This is one or more Ethernet or TSN interfaces.
>> +                   If multiple interfaces are specified, this
>> +                   application flow is replicated to those 
>> +                   interfaces.  DetNet application Flow filtering
>> +                   applies to the whole list of interfaces.
>> +                   For fine grain flow filtering, use a single
>> +                   interface per application.";
>>                }
>>              }
>>              container ip-mpls {
>>  
>> 3rd Change for a simple IP encapsulation of an Ethernet flow.   The option to directly forward a service sub-layer flow to a forwarding sub-layer was missing.   This is cleaner and aligns with other cases.
>>  
>> @@ -1188,6 +1192,18 @@ module ietf-detnet {
>>                   node or egress node.";
>>                uses detnet-flow-spec;
>>              }
>> +            container forwarding-sub-layer {
>> +              description
>> +                "This entry specifies one or more forwarding
>> +                 sub-layers. No or minimal service sub-layer
>> +                 encapsulation is allowed.";
>> +              leaf-list sub-layer {
>> +                type forwarding-sub-layer-ref;
>> +                config false;
>> +                description
>> +                  "List of outgoing forwarding sub-layers.";
>> +               }
>> +            }
>>            }
>>          }
>>          container outgoing {
>>  
>>  
>> Example of a TSN Ethernet flow arriving on two interfaces and encapsulated in DetNet IP UDP  Unidirectional Ingress – followed by DetNet Decapsulation back to TSN on two interfaces with changes,
>> In the example that follows the version 18 of the draft  XML data validated against the version 19 YANG generated schema.   
>> The following is a version 19 example .
>>  
>> Ingress TSN Application ->service sub-layer-> forwarding sub-layer (UDP)    
>> JSON: 
>>     "app-flows": {
>>       "app-flow": [
>>         {
>>           "name": "app-1",
>>           "bidir-congruent": false,
>>           "outgoing-service": "ssl-1",
>>           "traffic-profile": "pf-1",
>>           "ingress": {
>>             "app-flow-status": "ietf-detnet:ready",  /*Before change  single ref */
>>             "interface": [                                               /*"interface": "eth0",  version 18*/
>>               "eth0",                                     
>>               "eth1"                                      
>>             ],                                            
>>             "tsn-app-flow": {
>>               "vlan-id": 10
>>             }
>>           }
>>         }
>>       ] 
>>     },
>>     "service": {
>>       "sub-layer": [
>>         {
>>           "name": "ssl-1",
>>           "service-rank": 10,
>>           "traffic-profile": "pf-1",
>>           "service-protection": {
>>             "protection": "ordering",
>>             "sequence-number-length": "short-sn"
>>           },
>>           "operation": "initiation",
>>           "incoming": {
>>             "app-flow": {
>>               "flow": [
>>                 "app-1"
>>               ]
>>             }
>>           },
>>           "outgoing": {
>>             "forwarding-sub-layer": {   /* Option did not exist */
>>               "service-outgoing": [
>>                 {
>>                   "index": 1,
>>                   "sub-layer": [
>>                     "fsl-1"
>>                   ]
>>                 }
>>               ]
>>             }
>>           }
>>         }
>>       ]
>>     },
>>     "forwarding": {
>>       "sub-layer": [
>>         {
>>           "name": "fsl-1",
>>           "traffic-profile": "pf-4",
>>           "incoming": {
>>             "service-sub-layer": {
>>               "sub-layer": [
>>                 "ssl-1"
>>               ]
>>             }
>>           },
>>           "outgoing": {
>>             "interface": {
>>               "src-ip-address": "192.0.2.8",       /* No change with removal of choice. */
>>               "dest-ip-address": "192.0.2.1",
>>               "protocol-next-header": 17,
>>               "dscp": 6,
>>               "source-port": 50000,
>>               "destination-port": 50001
>>             }
>>           }
>>         }
>>       ]
>>     }
>>   }
>>  
>> Forwarding Sub-layer -> Service Sub-layer -> Egress  TSN Application interfaces.   
>> JSON: 
>>     "app-flows": {
>>       "app-flow": [
>>         {
>>           "name": "app-1",
>>           "bidir-congruent": false,
>>           "incoming-service": "ssl-1",
>>           "traffic-profile": "pf-1",
>>           "ingress": {
>>             "app-flow-status": "ietf-detnet:ready"
>>           },
>>           "egress": {
>>             "tsn-app-flow": {
>>               "vlan-id": 10
>>             },
>>             "ethernet": {                         /* Before change  single ref */
>>               "interface": [                       /* "interface": "eth0",  version 18*/
>>                 "eth0",
>>                 "eth1"
>>               ]
>>             }
>>           }
>>         }
>>       ]
>>     },
>>     "service": {
>>       "sub-layer": [
>>         {
>>           "name": "ssl-1",
>>           "service-rank": 10,
>>           "traffic-profile": "pf-1",
>>           "service-protection": {
>>             "protection": "ordering",
>>             "sequence-number-length": "short-sn"
>>           },
>>           "operation": "termination",
>>           "incoming": {
>>             "forwarding-sub-layer": {
>>               "sub-layer": [
>>                 "fsl-1"
>>               ]
>>             }
>>           },
>>           "outgoing": {
>>             "app-flow": {
>>               "flow": [
>>                 "app-1"
>>               ]
>>             }
>>           }
>>         }
>>       ]
>>     },
>>     "forwarding": {
>>       "sub-layer": [
>>         {
>>           "name": "fsl-1",
>>           "traffic-profile": "pf-4",
>>           "incoming": {
>>             "forwarding-id": {
>>               "src-ip-prefix": "192.0.2.1/32",
>>               "dest-ip-prefix": "192.0.2.8/32"
>>             }
>>           },
>>           "outgoing": {
>>             "service-sub-layer": {
>>               "sub-layer": [
>>                 "ssl-1"
>>               ]
>>             }
>>           }
>>         }
>>       ]
>>     }
>>   },
>>  
>> Please comment. 
>> Thanks
>> Don 
>>  
>>  
>>  
>>  
>> _______________________________________________
>> detnet mailing list
>> [e-mail]
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/detnet__;!!NEt6yMaO-gk!EeAepDoyrIRu7UqDYswDuZHaSM_eeao2iYy1MwdQ8Sc__tvlpoEAaW-j9x3hIo3LD0Q0oblYHGk$
>