Subject: [netmod] review of draft-ietf-netmod-routing-cfg-02

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Mar 2012 08:40:30 +0200 (CEST)

Hi,

Here are my comments on draft-ietf-netmod-routing-cfg-02.

o  4.1

     Each router instance in the core routing data model represents a
     (logical) router whose configuration and operation is independent
     of other router instances.

   Why do we need this extra list (/routing/router)?  Can you
   examplify when more than one list entry would be used?

o  4.1

     Logical network interfaces must be assigned to a router instance

  What is a "Logical network interface"?
  draft-ietf-netmod-interfaces-cfg does not use this term.

o  4.2

  s/destination-prefix/dest-prefix/

  OR the other way around in the data model.

o  4.3

  You say that at least two routing tables MUST be present.

  Can we change the name of a routing table to be:

     type union {
       type enumeration {
         enum fib;
         enum main;
       }
       type string;
     }

  This makes it clear which table is the fib and which is main.

  Also, on my linux box, I can see the FIB, but what about main?  Is
  it always present?

o  4.4

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

  Where is this "exactly one" property in the data model?
  "connected-routing-tables" has a list, so its seems a routing
  protocol can be connected to 0 or more tables?

o  4.4

     By default, every routing protocol instance SHOULD be connected
     to the main routing table.

  I do not understand this sentence.  What does it mean in terms of
  the configuration?

o  4.4

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

  What does this mean?

o  4.4.1

    s/It is recommended/It is RECOMMENDED/

o       leaf cur-hop-limit {
           type uint8;
           default "64";

  Is this default really correct?  It doesn't match the text:

              The default should be set to the value specified in IANA
              Assigned Numbers that was in effect at the time of
              implementation.

  I suggest you remove the default statement, and change the text to
  something like

              If not explicitly configured, the value to be used in
              the Cur Hop Limit field should be the value specified in IANA
              Assigned Numbers that was in effect at the time of
              implementation.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 29 Mar 2012 07:34:38 -0400

>   examplify when more than one list entry would be used?

LRs are independent of each other, but must exist in the
configuration of the full device.

>  OR the other way around in the data model.

Other way please.  Full words are so much easy to standardize on.

>  Also, on my linux box, I can see the FIB, but what about main?  Is

No.  The FIB can be built from a set of routing tables that
are protocol-specific (inet, inet6, etc) where no specific
one can be called "main" (without upsetting the v6 folks ;^).

If you keep it, "rib" might be a better name than "main".

Also there is a lot of information in the other routing tables
that isn't needed in the FIB.

>    "direct" pseudo-protocol.

I think this means routers without real interfaces are not
interesting.  And while that may be true, interfaces can
appear and disappear (hot plug), so saying that I MUST
have one is not good.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Mar 2012 14:11:59 +0200 (CEST)

> configuration of the full device.

I guess my concern is if this concept is similiar enough in different
vendors' routers that it make sense to standardize it like this.  A
device that do not support multiple LRs is still required to have this
extra layer.

Also, if this data model has this extra list on the top, do we need to
do the same in other data models?

> appear and disappear (hot plug), so saying that I MUST

Ok.

I meant what does this "MUST" mean for an implementation?  

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 29 Mar 2012 09:07:10 -0400

>device that do not support multiple LRs is still required to have this

We put LRs in a distinct container, since the base device
has functionality outside the LR.  You should not few the
base device as a "special" LR.

>I meant what does this "MUST" mean for an implementation?  

IMHO it should be removed.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Mar 2012 15:10:24 +0200 (CEST)

> base device as a "special" LR.

So do you think the same should be done here?

  /routing/<base-stuff>
          /logical-router/<subset-of base-stuff>

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 29 Mar 2012 10:21:09 -0400

>          /logical-router/<subset-of base-stuff>

Yup, that's what I'd suggest.

We actually use the term "logical systems" because they
can do much more that just routing (L2, firewall, etc).
We also have "routing-instances" which are multiple
protocol instances running inside a system or logical
system:

/protocols/bgp
/routing-instances/protocols/bgp
/logical-systems/routing-instances/protocols/bgp

Add in the config groups hierarchy and some wildcard matches
and you've got a party, dude ;^)

Thanks,
 Phil

http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/routing-instances-configuration-guidelines.html
http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/overview_1.html#id-10523666

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 29 Mar 2012 18:35:25 +0200

Hi Martin,

thanks for the review.

>    examplify when more than one list entry would be used?

I will react separately to this, also taking into account Phil's comments.

>   draft-ietf-netmod-interfaces-cfg does not use this term.

OK, I will change it to "network layer interface".

>   OR the other way around in the data model.

I will use "destination-prefix" everywhere.

>   This makes it clear which table is the fib and which is main.

Unfortunately, this cannot be done because the pair of routing tables must be available for each supported address family - see sec. 4.3.

>   Also, on my linux box, I can see the FIB, but what about main?  Is

I assume that at least one routing table except FIB must be present because FIB only contains active routes. Otherwise there is nothing magical on the main table.

The output of "ip route" on Linux is in fact a view of the main routing table because it can contain multiple routes for the same destination, e.g. with different metrics.  
 
>   protocol can be connected to 0 or more tables?

Yup, I have to correct this in the text. A routing protocol may work with multiple address families, so it is connected to one table for each address family. This is enforced by the 'must' statement under "connected-routing-tables". 

>   I do not understand this sentence.  What does it mean in terms of

I have to add "... for each address family supported by the protocol." In terms of configuration it means that a protocol that is IPv4-only should have the list preconfigured as follows:

<connected-routing-tables>
  <routing-table>
    <name>main-ipV4-unicast</name>
  </routing-table>
</connected-routing-tables>

As it is not possible to define default list contents in the data model, I have to assume that this is somehow factory-configured but can be changed.

The "SHOULD" means that an implementation may do it differently if necessary. 
   
>     "direct" pseudo-protocol.

This means that the "direct" protocol must be present, and only in one instance, in order to supply a direct route for each interface assigned to the router. It doesn't mean though that "direct" must appear in the configuration.
 
>     s/It is recommended/It is RECOMMENDED/

OK.

>               Assigned Numbers that was in effect at the time of

IANA document

http://www.iana.org/assignments/ip-parameters

says: "The current recommended default time to live (TTL) for the Internet Protocol (IP) is 64 [RFC791, RFC1122]."

Lada

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 29 Mar 2012 18:40:49 +0200

OK.

> one can be called "main" (without upsetting the v6 folks ;^).

Yes, a router implementing this module can do the same.

> If you keep it, "rib" might be a better name than "main".

I am afraid this could start a new terminology discussion.

> that isn't needed in the FIB.

Yup, maybe I should make it more clear that the FIB is different from other routing tables.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 29 Mar 2012 18:54:36 +0200

>           /logical-router/<subset-of base-stuff>

This means that the common stuff would be duplicated, although the duplication can be minimalized through the use of groupings. But also remember that most of the contents will appear here via augments from other modules, which means that the augmenting modules will actually have to define two augments: one for <base-stuff> and another for <subset of base-stuff>.

Another possibility is to introduce a new leaf specifying a router type (at least "base" versus "logical") and the difference of <base stuff> and <subset of base-stuff> would be conditional.

Lada

---

From: "t.petch" <[email-masked]>
Date: Fri, 30 Mar 2012 09:18:16 +0200

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 29, 2012 2:11 PM
> device that do not support multiple LRs is still required to have this

Martin

I was asked in 2002 if I knew of any routers which implemented multiple
instances of BGP.  I kept the e-mail, and for over five years, the answer was
no; and even now, I suspect it remains no for almost all routers, Juniper being
an - the? - exception - as is the case with many things, their routers having
the most capabilities.

Multi-instance OSPF is commoner, as I assume is multi-instance IS-IS, but the
vast mass of routers have a single logical router with a single instance of some
of OSPF, BGP, EIGRP, RIP etc.

The art is to make that simple and clear to configure even when the model allows
for the Junipers of this world.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Fri, 30 Mar 2012 09:26:14 +0200

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Phil Shafer" <[email-masked]>; "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 29, 2012 6:40 PM

Lada

Yes, I was about to say that I do not see the term 'main' in use but I do see
widespread use of RIB in contrast to FIB.  RIB is built into the logic of the
specification of BGP and I see it applied in more general discussions of
routing, even when the protocol has its own terminology, as when, for example,
OSPF uses Link State Data Base.  RIP has a 'RIB', else it could not do split
horizon with poison reverse, but its existence is usually kept secret, not
something I have ever understood.

FIB does sometimes get subdivided as when it gets downloaded to a line card,
with different line cards having different parts of the routing table.

Tom Petch

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 30 Mar 2012 10:32:14 +0200

Allied Telesis switches support multiple instances (or effectively multiple instances) of all the supported unicast routing protocols (in the current version, BGP, OSPF and RIP), in the presence of virtual routers.  See the howto document here: http://alliedtelesis.com.au/userfiles/file/howto_aw-_config_VRF_Lite_RevC.pdf

The model in the draft is similar enough to how the routing works in our switches that it works for us.  It also works for the full generality of the linux kernel's network namespace feature, which is far more complicated than VRF-lite.

I think it's general enough to work for almost any situation, and simple enough not to be unduly confusing.

Andrew

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 30 Mar 2012 11:43:57 +0200

> I think it's general enough to work for almost any situation, and simple enough not to be unduly confusing.

This is encouraging to hear.

I think the answer to the question whether to support multiple logical routers in the routing data model should be a resounding yes. So we just have to decide what is the best way to do it. In my opinion, the existing schema is satisfactory and certainly not limited to a JUNOS-like configuration of logical routers. The flip side is that there is an extra container ("router") which has to be used even in cases where there are no logical routers. I consider this drawback to be relatively minor.

Lada

> >> I meant what does this "MUST" mean for an implementation?
Attachment: smime.p7s (application/pkcs7-signature)

---

From: "t.petch" <[email-masked]>
Date: Fri, 30 Mar 2012 11:36:54 +0200

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Andrew McGregor" <[email-masked]>; "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 30, 2012 11:43 AM
> > Allied Telesis switches support multiple instances (or effectively multiple
instances) of all the supported unicast routing protocols (in the current
version, BGP, OSPF and RIP), in the presence of virtual routers.  See the howto
document here:
http://alliedtelesis.com.au/userfiles/file/howto_aw-_config_VRF_Lite_RevC.pdf
> >
> > The model in the draft is similar enough to how the routing works in our
switches that it works for us.  It also works for the full generality of the
linux kernel's network namespace feature, which is far more complicated than
VRF-lite.
> I think the answer to the question whether to support multiple logical routers
in the routing data model should be a resounding yes. So we just have to decide
what is the best way to do it. In my opinion, the existing schema is
satisfactory and certainly not limited to a JUNOS-like configuration of logical
routers. The flip side is that there is an extra container ("router") which has
to be used even in cases where there are no logical routers. I consider this
drawback to be relatively minor.

Lada

I agree that that is a minor drawback but the one that Martin raised might be
greater, of what attributes are regarded as part of the box as a whole and what
are part of each logical router.  Does everyone who has logical routers take the
same approach?  Looking at the document that Andrew referenced - good to have
that - some things can be specific to a logical router - IP addresses, OSPF,
Telnet client - while others cannot - SNMP, NTP, DHCP servers.  I doubt if that
approach would apply to other boxes.

If, as I suspect, it is a top end box feature, then the configuration needs not
to add too much complexity to the generic case.

Tom Petch