DPDK patches and discussions
 help / color / mirror / Atom feed
From: Vladimir Medvedkin <medvedkinv@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC] Add RIB library
Date: Wed, 12 Jul 2017 02:13:08 +0300	[thread overview]
Message-ID: <CANDrEH=uEoBnkvxUoaHQx1-OaNzFxQmbZkXGTyriXjMyPiSvRg@mail.gmail.com> (raw)
In-Reply-To: <20170711133143.77f02240@xeon-e3>

Actually that is vendor specific. For example Juniper takes all route
information from protocol specific tables and compiles it in rib (yes, they
call it rib) so-called inet.0 (for ipv4 default VRF). In general RIB
contains control plane information and is used for control plane purpose
such as fib modification and for example showing route information in CLI.
FIB is used on dataplane only to make forwarding decision.
Actually with this new library you can keep information about all
particular route sources and all protocol specific information. For example
I have in my rib
10.0.0.0/8          *[Static/5] 42w2d 10:58:02
                    > to 10.201.254.1 via ae1.996
                    [Static/5] 35w6d 05:39:47
                      Discard
                    [OSPF/150] 3w0d 07:49:33, metric 15, tag 0
                    > to 1.1.1.1 via ae3.0
                    [BGP/170] 07:17:26, localpref 100, from 1.1.2.1
                      AS path: I, validation-state: unverified
                    > to 1.1.2.2 via ae1.879, label-switched-path M9-OS1
                    [BGP/170] 2w1d 01:13:34, localpref 100, from 1.1.3.1
                      AS path: I, validation-state: unverified
                    > to 1.1.3.2 via ae1.878, label-switched-path M9-OS0
                    [BGP/170] 2w0d 02:54:47, localpref 100, from 1.1.4.1
                      AS path: I, validation-state: unverified
                    > to 1.1.4.2 via ae2.811, label-switched-path M9-KR0

So you have only one struct rte_rib_v4_node for prefix  10.0.0.0/8 that
contains app specific information like
struct my_app_static_ext {
        int admin_dist;
        time_t time;
        uint64_t nh_id;
}

struct my_app_ospf_ext {
        int admin_dist;
        time_t time;
        uint64_t nh_id;
        int metric;
        int type;
}
struct my_app_bgp_ext {
        int admin_dist;
        time_t time;
        uint64_t nh_id
        uint32_t source;
        int med;
        int localpref;
        char * as_path;
        char* community;
}

union my_app_proto_ext {
        struct my_app_static_ext;
        struct my_app_ospf_ext;
        struct my_app_bgp_ext;
}

struct my_app_ext {
        struct my_app_ext *next;
        int type;
        union my_app_proto_ext;
}
 in it's .ext field. In this way you'll keep information about all routes.


2017-07-11 23:31 GMT+03:00 Stephen Hemminger <stephen@networkplumber.org>:

> On Tue, 11 Jul 2017 19:33:04 +0000
> Medvedkin Vladimir <medvedkinv@gmail.com> wrote:
>
> > Hi,
> >
> > I want to introduce new library for ip routing lookup that have some
> advantages
> > over current LPM library. In short:
> >      - Increases the speed of control plane operations against lpm such
> as
> >        adding/deleting routes
> >      - Adds abstraction from dataplane algorythms, so it is possible to
> add
> >        different ip route lookup algorythms such as
> DXR/poptrie/lpc-trie/etc
> >        in addition to current dir24_8
> >      - It is possible to keep user defined application specific
> additional
> >        information in struct rte_rib_v4_node which represents route
> entry.
> >        It can be next hop/set of next hops (i.e. active and feasible),
> >        pointers to link rte_rib_v4_node based on some criteria (i.e.
> next_hop),
> >        plenty of additional control plane information.
> >      - For dir24_8 implementation it is possible to remove
> rte_lpm_tbl_entry.depth
> >        field that helps to save 6 bits.
> >      - Also new dir24_8 implementation supports different next_hop sizes
> >        (1/2/4/8 bytes per next hop)
> >
> > It would be nice to hear your opinion. The draft is below.
> >
> > Medvedkin Vladimir (1):
> >   lib/rib: Add Routing Information Base library
> >
> >  config/common_base           |   6 +
> >  doc/api/doxy-api.conf        |   1 +
> >  lib/Makefile                 |   2 +
> >  lib/librte_rib/Makefile      |  43 ++++
> >  lib/librte_rib/rte_dir24_8.c | 411 ++++++++++++++++++++++++++++++
> +++++++++
> >  lib/librte_rib/rte_dir24_8.h | 144 ++++++++++++++
> >  lib/librte_rib/rte_rib.c     | 454 ++++++++++++++++++++++++++++++
> +++++++++++++
> >  lib/librte_rib/rte_rib.h     | 260 +++++++++++++++++++++++++
> >  8 files changed, 1321 insertions(+)
> >  create mode 100644 lib/librte_rib/Makefile
> >  create mode 100644 lib/librte_rib/rte_dir24_8.c
> >  create mode 100644 lib/librte_rib/rte_dir24_8.h
> >  create mode 100644 lib/librte_rib/rte_rib.c
> >  create mode 100644 lib/librte_rib/rte_rib.h
> >
>
> In network paralance a RIB is usually a full route table and FIB is the
> forwarding
> table in use. You probably don't want to call this a RIB. It looks more
> like an
> abstraction above FIB.
>
>
> https://networkengineering.stackexchange.com/questions/
> 38588/rib-vs-fib-differences
> http://aftabsiddiqui.com/index.php/ip-routing-table-
> rib-and-forwarding-table-fib/
>



-- 
Regards,
Vladimir

  reply	other threads:[~2017-07-11 23:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-11 19:33 Medvedkin Vladimir
2017-07-11 19:33 ` [dpdk-dev] [PATCH] lib/rib: Add Routing Information Base library Medvedkin Vladimir
2017-07-11 20:28   ` Stephen Hemminger
2017-07-11 23:17     ` Vladimir Medvedkin
2017-07-11 20:31 ` [dpdk-dev] [RFC] Add RIB library Stephen Hemminger
2017-07-11 23:13   ` Vladimir Medvedkin [this message]
2017-08-14 10:51 ` Bruce Richardson
2017-08-14 22:28   ` Vladimir Medvedkin
2017-08-15  8:23     ` Bruce Richardson
2017-08-15 10:49       ` Vladimir Medvedkin
2017-08-15 11:01         ` Vladimir Medvedkin
2018-01-16  0:41           ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANDrEH=uEoBnkvxUoaHQx1-OaNzFxQmbZkXGTyriXjMyPiSvRg@mail.gmail.com' \
    --to=medvedkinv@gmail.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).