Subject: [netmod] Y09 introduce optional keys

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 16 Sep 2014 19:44:53 +0000

Hi,

In the ISIS model, we are looking for a construct where an ISIS interface attribute applies to level-1, level-2, or both. If it applies to both, that is the only metric that is specified. If you specify different metrics for level-1 and level-2 both can be specified. The snipers below are what we have been discussing. However, it is not really correct. Since if you specify a metric for “all-levels”, you shouldn’t specify anything else in the list. The suggestion was that an optional key could handle this. The alternative would be to have a “metric”, “level-1-metric”, and “level-2-metric”.

grouping interface-level-options {

    leaf level {
      type enumeration {
        enum "level-1" {
          description
            "ISIS level 1";
        }
        enum "level-2" {
          description
            "ISIS level-2";
        }
        enum "level-all" {
          description
            "All ISIS levels";
        }
   }
   default "level-all";
      description
        "Specify ISIS level for the interface command.";
    }
    description
      "ISIS interface level option.”;
}

list isis-metric {

       key "level";
        description "ISIS interface metric";
         leaf value {
                type uint32;
                description "ISIS metric value";
         }
         uses interface-level-options;
}

Thanks,

Acee

Andy Bierman <andy at yumaworks.com<http://yumaworks.com>> wrote:
> On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund <mbj at tail-f.com<http://tail-f.com>> wrote:
>
> > David Reid <reid at snmp.com<http://snmp.com>> wrote:
> > > > Here is a proposal for how to introduce optional keys.
> > >
> > > Adding optional keys seems like a pretty major new feature for
> > > a .1 release. Most of the other issues are fixes or clarifications.
> > > Is the benefit worth the cost?
> >
> > I don't think the cost is that high.  With YANG 1.0, people are forced
> > to use awkward workarounds, and/or vendor-specific extensions to
> > support a use case that seems to be natural in many circumstances.
> > Thus, I think it is better to support this natively.  (Incidentally,
> > just today I got a question from someone involved in the broadband
> > forum work why YANG doesn't support optional keys).
> >
> >
>
> I think the implementation impact is significant, but the feature could be
> useful.
> The protocol complexity increase is worse that the compiler.
> What about adding optional keys to an existing entry?
> IMO this cannot be supported with either RESTCONF or NETCONF.
> The request will be seen by the server as a create, merge, or replace on
> a new resource instance.

Right, and I think this is ok.  In general it would be nice with a
'rename' operation in the protocols, but that is a different issue.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Sep 2014 09:49:00 -0400

> In the ISIS model, we are looking for a construct where an ISIS interface attribute applies to level-1, level-2, or both. If it applies to both, that is the only metric that is specified. If you sp…

It seems a solution can be to use choice. It would allow to specify either one parameter to be used by both (all) levels, or a list of level-specific parameters, but not both. Something like

choice metric {
  leaf metric { … }
  list level-metric {
    key level;
    leaf level { … }
    leaf metric { … }
  }
}

Would it make sense?

Lada

> Andy Bierman <andy at yumaworks.com
> > wrote:
> > On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund <mbj at 
> tail-f.com
> > wrote:
> > 
> > > David Reid <reid at 
> snmp.com
> > wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 17 Sep 2014 14:06:46 +0000

Hi Lada, 
This might be just what we need - I¹ll discuss with the model authors. The
other alternative is to allow all three metrics and use the most specific
specification. In any case, it appears that we are not dependent on
optional keys.  
Thanks,
Acee 

On 9/17/14, 9:49 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>> In the ISIS model, we are looking for a construct where an ISIS
>>interface attribute applies to level-1, level-2, or both. If it applies
>>to both, that is the only metric that is specified. If you specify
>>different metrics for level-1 and level-2 both can be specified. The
>>snipers below are what we have been discussing. However, it is not
>>really correct. Since if you specify a metric for ³all-levels², you
>>shouldn¹t specify anything else in the list. The suggestion was that an
>>optional key could handle this. The alternative would be to have a
>>³metric², ³level-1-metric², and ³level-2-metric².
>
>It seems a solution can be to use choice. It would allow to specify
>either one parameter to be used by both (all) levels, or a list of
>level-specific parameters, but not both. Something like
>
>choice metric {
>  leaf metric { Š }
>  list level-metric {
>    key level;
>    leaf level { Š }
>    leaf metric { Š }
>  }
>}
>
>Would it make sense?
>
>Lada
>    
>
>>  
>>       "ISIS interface level option.²;
>> }
>> 
>> list isis-metric {
>>        key "level";

---

From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <[email-masked]>
Date: Wed, 17 Sep 2014 14:25:26 +0000

Hi Lada,

I had posted an example previously (which I suggested in one of the calls should be added as a note for Y09) -- reproduced here. In this case a "choice" doesn't solve the problem, as there are a set of overlapping identifiers which are actually used as the key.

======
A list entry may have a key which is a union; i.e. it is indexed by a single value which is one of multiple types. However, a YANG union is not always sufficient to model a choice between a set of types.

Take the following case for example:

choice maintenance-domain-identifier {
  leaf host { type inet:host; }
  leaf id   { type hex-string; }
  leaf name { type string; }
}

These strings can be overlapping, so this cannot be represented as a union.
======

There was a discussion of other solutions which involved more controversial extensions to the language (Y53, rejected) -- but it can be solved with Y09 by making each leaf an optional key.

Thanks,
Peyman

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Acee Lindem
> (acee)
> Sent: 17 September 2014 15:07
> To: Ladislav Lhotka
> Cc: [email-masked]
> Subject: Re: [netmod] Y09 introduce optional keys
> 
> Hi Lada,
> >> > The request will be seen by the server as a create, merge, or
> replace
> >>on
> >> > a new resource instance.
> >>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Sep 2014 14:11:35 -0400

Hi Peyman,

I think you are mixing up “choice” as a schema node and the “union” type. In your example there is no amiguity at all.

Lada