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

[Florian Kauer <[e-mail]>]

Hi,
these two changes would definitely improve the YANG model for IP data plane usage.
Just one observation below with [FK].

Greetings,
Florian

On 11.01.24 20:43, Don Fedyk wrote:
> 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

[FK] What I am missing now here is a way to specify the next hop IP address. I think we need that regardless whether we add IP headers in the forwarding sub-layer or not.
I would argue we do not need the operation-type anymore and can just do this:

        choice flow-type {
          description
            "These are the flow type next hop choices.";
          case ip {
            description
              "Use IP data plane for forwarding.";
            leaf next-hop-address {
              type inet:ip-address-no-zone;
              description
                "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;
          }
        }

>             }
>           }
>         }
>       ]
>     }
>   },
>  ... 
> 
> 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