Re: [Rtg-yang-coord] templates for protocol parameters

[Ladislav Lhotka <[e-mail]>]

Hi Stephane,

[e-mail] writes:

> Hi Lada,
>
> The idea sounds good to me. In term of details, we must think about creating "intelligent" templates.
> What I mean is that applying some parameters to some items only.
>
> For example, being able to apply a routing-protocol template to only
> bgp instances which name matches a regexp ...
>
> Here is what I see :
> - being able to apply the template at multiple level (routing-instance
> level, or routing-protocol level)

Sure, we can have another leafref pointing to a template routing instance
- and there can be multiple routing instances of the type "template".

> - if the template is applied at routing-instance level, the
> routing-protocol part of the template routing-instance will apply to
> all routing-protocols that will match the container of the template
> (if type is OSPF within the template, it will apply only to OSPF
> routing protocols)

Yes, we can specify such rules.

> - the name leaves in the template could be used to store a regular
> expression, or maybe we need to use another leaf. The regexp will
> permit to identify which container are eligible for inheritance.

I am not sure it is reasonable to bind semantics to instance names - it
will make the configurations less portable. Maybe such things can be
better handled at the client side, i.e. via a user interface or script.

>
> The main concern I have is if we develop such template for routing,
> would it be interesting to extend it to all configurations ? (routing,
> interfaces ...)

It could probably be done but I'd suggest we discuss these template
routing instances first because that's what we need for deciding whether
we can keep the current design of ietf-routing.

Thanks, Lada

>
> -----Original Message-----
> From: Rtg-yang-coord [mailto:[e-mail]] On Behalf Of Ladislav Lhotka
> Sent: Tuesday, January 27, 2015 11:03
> To: [e-mail]
> Subject: [Rtg-yang-coord] templates for protocol parameters
>
> Hi,
>
> the templates that would allow for sharing/inheriting some protocol parameters may be implemented in the current "ietf-routing" module as
> follows:
>
> 1. Define a new identity for the template routing instances:
>
>     identity template-routing-instance {
>         base routing-instance;
>     }
>
> 2. Define a new leaf under "routing-protocol" for referring to a
>    template protocol instance:
>
>     leaf template-ref {
>         type leafref {
>             path "/rt:routing/rt:routing-instance/rt:routing-protocols"
>                + "/rt:routing-protocol/rt:name";
>     }
>
> With this, a routing instance of the type "template-routing-instance"
> can be configured, and inside it any number of protocol instances (with appropriate types) containing template parameters.
>
> A "real" protocol instance would then use the "template-ref" leaf for pointing to a template protocol instance and share/inherit its parameters.
>
> I think it would then be easy to map inherited parameters in the protocol-centric design to such a template, and vice versa.
>
> Could this work?
>
> Lada
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> Rtg-yang-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C