Hi Juergen,

I'd like to be able to choose between a single prefix and a prefix-list which 
could be handled separately for reuse.

               Hence, in the same level as acl[] a container to handle the 
prexi-lists would be added:

The model would look like

CURRENT
--rw acls
        +--rw acl* [name]
                     .....
        +--rw attachment-points
                     ......
              PROPOSED

--rw acls
        +--rw acl* [name]
                     .....
        +--rw attachment-points
                     ......
        +-rw prefix-lists
           |  |  +--rw prefix-list* [name]
(Here the list is defined and is reusable by the acls)

-----

      Then, in the matches, a possibility is to add a case, to avoid touching 
the current model and be backwards compatible.

      CURRENT
choice destination-network {
      case destination-ipv4-network {
        leaf destination-ipv4-network {
          type inet:ipv4-prefix;
          description
            "Destination IPv4 address prefix.";
        }
      }
      description
        "Choice of specifying a destination IPv4 address or
         referring to a group of IPv4 destination addresses.";
    }


       PROPOSED
choice destination-network {
      case destination-ipv4-network {
          leaf destination-ipv4-network {
                type inet:ipv4-prefix;
                description
                    "Destination IPv4 address prefix.";
        }
    case destination-ipv4-prefix-list {
          leaf destination-ipv4-prefix-list {
              type leafref {path_to_where_the_prefix_list_is_defined};
               description
                    "Destination IPv4 address prefix list.";
               }
       }
      description
        "Choice of specifying a destination IPv4 address or
         referring to a group of IPv4 destination addresses.";
    }

I hope this clarifies the intention. Thus, not only specify multiple prefixes, 
but also handling the prefix list for reusability.

Best Regards,

Oscar

-----Mensaje original-----
De: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>
Enviado el: miércoles, 17 de marzo de 2021 13:29
Para: Oscar González de Dios <oscar.gonzalezded...@telefonica.com>
CC: netmod@ietf.org
Asunto: Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list 
to the match

Hi,

let me check whether I understand your request correctly: I heard you saying 
that you would like to have

        leaf-list destination-ipv6-network {
          type inet:ipv6-prefix;
          description
            "Destination IPv6 address prefix.";
        }

instead of just

        leaf destination-ipv6-network {
          type inet:ipv6-prefix;
          description
            "Destination IPv6 address prefix.";
        }

(and similar changes for the other IP prefix related leafs).

While such a direct change may be difficult, given that the header fields are 
defined in a choice, it should be possible to add additional choices for sets 
of prefixes. So from the YANG side, this seems to be something possible to 
address without too much trouble.

Whether implementors are happy with supporting such a change is something 
others have to comment on.

/js

On Wed, Mar 17, 2021 at 10:31:10AM +0000, Oscar González de Dios wrote:
> Dear netmod wg colleagues,
>
>                 The ietf-acl YANG model defined in RFC 8519 allows to create 
> rules, and for each a rule, in case of IPv4/IPv6 you can specify in the match 
> the source-network and destination-network. The source-network (or equally 
> the destination network) is in the model an address prefix. In our use case 
> in Telefonica we are specifying a prefix-list for source network and another 
> prefix list for destination network. If you had to create this behavior using 
> the ACL model, you would need to create NxM rules. Besides, the management of 
> those rules would be more complex.
>
>                 The routing policy model has the concept of prefix-sets, but 
> is a separate model (and a different use case).
>
>                 The functionality of specifying a prefix list for source and 
> destination in access control lists is available in most vendors that I am 
> aware today. Hence, it's a pretty standard functionality.
>
>                 Do you think it is useful to add this functionality to the 
> ACL YANG model? If yes, what would be the procedure, given that ACL is 
> already defined in an existing RFC?
>
>                 Best Regards,
>
>                                Oscar
>
>
>
>
>
> ________________________________
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, 
> puede contener información privilegiada o confidencial y es para uso 
> exclusivo de la persona o entidad de destino. Si no es usted. el destinatario 
> indicado, queda notificado de que la lectura, utilización, divulgación y/o 
> copia sin autorización puede estar prohibida en virtud de la legislación 
> vigente. Si ha recibido este mensaje por error, le rogamos que nos lo 
> comunique inmediatamente por esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is privileged and confidential 
> information intended only for the use of the individual or entity named 
> above. If the reader of this message is not the intended recipient, you are 
> hereby notified that any dissemination, distribution or copying of this 
> communication is strictly prohibited. If you have received this transmission 
> in error, do not read it. Please immediately reply to the sender that you 
> have received this communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> senhoria o destinatário indicado, fica notificado de que a leitura,
> utilização, divulgação e/ou cópia sem autorização pode estar proibida
> em virtude da legislação vigente. Se recebeu esta mensagem por erro,
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> proceda a sua destruição

> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to