From: netmod <netmod-boun...@ietf.org> on behalf of Oscar González de Dios
<oscar.gonzalezded...@telefonica.com>
Sent: 31 March 2021 12:07
Agree too,
It makes sense to "generalize" the concept of sets that can be shared between
ACLs, so they can be used with other fields beyond those already identified
with our use cases (prefixes and ports/port ranges) .
So, question for Netmod WG chairs, what would be the procedure to include such
feature in the ACL module, given that it is defined in an already published
RFC? Is it via a new draft describing just the extension and referencing the
original RFC and including the updated yang? Or it is an update of the existing
RFC adding the new functionality (full description and full yang)? I am
assuming the work implies creating a new revision of the module.
<tp.
New revision or new module? RFC7950 lays down what can be changed in a new
revision of a module and it would be good to see in summary what your revised
YANG would look like. I suspect that it would go beyond what is permitted in a
revision ie you are proposing a new module, new name (but I could be wrong:-(.
Either way, it is an RFC. If the changes fall within those permitted then I
would still expect a replacement RFC, as has happened with a number of YANG
modules, e.g. those triggered by NMDA.
The chairs can guide you on procedure but it is the WG members, you, me and
everyone else who have to do the work and so declare their willingness, or not,
to take up the work which the chairs then use to decide whether or not the work
should happen in the WG.
Tom Petch.
Best Regards,
Oscar
-----Mensaje original-----
De: Aseem Choudhary (asechoud) <asech...@cisco.com>
Enviado el: miércoles, 17 de marzo de 2021 17:16
Para: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>
CC: Oscar González de Dios <oscar.gonzalezded...@telefonica.com>;
netmod@ietf.org
Asunto: Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list
to the match
I agree, a template based approach works well as it helps to share the set of
fields between ACLs.
-thanks,
Aseem
On 3/17/21, 8:58 AM, "Juergen Schoenwaelder"
<j.schoenwael...@jacobs-university.de> wrote:
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/>
________________________________
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
