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

On 1/30/15, 7:31 AM, "Ladislav Lhotka" <lhotka@nic.cz> wrote:

>
>> On 30 Jan 2015, at 13:24, Acee Lindem (acee) <acee@cisco.com> wrote:
>> 
>> Hi Stephane, Lada,
>> 
>> Would it be possible to define a general rule where the a value
>>specified
>> for a data node in the template would only be used if that data node is
>> not explicitly specified?
>
>Yes, such an overriding would be useful. We also have to think about what
>to do with (leaf-)lists: if the same list appears in both the template
>and real instance, we could
>
>1. use only the list from the real instance, or
>
>2. merge both lists.

While #2 would be useful at times, I think keeping consistent semantics
(#1) would be preferred.

Thanks,
Acee 

>
>Lada
>
>> 
>> Thanks,
>> Acee 
>> 
>> On 1/30/15, 6:03 AM, "stephane.litkowski@orange.com"
>> <stephane.litkowski@orange.com> wrote:
>> 
>>> 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)
>>> - 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)
>>> - 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.
>>> 
>>> 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 ...)
>>> 
>>> -----Original Message-----
>>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf
>>> Of Ladislav Lhotka
>>> Sent: Tuesday, January 27, 2015 11:03
>>> To: rtg-yang-coord@ietf.org
>>> 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
>>> Rtg-yang-coord@ietf.org
>>> 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.
>>> 
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> Rtg-yang-coord@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>> 
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>