Subject: [netmod] js review of draft-lhotka-netmod-routing-cfg-00

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2011 10:44:03 +0200

Hi,

here are some comments on draft-lhotka-netmod-routing-cfg-00:

a) I suggest that the introduction talks less about the charter of
   NETMOD - charters change and what matters is the purpose of the
   module, not how it was created.

b) p6: s/initial design/design/

c) You require that "every compliant implementation MUST support IPv4
   unicast routing and implement at least one (main) routing table".
   Isn't it the job of the IPv4/IPv6 node requirements document to say
   what nodes are expected to support? If my box is a router for a v6
   only network, why should I be required by the YANG data model to
   support IPv4 routing? Perhaps better would be to state that a box
   supporting IPv4 forwarding (i.e a router) MUST support IPv4 unicast
   routing and implement at least one (main) routing table and perhaps
   for the IPv6 case. If we follow this path, we might want to also
   define a feature ipv4-routing.

d) You define address family identities. This raises the question
   whether this is the proper place to do this, whether this needs to
   be extensible (ie under IANA control), how this relates to the
   AddressFamilyNumbers TC in the IANA-ADDRESS-FAMILY-NUMBERS-MIB.

e) Should there be a get-route RPC, giving me the route used for a
   given destination address?

f) You often have an id leaf of type string paired with a description
   leaf of type string. It is not totally clear to me how these are
   going to be used and whether they are both needed.

g) I prefer to have an explicit identity defined for a blocking filter
   instead of overloading the base route-filter with these semantics.
   Perhaps we also need an identify for a filter that just passes
   everything.

h) Should the routing-table have a key name?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 29 Mar 2011 14:00:10 +0200

>   module, not how it was created.

OK.

> b) p6: s/initial design/design/

OK.

>   define a feature ipv4-routing.

You are right, I just wanted to make it really easy for common setups to use just this module. But I am fine with changing it.

>   AddressFamilyNumbers TC in the IANA-ADDRESS-FAMILY-NUMBERS-MIB.

OK, so only "address-family" identity can be defined here, but I think it should remain implemented as identities, so the relation to af-numbers should be only through the names.

>   given destination address?

Yes, there may be more admin operations, we should get some idea from existing router implementations.

>   going to be used and whether they are both needed.

The "id" leaf is used as the mandatory key, but one that is not expected to be used in leafrefs. Lists whose entries will be referenced have the key named "name". Maybe this should be stated in the draft - or do you have an idea of an alternative implementation?
 
>   Perhaps we also need an identify for a filter that just passes

OK, no problem.

> h) Should the routing-table have a key name?

Yes, that's also my question: does it make sense to, e.g. enforce the name of each address family default table?

Lada

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

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C