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

[Vishnu Pavan Beeram <[e-mail]>]

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]> 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]>
> *Sent:* Wednesday, August 14, 2024 4:10 PM
> *To:* Vishnu Pavan Beeram <[e-mail]>; Oscar González de Dios
> <[e-mail]>; TEAS WG Chairs <
> [e-mail]>
> *Cc:* [e-mail]; Wubo (lana) <[e-mail]>; Peter Busschbach
> (Nokia) <[e-mail]>; Swamynathan B (Nokia) <
> [e-mail]>; Sergio Belotti (Nokia) <[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
>