Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-02

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 Mar 2012 14:34:57 +0200

Hi Yi,

thank you very much for the review and helpful comments, please see my replies below.

Best regards, Lada

* Section 4. The Design of the Core Routing Data Model
   +--rw routing
      +--rw router [name]

YY> Unlike the interface name or routing-protocol name, the router
YY> name is not just a local significant variable. How to guarantee
YY> the router name is unique within a domain?

LL> If you mean a router ID, I expect it will be defined elsewhere.
LL> Some implementations define a global router ID but mostly it is
LL> done per protocol. One option would be to define it here and allow
LL> routing protocols to override it.

         +--rw name
         +--rw description?
         +--rw enabled?
         +--rw interfaces
         |  +--rw interface [name]
         |     +--rw name

YY> Interface names are only configurable for virtual interfaces such
YY> as tunnel interface, loopback interfaces and etc., but not
YY> configurable for physical interfaces. So it would be a mix of rw
YY> and ro?

LL> The "name" leaf serves two purposes: (i) it is a list key, which
LL> is required by YANG and (ii) reference to a logical interface
LL> defined in the "/if:interfaces" subtree. There, the name may or
LL> may not be configurable.

         |     +--rw v6ur:ipv6-router-advertisements
         |        +--rw v6ur:send-advertisements?
         |        +--rw v6ur:max-rtr-adv-interval?
         |        +--rw v6ur:min-rtr-adv-interval?
         |        +--rw v6ur:managed-flag?
         |        +--rw v6ur:other-config-flag?
         |        +--rw v6ur:link-mtu?
         |        +--rw v6ur:reachable-time?
         |        +--rw v6ur:retrans-timer?
         |        +--rw v6ur:cur-hop-limit?
         |        +--rw v6ur:default-lifetime?
         |        +--rw v6ur:prefix-list
         |           +--rw v6ur:prefix [seqno]
         |              +--rw v6ur:seqno
         |              +--rw v6ur:prefix-spec?

YY> This should be mandatory — If a prefix is not specified, it will
YY> not be advertised.

LL> OK, I will change it to "mandatory".

         |              +--rw v6ur:valid-lifetime?
         |              +--rw v6ur:on-link-flag?
         |              +--rw v6ur:preferred-lifetime?
         |              +--rw v6ur:autonomous-flag?
         +--rw routing-protocols
         |  +--rw routing-protocol [name]
         |     +--rw name
         |     +--rw description?
         |     +--rw type
         |     +--rw connected-routing-tables
         |     |  +--rw routing-table [name]
         |     |     +--rw name

YY> The routing-table name of the main table and FIB should not be
YY> configurable.

LL> Yes, I expect every implementation will have the names of these
LL> two routing tables predefined and fixed. This is explained in sec.
LL> 4.3, last-but-one paragraph. Each vendor seems to have a favorite
LL> naming scheme, so I didn't want to fix the names in the data
LL> model. It's pretty much the same as with interface names.

         |     |     +--rw import-filter?
         |     |     +--rw export-filter?
         |     +--rw static-routes
         |        +--rw v4ur:ipv4
         |        |  +--rw v4ur:route [seqno]
         |        |     +--rw v4ur:seqno
         |        |     +--rw v4ur:description?
         |        |     +--rw v4ur:outgoing-interface?
         |        |     +--rw v4ur:dest-prefix?

YY> This should be mandatory for route.

LL> This leaf appears here via augmentation from the
LL> "ietf-ipv4-unicast-routing" module, and it is a YANG rule that
LL> such a data node must not be mandatory. The same holds for
LL> "v6ur:dest-prefix" below.

         |        |     +--rw v4ur:next-hop?
         |        +--rw v6ur:ipv6
         |           +--rw v6ur:route [seqno]
         |              +--rw v6ur:seqno
         |              +--rw v6ur:description?
         |              +--rw v6ur:outgoing-interface?
         |              +--rw v6ur:dest-prefix?
         |              +--rw v6ur:next-hop?
         +--rw route-filters
         |  +--rw route-filter [name]
         |     +--rw name
         |     +--rw description?
         |     +--rw type?
         +--rw routing-tables
            +--rw routing-table [name]
               +--rw name
               +--rw address-family?
               +--rw safi?
               +--rw description?
               +--ro routes

YY> When new afi-safi are supported, do we expect this list to be
YY> extended as well? How about to define base types for
YY> outgoing-interfaces, dest-prefix and next-hop and use them here
YY> instead?

LL> Yes, this list would be augmented with stuff specific to the new
LL> AFN/SAFI. I am not sure what you exactly mean by "base type" but
LL> YANG is not object-oriented.

               |  +--ro route
               |     +--ro source-protocol?
               |     +--ro last-modified?
               |     +--ro v4ur:outgoing-interface?
               |     +--ro v4ur:dest-prefix?
               |     +--ro v4ur:next-hop?
               |     +--ro v6ur:outgoing-interface?
               |     +--ro v6ur:dest-prefix?
               |     +--ro v6ur:next-hop?
               +--rw recipient-routing-tables [recipient-name]
                  +--rw recipient-name
                  +--rw filter?

    +--------+             +------------+
    | direct |    +---+    |            |
    | routes |--->| F |--->|    FIB     |
    +--------+    +---+    |            |
                           +------------+

YY> Why the “direct routes” are not connected with main RT? If direct
YY> routes are connected with FIB, we should not expect to see these
YY> routes in the main table, which contradicts the current practice.

LL> It was so in the previous revision of the draft. I changed it to
LL> allow for direct routes *not* appearing in the main routing table.
LL> If necessary, "main" can be configured as a recipient of direct
LL> routes from FIB. Or do you see a strong reason to change it back?

** Section 4.3. Routing Tables

   This also includes manipulations via the "static" pseudo-protocol.

YY> This also includes manipulations via the "static" and/or "direct"
YY> pseudo-protocols.

LL> OK.

** Section 4.4. Routing Protocols

   Each routing protocol instance is connected to exactly one routing
   table.

YY> Each routing protocol instance is connected to exactly one routing
YY> table for each AFN/SAFI.

LL> OK.

   Routes learned from the network by a routing protocol are passed to
   the connected routing table and vice versa - routes appearing in a
   routing table are passed to all routing protocols connected to the
   table (except "direct" and "static" pseudo-protocols) and advertised
   by that protocol to the network.

YY> This is not true. For example, routes learned from BGP will not be
YY> passed to OSPF. They can but are not by default.

LL> As the next paragraph states, this exchange may be subject to a
LL> route filter. It is up to the data models for routing protocols to
LL> define such "business rules" and implementations will have to
LL> follow them. The core routing data model only provides a
LL> framework, there are (almost) no policies.

   Every router instance MUST contain exactly one instance of the
   "direct" pseudo-protocol.

YY> It’s possible to run one “direct” protocol instance per AFI/SAFI
YY> instead.

LL> I assume that the single "direct" instance generates the routes
LL> for all address families, analogically to "static".

*** Section 4.4.1. Defining New Routing Protocols

   o  Other configuration parameters can be defined by augmenting the
      "routing-protocol" data node.  By using the "when" statement, this
      augment SHOULD be made conditional and valid only if the value of
      the "rt:type" child leaf equals to the new protocol's identity.

YY> Other operational state data can be defined by augmenting the
YY> "routing-protocol" data node. By using the "when" statement, this
YY> augment SHOULD be made conditional and valid only if the value of
YY> the "rt:type" child leaf equals to the new protocol's identity.
YY> (Examples of such operational state data are ospf link state
YY> database, bgp database….)

LL> OK, I will change it to "Other configuration parameters and/or
LL> operational state data can be defined ...".

* Section 5. IANA AFN and SAFI YANG Module

         enum afi {
           value "25";
           description
             "AFI for L2VPN";
         }

YY> enum l2vpn { ... }

LL> I used the "enum" labels from IANA-ADDRESS-FAMILY-NUMBERS-MIB. Of
LL> course, this one seems really weird but I am not sure whether it
LL> is a good idea to change it.

YY> Add the following entry to "typedef subsequent-address-family":
YY>
YY>      enum encapsulation {
YY>        value "7";
YY>        description
YY>          "Encapsulation SAFI";
YY>        reference
YY>          "RFC5512";
YY>      }

LL> OK, I have to update the typedef to reflect the most recent IANA
LL> data.

* Section 6. Routing YANG Module

YY> Add the following identity to the "ietf-routing" module:
YY>
YY>     identity allow-all-route-filter {
YY>       base route-filter;
YY>       description
YY>         "Route filter that allows all routes.";
YY>     }
YY>
YY> Based on section 4.5, this filter should be provided in the doc as
YY> well.

LL> This "allow-all" filter is equivalent to no filter at all. But
LL> maybe, for the sake of symmetricity, it should be available as an
LL> explicit filter.

* Section 7. IPv4 Unicast Routing Module

     augment "/rt:routing/rt:router/rt:routing-protocols/"
           + "rt:routing-protocol/rt:static-routes" {
       description
         "This augment defines the configuration of the 'static'
          pseudo-protocol with data specific for IPv4 unicast.";
       container ipv4 {
         description
           "Configuration of a 'static' pseudo-protocol instance
            consists of a list of routes.";
         list route {
           key "seqno";
           ordered-by "user";
           description
             "A user-ordered list of static routes.";
           leaf seqno {
             type uint16;
             description
               "Sequential number of the route.";
           }

YY> big enough?

LL> Hmm, I thought it was enough, unless someone wants to copy the
LL> full BGP table and paste it as static routes. But I can change it
LL> to uint32, in order to allow for such pathological (but possible)
LL> cases.

On Thu, 22 Mar 2012 14:59:35 -0400, Yi Yang <[email-masked]> wrote:
> Hi Folks,
> 
> Please see the attached for my comments. -- I put it into MS word to track the changes/comments.
> 
> Regards,
> 
> Yi
> 

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 26 Mar 2012 17:04:04 +0200 (CEST)

> LL> This leaf appears here via augmentation from the

What does "This leaf" refer to?

> LL> "v6ur:dest-prefix" below.

v6ur:dest-prefix can be mandatory since it is within a list.  The node
added by the augement is "v6ur:ipv6", which is not mandatory (per 3.1
of 6020).

>          |              +--rw v6ur:dest-prefix?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 Mar 2012 17:17:08 +0200

> What does "This leaf" refer to?

v4ur:dest-prefix

> added by the augement is "v6ur:ipv6", which is not mandatory (per 3.1

You are right, I'll make both v4ur:dest-prefix and v6ur:dest-prefix mandatory.

Lada