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

[Don Fedyk <[e-mail]>]

Hi 
There are two items that remain in the long discussion with Florian. 

This is the first point we need to resolve.  DetNet Yang can be used for a wide variety of DetNet encapsulations.  A configuration allows aggregation and disaggregation using IP and MPLS. Florian pointed out though that he was having difficulty with and L2 Application in a Detnet IP UDP encap. Below is an example. 

This is how you might config the incoming application to IP Detnet Flow. (This part required no change) 
...
    "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",
            "interface": "eth0"
          }
        }
      ]
    },
    "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": {
              "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",
              "dest-ip-address": "192.0.2.1",
              "protocol-next-header": 17,
              "dscp": 6,
              "source-port": 50000,
              "destination-port": 50001
            }
          }
        }
      ]
    }
  },
 ... 

At the Egress you have the reverse.  
The "+"s show a missing option when not adding a full service header.
Strictly speaking this option just adds clarity and symmetry with the ingress side config. Without the change you have a Service sublayer that has no specific reference  to the forwarding sub layer.  
 
I think it is worth adding this.      

   "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": {
            "ethernet": {
              "interface": "eth0"
            }
          }
        }
      ]
    },
    "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"
              ]
            }
          }
        }
      ]
    }
  },

This requires a small addition to the YANG model. I 

@@ -1189,6 +1189,19 @@ module ietf-detnet {
                  node or egress node.";
               uses detnet-flow-spec;
             }
+            container forwarding-sub-layer {
+              description
+                "This entry allows passing the packet directly to
+                 one or more forwarding sub-layers. This option may
+                have no or minimal service sublayer encapsuation.";
+              leaf-list sub-layer {
+                type forwarding-sub-layer-ref;
+               config false;
+                description
+                  "List of incoming or outgoing forwarding sub-layers that
+                   have to aggregate or disaggregate.";
+               }
+            }

While I was testing this, I noted that a container labeled mpls-over-ip-encapsulation is more appropriately labeled ip-encapsulation. I think this is more accurate - it has no impact on any yang data and minimal yang/tree change.  

@@ -760,7 +760,7 @@ module ietf-detnet {
                     "This is an IP address as a next hop.";
                 }
               }
-              case mpls-over-ip-encapsulation {
+              case ip-encapsulation {
                 uses ip-header;
               }
             }
@@ -802,7 +802,7 @@ module ietf-detnet {
                       "This is an IP address as a next hop.";
                   }
                 }
-                case mpls-over-ip-encapsulation {
+                case ip-encapsulation {
                   uses ip-header;
                 }
               }

I need co-authors to speak up and consensus this a good idea. 

Thanks

Don Fedyk