Subject: [netmod] comments on draft-ietf-netmod-routing-cfg-01

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Nov 2011 13:50:17 +0100 (CET)

Hi,

Here are my comments on draft-ietf-netmod-routing-cfg-01:

I think this document has improved a lot over -00, with the new
structure in ietf-routing.

o  Table 1.

  Remove "eth" from this table; it isn't used.

  I was going to say that you should remove "rip", since it is a bit
  confusing with having an example module listed in this table.  But
  it is actually used.

  Maybe it would be more clear to rmeove this table, and show the
  proper imports / xmlns declarations in the examples that need them.
  This way each example would be more self-contained.  (I think there
  is actually just one example where this applies).

o  Section 4:

   As can be see from Figure 1, the core routing data model introduces
   several generic components of a routing framework: routers, routing
   tables containing routes, routing protocols, route filters and RPC
   operations.

  I cannot see any RPC operations in figure 1.

o  Section 4:

  OLD:

    Each routing protocol instance, including the "static" and
    "direct" pseudo-protocols

  NEW:

    Each routing protocol instance, including instances of the
    "static" and "direct" pseudo-protocols

  In the same sentence, add forward reference to where the "static"
  and "direct" pseudo-protocols are defined. 

o  Section 4:

   o  Along with the main routing table, which must always be present,
      an additional routing table is configured.

  Add forward refrence to where the main routing table is defined. 

o  Section 4.1

  s/it it not/it is not/

o  Secion 4.2

  The way the module is currently written, you should:   s/IP/IPv4/

  But doesn't it make sense to keep the text and change the module?
  I.e., let a route have a (generic) ip-address and ip-prefix.

o  Section 4.3

  OLD:

   Routing tables are lists of routes complemented with administrative
   data, namely:

  NEW:

   Routing tables are lists of routes complemented with administrative
   data for each route, namely:

o  Section 4.3

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

  Add a forward reference to where the "static" pseudo-protocol is
  explained.

o  Section 4.3

   At least the following two routing tables MUST be configured for each
   router instance:

  How is this MUST enforced?  How does am operator know which routing
  table is the fib?

  Maybe change the routing table to a type union of the two
  enumerations "fib" and "main", and a string?

o  Section 4.3

   2.  Main routing table to which all routing protocol instances are
       connected by default.

  What does "connected by default" really mean?  There is nothing in
  the data model about this.

o  Section 4.3

   The naming scheme for routing tables, as well as restrictions on the
   number and configurability of routing tables are implementation-
   specific.

  Could you elaborate a bit on the naming scheme and "configurability"
  part?  Maybe you mean that a routing table name SHOULD be
  arbitrary, but an implementation MAY impose some restriction on the
  name?

o  Section 4.5

   The default value for route filter type
   is the identity "deny-all-route-filter" defined in the "ietf-routing"
   module, which represents a route filtering policy in which all routes
   are rejected.
  
  Why is this necessary?  Is it common to define filters w/o any type
  and let that mean the deny-all type?  I suggest you remove this
  default, and make the type mandatory instead.

o  grouping afn-safi

       leaf address-family {
         type ianaaf:address-family;
         default "ipV4";
         ...
       }

       leaf safi {
         type ianaaf:subsequent-address-family;
         default "nlri-unicast";
         ...
       }

  Should we really have these as defaults?  Isn't it more clear to
  make these mandatory instead?

o  grouping route-content

       leaf source-protocol {
         type string;
         description
           "The name of the routing protocol instance from which the
            route comes. This routing protocol must be configured
            (automatically or manually) in the device.";
       }

  What does "configured automatically" mean?  Automatically by whom?

o  rpc get-route

         container destination-address {
           uses afn-safi;
           description
             "Second parameter: destination address.

              AFN/SAFI-specific modules must augment this container with
              a leaf named 'address'.
             ";
         }

  Why is it important that AFN/SAFI modules choose the name "address"?
  I suggest something like:

              AFN/SAFI-specific modules must augment this container with
              address-specific parameters.

o  list router

  Here you use the term "(logical) router".  In 4.1. you say
  "(virtual) router".  You may want to use the same term, and define
  it once.

o  container connected-routing-tables

               list connected-routing-table {
                 key "name";
                 description
                   "List of routing tables to which the routing protocol
                    instance is connected. No more than one routing
                    table may be configured for each AFN/SAFI pair.

    What does the last sentence mean?

                    Implementation may provide default routing tables
                    for some AFN/SAFI pairs, which are used if the
                    corresponding entry is not configured.

    I do not understand the last sentence.  How does an implementation
    provide these default routing tables?  Where is the "corresponding
    entry"?

o  Why don't we have a ipv6-unicast module?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Nov 2011 00:14:24 +0800

Hi Martin,

thanks for the review. See inline.

>  Remove "eth" from this table; it isn't used.

OK

>  is actually just one example where this applies).

I think this is done in the examples, or do you mean something else?
On the other hand, I believe it is useful to have all prefixes that are used anywhere in the draft listed in one place.

>  I cannot see any RPC operations in figure 1.

Oh yes, I first had the full output of "pyang -f tree" there but then I thought the "rpcs:" part was confusing and deleted it. I will probably use two figures, one with the main data tree and another with the RPC tree.
 
>  and "direct" pseudo-protocols are defined. 

OK

>  Add forward refrence to where the main routing table is defined. 

OK

>  s/it it not/it is not/

OK

>  The way the module is currently written, you should:   s/IP/IPv4/

Right, although the same will have to be done for IPv6 and potentially other address families. I'd like to have it generic but I don't think it is possible in YANG (see also my next comment).

>  I.e., let a route have a (generic) ip-address and ip-prefix.

The problem is that ip-address and ip-prefix only support IPv4 and IPv6, but this should support other address families as well.

>   data for each route, namely:

OK

>  Add a forward reference to where the "static" pseudo-protocol is

OK

>  enumerations "fib" and "main", and a string?

It is similar to RFC 4861: We need a conceptual model of the host, i.e. conceptual objects that behave like "fib" and "main", but we needn't enforce any naming scheme.

>  the data model about this.

Yes, it is exactly because the data model cannot pre-populate the list of routing tables with the entry for "main", which is however required to be present. An implementation just has to use the main routing table if the protocol instance doesn't say otherwise.

>  arbitrary, but an implementation MAY impose some restriction on the

Implementation A may call its main routing table "main.v4" while implementation B calls it "inet.0". Also, some implementations may not allow the user to configure additional tables.

>  default, and make the type mandatory instead.

It is not necessary, but at least you get two extreme filtering options at this stage, without having any real route-filtering framework: either you don't define any route filter, which means "permit all", or you define one, which means "reject all".
 
>  make these mandatory instead?

Yes, it is probably "politically incorrect", but in practical terms this default still makes sense for most users.

>  What does "configured automatically" mean?  Automatically by whom?

Instances of "static" and "direct" protocols must be pre-configured in each router instance. So "automatically" means "configured-by-system".
 
>              address-specific parameters.

I'd prefer that an address be always called "address", be it IPv4, IPv6 or whatever, in order to achieve some kind of poor man's object-orientedness. For example, some leafrefs may then refer to this "address" independently of the address family.

>  "(virtual) router".  You may want to use the same term, and define

OK

>                    table may be configured for each AFN/SAFI pair.

Joel's objection to the previous version was that one instance of a protocol such as BGP may carry routes for multiple address families. So the idea here is that, e.g., IPv4 routes go to routing table "inet.0" and IPv6 routes to "inet6.0".
  
>    provide these default routing tables?  Where is the "corresponding

The sentence should be deleted. The "main" routing table must be configured for each supported AFN/SAFI combination and this is the routing table to which the routing protocol instance is connected by default, i.e., unless "connected-routing-table" is present.

I also have to clarify this in Sec. 4.3:

OLD

At least the following two routing tables MUST be configured for each router instance:

NEW

At least the following two routing tables MUST be configured for each AFN/SAFI combination supported by the router instance: 

(Because previously each router instance was limited to one AFN/SAFI).

> o  Why don't we have a ipv6-unicast module?

Because it will be more complicated than ipv4-unicast and I thought it would be better to leave this task to the 6man WG.

However, it the light of the discussion in the other thread, we should probably reconsider the overall organization of the IP-related data and define an appropriate scope for our WG.

Lada

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

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Nov 2011 18:59:39 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Right, although the same will have to be done for IPv6 and potentially other
> address families. I'd like to have it generic but I don't think it is possible
> in YANG (see also my next comment).

I think you can have generic ip, and then let other address families
augment with their stuff.

> It is similar to RFC 4861: We need a conceptual model of the host,
> i.e. conceptual objects that behave like "fib" and "main", but we needn't
> enforce any naming scheme.

Then this needs to be explained.  And how does an operator know which
one is the fib that is REQUIRED?

> Yes, it is exactly because the data model cannot pre-populate the list of
> routing tables with the entry for "main", which is however required to be
> present. An implementation just has to use the main routing table if the
> protocol instance doesn't say otherwise.

I think this needs to be clarified.

> Implementation A may call its main routing table "main.v4" while
> implementation B calls it "inet.0". Also, some implementations may not allow
> the user to configure additional tables.

Ok.  This should be clarified.  Will this work, from an
interoperability pow?

> It is not necessary, but at least you get two extreme filtering options at
> this stage, without having any real route-filtering framework: either you
> don't define any route filter, which means "permit all", or you define one,
> which means "reject all".

But is the latter so common that it is worth it to have a default
value with this function?

> Yes, it is probably "politically incorrect", but in practical terms this
> default still makes sense for most users.

Defaults are good so that users don't have to configure common values
every time.  Is this really such a case?

> Instances of "static" and "direct" protocols must be pre-configured in each
> router instance. So "automatically" means "configured-by-system".

This should be clarified in the description for a router.

> Joel's objection to the previous version was that one instance of a protocol
> such as BGP may carry routes for multiple address families. So the idea here
> is that, e.g., IPv4 routes go to routing table "inet.0" and IPv6 routes to
> "inet6.0".

Ok. I did not understand that you meant the table that this instance
refers to.  There MUST NOT be two connected tables with the same
"address-family" and "safi" values.  Or something.

> Because it will be more complicated than ipv4-unicast and I thought it would
> be better to leave this task to the 6man WG.
> 
> However, it the light of the discussion in the other thread, we should
> probably reconsider the overall organization of the IP-related data and define
> an appropriate scope for our WG.

Ok.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Nov 2011 09:49:42 +0800

> augment with their stuff.

It's possible. I wanted to have it symmetric - one "address" node (in the corresponding
namespace) per AFN/SAFI.

> one is the fib that is REQUIRED?

As it is done now: you have to find this info in the manual of every router OS.

One way how to make this more explicit would be to define "fib" and "main" as separate containers and then have a list of "extra-routing-tables". But this would break leafrefs that are intended to point to *any* routing table because leafrefs in YANG cannot specify alternative paths (which is IMO unfortunate).

OK

> Ok.  This should be clarified.  Will this work, from an

It depends on what you mean by interoperability. A configuration that works on one platform may not work on another - but I think we can't avoid this anyway. Perhaps we can introduce a feature for this, e.g. "user-defined-routing-tables."

> value with this function?

Since the other extreme - "permit all" - is already available, I think is is useful to provide the "deny all" behavior. And yes, I think it is quite common - it is actually used in the example in appendix A.2. 

> every time.  Is this really such a case?

I think so.

OK

> "address-family" and "safi" values.  Or something.

OK, I will try to make it more clear.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 29 Nov 2011 14:27:40 +0100

Hi,

> o  Why don't we have a ipv6-unicast module?

I'd like to write the "ietf-ipv6-unicast-routing" module but first we
need to agree on the distribution of IPv6 parameters between this module
and "ietf-ip".

In the next revision of the "ietf-routing" module, I plan to add a list
of interfaces under /rt:routing/rt:router with key being a leafref
pointing to a configured logical interface. This is necessary in order to
be able to specify the logical interfaces that belong to each logical
router. As a side effect, interface parameters that are only relevant
for routers, such as RA configuration, can be put here rather than under
/if:interfaces. 

Any opinions or suggestions?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C