Subject: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Feb 2012 13:15:05 -0800

Hi,

I was trying to update the modules on netconfcentral.org, and yangdump
is complaining about ietf-routing.yang. 1 fatal error and some warnings.

    unique "interfaces/interface/name";

    Error: list node (interface) within unique stmt 'interfaces/interface/name' for node 'interfaces/interface/name'
    [email-masked]:185.7: error(352): invalid unique-stmt node

A unique-stmt for container/list/leaf is not allowed.  Only container and leaf are allowed.
RFC 6020 may not be clear on this.  Martin should fix it ;-)

It can work if there is only 1 node in the 'uniqueness tuple and only 1 list in the path.
But except for that special case, list cannot deterministically produce a set of instances
that belong to the same tuple, for comparison to another tuple.

If I comment out the unique-stmt, then I get these warnings from ipv4 and ipv6 modules:

     Warning: sibling object 'address' already defined in module 'ietf-ipv4-unicast-routing' at line 85
     ietf-ipv6-unicast-routing.yang:93.5: warning(425): duplicate sibling node name from external augment

     Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132
     ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment

     Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63
     ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment

     Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68
     ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment

     Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132
     ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment

     Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63
     ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment

     Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68
     ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment

These warnings are because each module does an external augment on
the same target, using the same 'route-content' grouping.  So all siblings
have duplicate local-names in different namespaces.

I really think it sets a bad precedent to intentionally cause local-name
collisions -- to be as XML namespace dependent as possible.
The user-friendly thing to do would be to always add your own sub-container.
This is how CLI keeps things straight.  E.g.:
(note container insertion before 'uses route-content')

   augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/"
         + "rt:routes/rt:route" {
     when "../../rt:address-family='ipV4' and "
        + "../../rt:safi='nlri-unicast'" {
       description
         "This augment is valid only for IPv4 unicast.";
     }
     description
       "This augment defines the content of IPv4 unicast routes.";

     container ipv4-unicast {
        uses route-content;
     }
   }

   augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/"
         + "rt:routes/rt:route" {
     when "../../rt:address-family='ipV6' and "
        + "../../rt:safi='nlri-unicast'" {
       description
         "This augment is valid only for IPv6 unicast.";
     }
     description
       "This augment defines the content of IPv6 unicast routes.";
     container ipv6-unicast {
       uses route-content;
     }
   }
}

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 01 Mar 2012 08:59:06 +0100

> RFC 6020 may not be clear on this.  Martin should fix it ;-)

I did check the spec before writing that statement, and it doesn't seem to exclude this case.
The use case is clear: partition the list of logical interfaces into sublists and make sure the sublists are disjoint.

> that belong to the same tuple, for comparison to another tuple.

I think it is a matter of definition, and IMO a reasonable definition is in RFC 6110, sec. 12.16. Of course, I could change the 'unique' statement into 'must' along these lines but that would be much less readable.

> have duplicate local-names in different namespaces.

I don't see it as a problem. We have next-hop for both IPv4 and for IPv6, named v4ur:next-hop and v6ur:next-hop. Moreover, the augments are conditional so that these two can never become siblings - in fact, they cannot be in the same routing table.

> collisions -- to be as XML namespace dependent as possible.

For me namespaces is one of the few reasons for using XML rather than, e.g., JSON.

> The user-friendly thing to do would be to always add your own sub-container.

With subcontainers you cannot use leafrefs effectively. That's why we have a flat list of interfaces.

> (note container insertion before 'uses route-content')

Each 'routing-table' already has 'address-family' and 'safi' as its children, so it makes little sense to carry the redundant address family information in each route:

<rt:routing-table>
  <rt:address-family>ipV6</rt:address-family>
  <rt:safi>nlri-unicast</rt:safi>
  <rt:routes>
    <rt:route>
      <v6ur:ipv6-unicast>
        ... 
      </v6ur:ipv6-unicast>
    </rt:route>
    ...
  </rt:routes>
  ...
<rt:routing-table>

With 250K routes this can already make a difference.

Lada

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

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