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

From: t.petch <[email-masked]>
Date: Thu, 2 Aug 2012 15:00:54 +0100

----- Original Message -----
From: "Yi Yang (yiya)" <[email-masked]>
To: "Ladislav Lhotka" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 31, 2012 3:29 PM
Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04

Hi Ladislav,

>>>> I am not an expert on Junos, but here is the output of "show route
forwarding-table", from
http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command
-summary/show-route-forwarding-table-mpls-ex-series.html
>>>>
>>>> user@switch> show route forwarding-table
>>>> Routing table: default.inet
>>>> Internet:
>>>> Destination        Type RtRef Next hop           Type Index NhRef
Netif
>>>> default            user     2 0:12:f2:21:cf:0    ucst   333     5
me0.0
>>>> default            perm     0                    rjct    36     2
>>>> 0.0.0.0/32         perm     0                    dscd    34     1
>>>> 2.2.2.0/24         intf     0                    rslv  1309     1
ae0.0
>>>> .......
>>>>
>>>> Compared to the output of "show route", from
>>>>
http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command
-summary/show-route.html
>>>>
>>>> user@host> show route
>>>> inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden)
>>>> + = Active Route, - = Last Active, * = Both
>>>> 0.0.0.0/0          *[Static/5] 1w5d 20:30:29
>>>>                    Discard
>>>> 10.255.245.51/32   *[Direct/0] 2w4d 13:11:14
>>>>> via lo0.0
>>>> 172.16.0.0/12      *[Static/5] 2w4d 13:11:14
>>>>> to 192.168.167.254 via fxp0.0
>>>> 192.168.0.0/18     *[Static/5] 1w5d 20:30:29
>>>>> to 192.168.167.254 via fxp0.0
>>>>
>>>> As mentioned earlier, source/age are not shown in the forwarding
table, unless they are hidden intentionally? Maybe someone familiar with
Junos can comment on this?
>>>
>>> Would it help if "age" and "source-protocol" were not mandatory?
>>
>> I am inclined to separate forwarding table from routing table. The
forwarding table is so special that it has a different data structure,
doesn't interact with routing protocol directly, and doesn't support
export filters…
>
> This is certainly an option - somebody can write such an extension as
a separate module. But, as I said, some implementations do not use a
forwarding table.

Or, forwarding table as an optional?

IMO, no matter if forwarding table is specified in a separate module, or
specified as an optional node, the reference of forwarding table and FIB
in the draft should be clarified as they are not routing tables.

<tp>
In a sense I agree with you, in a sense I think the exact opposite.

This topic of what tables there are in a box that routes packets has
surfaced before.  I see, in a typical I-D produced about routing,
reference to FIB and RIB, without any need to define or explain the
terms, they are that well known, they are what routers and other boxes
have as a matter or course.

For me, it is the FIB that is always present; if you do not know where
to send a packet, how to route it, then you are not an IP box of any
shape or form - you must have a FIB..  In simple boxes, like Linux or
Windows, then that is all you have.

In more sophisticated boxes, 'proper' routers, for some meaning of the
word proper, then you need much more data, which may closely model the
FIB, as with RIP, or may be utterly different, as with OSPF, and for
this, I see the term RIB used, initially with BGP but latterly with any
routing protocol.  RIBs vary widely with the routing protocol and so are
properly part of routing protocol extensions.

So I think that this I-D gets the terminology quite wrong; as I say,
this has surfaced before without any visible change to the I-D.  I was
surprised that this topic attracted no comment from the Routing
Directorate.

Tom Petch
</tp>
Yi

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 02 Aug 2012 16:10:42 -0700

> have as a matter or course.

Yes, it's been my problem that I couldn't find a precise definition of these acronyms, and I understand most routing experts use the definition "you know it when you see it".

> properly part of routing protocol extensions.

So at the level of the present core routing model we are dealing with FIBs, but as soon as a BGP module augments routes with that sophisticated stuff a FIB gets promoted to a RIB, right? But this may be quite confusing from the point of view of the I-D text, and in this case I would probably prefer to avoid these acronyms entirely and use only "routing table".

> surprised that this topic attracted no comment from the Routing

Can you suggest what to do in order to get the terminology right?

Anyway, I think that Yi Yang's comments were about "forwarding table", i.e. a (simplified) routing table which by definition contains only active routes. 

Thanks, Lada

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

---

From: t.petch <[email-masked]>
Date: Fri, 3 Aug 2012 15:34:05 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>; "Yi Yang (yiya)" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 03, 2012 12:10 AM
> Yes, it's been my problem that I couldn't find a precise definition of
these acronyms, and I understand most routing experts use the definition
"you know it when you see it".
> So at the level of the present core routing model we are dealing with
FIBs, but as soon as a BGP module augments routes with that
sophisticated stuff a FIB gets promoted to a RIB, right? But this may be
quite confusing from the point of view of the I-D text, and in this case
I would probably prefer to avoid these acronyms entirely and use only
"routing table".
> Anyway, I think that Yi Yang's comments were about "forwarding table",
i.e. a (simplified) routing table which by definition contains only
active routes.

I think this a misuse of forwarding table:-(

RIB is defined in RFC1771 (BGP) and later BGP RFC such as RFC2439 (Nov
1998) and RFC4771; it is clearly not the routing table, containing
everything including the kitchen sink and its structure is specific to
BGP.  But I see the term applied generically to what is learnt by an
instance of a routing protocol, and so could be applied to the
equivalent structures of EIGRP or IS-IS, which are very different in
kind.  Sometimes I see it used generically to include everything learnt
by all instances of all routing protocols but I think that that is
wrong.

FIB appears in RFC1812
"The goal of the next-hop selection process is to examine the entries
   in the router's Forwarding Information Base (FIB) and select the best
   route (if there is one) for the packet from those available in the
   FIB."
which is what, in popular parlance, is a routing table.  For example,
Moy, writing on OSPF, says
"A router's routing table instructs the router how to forward  packets.
Given a packet, the router performs a routing table lookup, using the
packet's IP destination address as a key.  This lookup returns the best
matching routing table entry ..."

I would not expect the term FIB to include all the baggage that routing
protocols provide nor for it to include any route which is not
available, as far as the host or router knows, for immediate use.

But the terms FIB and RIB are a bit specialised; I-Ds such as
draft-uttaro-idr-bgp-persistence-01
and
draft-ietf-grow-simple-va-11
use them without any explanation as do posters on many if not most of
the WG lists in Routing and parts of Operations Areas, but that is
probably not appropriate for this I-D, just as the terms are not used
in, eg, RFC2096, which is entitled 'IP Forwarding Table MIB' but then
defines 'IP CIDR Route Table', the DESCRIPTION of which is "This
entity's IP Routing table."; oh dear, you can't win!

So I think that conceptually, you should be defining the FIB, of usable
routes from which the next hop or interface of a packet is selected on
the basis of longest match, but probably calling it a route or routing
table since that is the term most widely used.  Where individual router
manufactuers do clever things on line cards, then that is best modelled
by clever router manufacturers, even if they are all doing something
similar - the speed and rate of change of those data structures probably
makes them unsuitable for MIB, yang or anything else.

You should allow for augmentation, or some such;  BGP revolves around
peers and path attributes (RFC4273) and avoids all mention of FIB, RIB
or the IP Route Table.  OSPF (RFC4750) covers interfaces, neighbors,
areas and link states, and has a reference to the Forwarding Table.
RIP(RFC1724) has interfaces and peers and refers to the  "the IP Route
Database by RIP"

Yup, you can't win, but referring to RFC1812 is unlikely to lose.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 03 Aug 2012 11:45:21 -0700

Hi Tom,

thank you for a detailed explanation. The moral of the story for me is that it is probably better to avoid FIB/RIB and use "routing table" everywhere, although it may look "less sophisticated".

As for the term "forwarding table", it is used in this sense in Junos documentation:

http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/routing-protocols-routing-databases-overview.html

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 13 Aug 2012 11:00:02 +0200

"Yi Yang (yiya)" <[email-masked]> writes:

> Even on the Juniper's webpage, the forwarding table and routing table have different meanings. They are close but different. 
>
> For IOS world, the webpage may help you understand the difference between routing table and forwarding table.
> http://blog.ioshints.info/2010/09/ribs-and-fibs.html

Hmm, these definitions of RIB and FIB are clearly at odds with those advocated by Tom Petch. Oh well ...

Lada

---

From: t.petch <[email-masked]>
Date: Tue, 14 Aug 2012 11:35:19 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Yi Yang (yiya)" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 13, 2012 10:00 AM
> >> thank you for a detailed explanation. The moral of the story for me
is that it is probably better to avoid FIB/RIB and use "routing table"
everywhere, although it may look "less sophisticated".
> >> As for the term "forwarding table", it is used in this sense in
Junos documentation:
http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/routing-p
rotocols-routing-databases-overview.html
> >
> > Even on the Juniper's webpage, the forwarding table and routing
table have different meanings. They are close but different.
> >
> > For IOS world, the webpage may help you understand the difference
between routing table and forwarding table.
> Hmm, these definitions of RIB and FIB are clearly at odds with those
advocated by Tom Petch. Oh well ...

Yes:-(

My definitions come, as you can see, from RFC and from I-Ds I expect to
become RFC, ie they are IETF consensus documents, whereas the references
above are to manufacturer documentation, in support of the sale and
implementation of a particular manufacturer's products.  The
relationship of a manufacturer with standards is complex, typically
adopting them when it helps their business model, ignoring them when it
has the opposite effect.  A WG has to decide which road to go down, but
to use different terminology to the rest of the IETF does require
justification, IMO.  It happens, particularly between the low level, of
IP and Routing, and the high level, Applications, but I do not think it
ever helpful to those who want to use our standards.

In the source referenced above, Juniper says
"The Junos OS maintains two databases for routing information:
Routing table-Contains all the routing information learned by all
routing protocols.
Forwarding table-Contains the routes actually used to forward packets
through the router.
In addition, the interior gateway protocols (IGPs), IS-IS, and OSPF
maintain link-state databases."
which, to someone familiar with routing protocols, looks a little odd.
The OSPF protocol is about link state, used to build the link state
database.  Every so often, the SPF algorithm is used to generate best
routes.  Does this constitute "routing information learned by all
routing protocols"?  Strictly no, so where does it go? Direct into the
Forwarding table if it is better than a RIP route?  I cannot tell from
this.

Likewise, Juniper is unclear where the BGP learnt data goes, what is
widely referred to as a RIB.  That does fit the definition of 'Routing
table' but it is odd that BGP, the most important routing protocol for
the Internet, and its RIB, do not get a mention here.  It is as if the
focus is on an entry level router, linking LAN to WAN, not a high
powered Internet router.

The other web site says
"I'm asked about the difference between Routing Information Base (RIB),
also known as IP Routing Table ..."
but then has a diagram of
BGP table -> BGP process -> IP Routing Table
which is a contradiction of every RFC on BGP that the IETF has ever
produced; the BGP table is the RIB.

And so on and so forth.

Sources like these are fine for Routing 101, especially for a
manufacturer promoting their products, but a Standards body should aim
higher and be precise and consistent in its choice and use of terms.

Tom Petch