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

[<[e-mail]>]

Agree , #1 is better. Specific parameters overriding inherited.


-----Original Message-----
From: Acee Lindem (acee) [mailto:[e-mail]] 
Sent: Friday, January 30, 2015 13:35
To: Ladislav Lhotka
Cc: LITKOWSKI Stephane SCE/IBNF; [e-mail]
Subject: Re: [Rtg-yang-coord] templates for protocol parameters

On 1/30/15, 7:31 AM, "Ladislav Lhotka" <[e-mail]> wrote:

>
>> On 30 Jan 2015, at 13:24, Acee Lindem (acee) <[e-mail]> 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, "[e-mail]"
>> <[e-mail]> 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:[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.
>>> 
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>> 
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>


_________________________________________________________________________________________________________________________

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.