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