Subject: [netmod] list keys

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 08 May 2008 10:08:58 +0200

Hi,

as an exercise, I converted manually the RELAX NG schema that we are
using for our FlowMon probe to YANG. It went quite smoothly, the result
is here:
http://www.yang-central.org/twiki/pub/Main/YangExamples/flowmon.yang

I encountered two problems related to list keys, one minor and one more
serious:

1. In the following list

list interface {
  key ifNumber;
  leaf ifNumber {
    type uint8 {
      range 0..3;
    }
  }
  choice monitoring-mirroring {
    case monitoring-interface {
      ...                
    }
    case mirroring-interface {
      ...
    }
  }
}

I actually want to use the "monitoring-interface" case for ifNumber 0 or
1 and the other case for ifNumber 2 or 3. I could move ifNumber under
the choice statement and make the distinction in each of the case
statements - but is it possible with ifNumber serving as the list key?

2. In this list

list filterCondition {
  ordered-by user;
  choice filter-conditions {
    leaf ipVersion {
      type inet:ip-version;
    }
    container addressRange {
      leaf startAddress {
        mandatory true;
        type inet:ip-address;
      }
      leaf endAddress {
        mandatory true;
        type inet:ip-address;
      }
      container matchAgainst {
        uses address-choice;
      }
    }
  }
  leaf ifNumber {
    type uint8 {
      range 0..1;
    }
  }
}

there is essentially no way how to define the mandatory key. With deep
keys, it would be probably possible to use all contained leafs but IMO
it makes little sense anyway. I propose to drop the requirement to
define a key for lists ordered-by user. If the key is not defined (as it
is here) the system should allocate internally ordinal numbers to list
items that can be used for their addressing.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Phil Shafer <[email-masked]>
Date: Thu, 08 May 2008 12:33:05 -0400

>http://www.yang-central.org/twiki/pub/Main/YangExamples/flowmon.yang

Very cool.

>statements - but is it possible with ifNumber serving as the list key?

I'm confused about how the values relate to the content (and
why interfaces 0 and 1 have inputSampling but not others), but
aren't you really wanting a conditional augmentation?  You want
the common stuff always and the others if ifNum <= 1:

      list interface {
        key ifNumber;
        leaf ifNumber {
          type uint8 {
            range 0..3;
          }
        }
        uses common-interface-content;
        augment . {
            when "ifNumber <= 1";
            container inputSampling {
              leaf samplingMethod {
                type enumeration {
                  enum regular;
                  enum statistical;
                }
                default statistical;
              }
              leaf samplingRate {
                type sampling-rate;
              }
            }
            leaf ifInPackets {
              config false;
              type uint32;
            }
            leaf ifInErrors {
              config false;
              type uint32;
            }
            leaf ifInDiscards {
              config false;
              type uint32;
            }
          }
        }
     }

>items that can be used for their addressing.

I'd rather see explicit names, so both sides know which member
you are talking about and there's no misunderstanding:

          list filterCondition {
            ordered-by user;
            key name;
            leaf name {  // Explicit name
                type string;
                description "Name of this condition";
            }
            ...
          }

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 May 2008 22:28:40 +0200 (CEST)

Hi,

Phil Shafer <[email-masked]> wrote:
> aren't you really wanting a conditional augmentation?

[...]

Another alternative is to use a 'must' constraint:

    list interface {
      key ifNumber;
      leaf ifNumber {
        type uint8 {
          range 0..3;
        }
      }
      choice monitoring-mirroring {
        case monitoring-interface {
          must '../../../ifNumber <= 1';
          ...                
        }
        case mirroring-interface {
          must '../../../ifNumber > 1';
          ...
        }
      }
    }

(Note that YANG currently don't support "must" in a case; I think it
should do that.)

> you are talking about and there's no misunderstanding:

I agree.  Using an explicit name as key also makes deletion via
edit-config easier.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 08 May 2008 22:40:57 +0200

Hi Phil,

> why interfaces 0 and 1 have inputSampling but not others), but

Only interfaces 0 and 1 can do the aggregation of flows (typically from
both directions of the same link), 2 and 3 can be optionally used just
for getting another copy of raw data from 0 and 1, respectively. This is
a firmware limitation.

> the common stuff always and the others if ifNum <= 1:

Yes, this is it, thanks.

>                 description "Name of this condition";

Well, with hundreds of such conditions this looks like a drudgery. No,
we don't use that many conditions, but in a general packet filter it
could easily be the case. For lists ordered by user the automatic
ordinal numbers could be a convenient default.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 08 May 2008 23:14:34 +0200

> (Note that YANG currently don't support "must" in a case; I think it

Yes, it was my first idea, but I found out it was not possible.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C