Re: [Rtg-yang-coord] container with presence

Susan Hares <shares@ndzh.com> writes:

> Lada:
>
> A clearer example, is the I2RS BGP modules is dependent on the BGP
> protocol.  How would you use a "must" to require the BGP protocol
> exist.  The L1 portion of the I2RS topology model may be dependent on

If it is sufficient that the BGP protocol is configured in any routing
instance, the must expression would be

must "/rt:routing/rt:routing-instance/rt:routing-protocols/"
   + "rt:routing-protocol[rt:type='bgp:bgp']";

provided there exists a BGP module that's integrated into the core
routing data model and defines the identity 'bgp'.

In YANG 1.1, it will be possible to use the new XPath function
'derived-from-or-self':

must "/rt:routing/rt:routing-instance/rt:routing-protocols/"
   + "rt:routing-protocol[derived-from-or-self(rt:type,'ietf-bgp','bgp')]";

> the L1 TEAS definitions.  How would you write that dependency in the
> yang module?

It depends on what the dependency really is. If what is required is just
the existence of a certain node, it suffices to put that node alone in a
must statement.

>

> If there is an RFC or draft I should read, just point it out.

In YANG 1.0 it is essentially XPath 1.0 plus the current()
function. This is the spec:

http://www.w3.org/TR/xpath/

and here is a tutorial:

http://www.w3schools.com/xpath/

YANG 1.1 will add a couple of useful functions:

https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-05#section-10

Lada

>
> Sue 
>
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz] 
> Sent: Thursday, May 28, 2015 7:43 AM
> To: Susan Hares
> Cc: Rtg-yang-coord@ietf.org
> Subject: Re: [Rtg-yang-coord] container with presence
>
> Hi Sue,
>
>> On 28 May 2015, at 13:18, Susan Hares <shares@ndzh.com> wrote:
>> 
>> Lada: 
>> 
>> Thank you for this suggestion. How would you suggest the I2RS yang models for I2RS RIB, I2RS Topology, and I2RS FB-RIB use the 
>
> These models don’t define routing protocols, so why should they augment "rt:routing-protocol”?
>
> However, the use of presence containers is a common workaround for all situation where mandatory data are needed inside an augment. Another example is the if:interface list in the ietf-interfaces module, where config data for a specific interface type (augmented into the list from another module) might include mandatory items.
>
> Another solution that doesn’t need an extra presence container is to use a “must” statement. 
>  
>
>> 
>> 
>>     augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>         +"rt:routing-protocol" {
>>       when "rt:type = 'i2rs:i2rs'" {
>>         description
>>          "This augment is only valid when routing protocol
>>           instance type is i2rs.";
>>       }
>>       presence "I2RS routing protocol”;
>>       ...
>>     }
>> 
>> If a modules depends on L1 TEAS model or l2  how should this be tested?
>
> Sorry, I don’t understand, what exactly do you want to test?
>
> Lada
>
>>  
>> 
>> 
>> Sue 
>> 
>> -----Original Message-----
>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Ladislav Lhotka
>> Sent: Thursday, May 28, 2015 5:29 AM
>> To: Rtg-yang-coord@ietf.org
>> Subject: [Rtg-yang-coord] container with presence
>> 
>> Hi,
>> 
>> I have a suggestion for the authors of all routing protocol modules: the container that encapsulates all configuration data for a given protocol should be a container with presence (see sec. 7.5.1 in RFC 6020) because then the configuration data may include mandatory items that are otherwise forbidden at the top level of an augment.
>> 
>> See also YANG 1.1 issue Y26:
>> 
>> https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27
>> 
>> For example, in the the ietf-isis it should look like this:
>> 
>>     augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>         +"rt:routing-protocol" {
>>       when "rt:type = 'isis:isis'" {
>>         description
>>          "This augment is only valid when routing protocol
>>           instance type is isis.";
>>       }
>>       presence "IS-IS routing protocol”;
>>       ...
>>     }
>> 
>> I am also including this recommendation in the routing-cfg draft.
>> 
>> 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
>> 
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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