I now understand that the original request was about two things:
- allowing sets of prefixes in an ACL (instead of just a single)
- sharing of sets of prefixes between ACLs
And yes, if the WG goes there, then of course the same questions will
come up for all the other possible header fields...
- allowing sets of ports/port ranges
- sharing of sets of ports/port ranges between ACLs
[...]
/js
On Wed, Mar 17, 2021 at 03:49:11PM +0000, Aseem Choudhary (asechoud) wrote:
> Hi,
>
> Similarly, there is NxM issue when there are more than one source and
> destination port/port ranges.
>
> -thanks,
> Aseem
>
> On 3/17/21, 5:29 AM, "netmod on behalf of Juergen Schoenwaelder"
> <netmod-boun...@ietf.org on behalf of j.schoenwael...@jacobs-university.de>
> wrote:
>
> 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/>
>
> _______________________________________________
> 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/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
