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

[유연철 <[e-mail]>]

Hi Don, and Florian.
Thank you for finding the missing part and finding a good solution through a long discussion.
Perhaps initially, in the case of the IP data plane, there was no operation of the service sub-layer, so only the forwarding sub-layer was considered, so that part seems to have been missed.
In the case of IP, since flows have already been classified at the forwarding sub-layer based on 6-tuples, it seems unnecessary to perform flow identification at the service sub-layer again with the same value. As in the example, it seems like a good idea to use the flow identification already classified in the forwarding sub-layer through the forwarding sub-layer reference in the service sub-layer.
Thanks.

Yeoncheol Ryoo

> 2024. 1. 12. 오전 4:43, 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
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
>