[Teas] Re: issue on multiple match-criterion on the same time for a connectivity-group

["Wubo (lana)" <[e-mail]>]

Hi Pavan, Oscar, Sergio, WG,

We have posted version (-15) to address the comments made by Sergio and Pavan. Thanks for your valuable comments.
Diff is at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-teas-ietf-network-slice-nbi-yang-15


In this version, we enhance “match-criterion” with “match-type“ list, and also improve the overall text description.



Thanks,

Bo


From: Vishnu Pavan Beeram <[e-mail]>
Sent: Friday, August 23, 2024 6:31 PM
To: Wubo (lana) <[e-mail]>
Cc: Sergio Belotti (Nokia) <[e-mail]>; Oscar González de Dios <[e-mail]>; TEAS WG Chairs <[e-mail]>; [e-mail]; Peter Busschbach (Nokia) <[e-mail]>; Swamynathan B (Nokia) <[e-mail]>; Qin Wu <[e-mail]>
Subject: Re: issue on multiple match-criterion on the same time for a connectivity-group

Sergio -- Thanks for bringing this to the WG's attention.

Bo and authors -- Thanks for the quick resolution. The changes to the module and the associated examples seem to be straightforward. Adding another example for this specific scenario would be useful to explain the difference between the "OR" and "AND" application of the match criteria. We (chairs) don't think this warrants another LC (or any change to the shepherd write-up). That said, we'll review the changes when the new revision is available and decide on the next steps.

Regards,
-Pavan and Oscar

On Fri, Aug 23, 2024 at 1:33 PM Wubo (lana) <[e-mail]<mailto:[e-mail]>> wrote:
Dear Pavan, Oscar, Sergio, WG,

After discussing among the authors, we agree that this match criterion enhancement can be added for flexibility without relying on the ACL model reference.

And for ACL, since IETF has multiple ACL enhancement models, which can support many complex rule combinations.
Therefore, it is recommended to leave the ACL as the match criteria as it is. We can add text stating that the ACL name can be used as the "value" when the ACL is used as a match criterion.

We will post a new version to resolve this. At the same time, the authors think that the modification is an enhancement of YANG model and does not change the definition of “match criteria”. We hope this change does not require a second WGLC?

Thanks,
Bo

From: Sergio Belotti (Nokia) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, August 14, 2024 4:10 PM
To: Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>; Oscar González de Dios <[e-mail]<mailto:[e-mail]>>; TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Wubo (lana) <[e-mail]<mailto:[e-mail]>>; Peter Busschbach (Nokia) <[e-mail]<mailto:[e-mail]>>; Swamynathan B (Nokia) <[e-mail]<mailto:[e-mail]>>; Sergio Belotti (Nokia) <[e-mail]<mailto:[e-mail]>>
Subject: issue on multiple match-criterion on the same time for a connectivity-group

Hello Pavan,Oscar, authors, WG,

I know draft-ietf-teas-ietf-network-slice-nbi-yang-14 has passed the WGLC but I’ve discovered a potential issue that heavily affects the model flexibility.

For my understanding of the model there is no possibility to have a combination of match criteria. For example: IF source-ip-address = 1.2.3.4 AND IF dscp = ef THEN map traffic onto target-connection-group X.
So we’d like to obtain that at the same connection-group X, it can be applied two matching criteria at the same time.

The model allows for the identification of multiple values (i.e. “value” is a leaf-list node). In principle, it is possible to identify an ip address and a dcsp value. The draft literally says “Provides a value for the Slice Service match criteria, e.g., IP prefix and VLAN ID”. However, you can only specify one match-type.
The model permit to have  e.g. 2 match criteria   one with source IP address and another with DSCP values both pointing to same connection group or connectivity construct.
So basically taking an example from the draft you could have :

              "service-match-criteria": {
                "match-criterion": [
                  {
                    "index": 1,
                    "match-type": "ietf-nss:dscp",
                    "value": ["EF"],
                    "target-connection-group-id": “matrix6”,
                    "target-connectivity-construct-id": "2"
                  },
                  {
                    "index": 2,
                                "match-type": "ietf-nss: source-ip-prefix",
                                “value”: “1.2.3.4”
                    "target-connection-group-id": “matrix6”,
                    "target-connectivity-construct-id": "2"
                  }

This type of encoding permits the OR of the matching criteria , I mean source-ip-address = 1.2.3.4 OR  dscp = ef., but how I can have the AND of the two ?

I know that for complex combination it is suggested to use the matching criteria type of ACL, defining a specific identity to be used as match-type


  identity acl {
    base service-match-type;
    description
      "Uses Access Control List (ACL) as match criteria
       for the Slice Service traffic.";
    reference
      "RFC 8519: YANG Data Model for Network Access Control
                 Lists (ACLs)";
  }

But there is no guideline on how to use it, and how to encode the “value” field, that is not present in ACL model.
ACL encodes a set of rules consisting of conditions and actions but there is no specific format that is able to capture a set of conditions .

What I would propose to solve the problem would be a list of pairs “match-type” and “value” , with match-type as key and value as another leaf. In this case for any “index” you could have multiple match-type and for the same “index” of match-criterion a combination of more than one match-type.

Something like:

"service-match-criteria": {
                "match-criterion": [
                  {
                    "index": 1,
                    “newlist” : [
                          {
                             "match-type": "ietf-nss:dscp",
                             "value": ["EF"]
                         },
                         {
                             "match-type": "ietf-nss: source-ip-prefix",
                              “value”: “1.2.3.4”
                         }
                   ]
                   "target-connection-group-id": “matrix6”,
                   "target-connectivity-construct-id": "2"
                 },

I think the modification is not complex and the model would be more flexible and “ready to be used” for match combinations instead to exploit another model like ACL.

Thanks
Sergio