-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Wilson wrote:
> On Thu, 2011-07-07 at 01:09 +0400, Alexander V. Chernikov wrote:
> 
>> Are there any plans to move from different daemons to single one?
>>
> 
> Better would be to split them out onto a message bus with a common
> controlling CLI interface. 
> 
> That way they can talk to each other while maintaining process
> separation. It is very useful indeed to have multiple calculations going
> on at the same time without the risk of one of them blowing up and
> destroying the whole lot.
Actually, if we began talk about splitting into multiple daemons because
of multiple calculations and protocol bugs causing entire process crash
- - better to discuss splitting based not on address family but protocol
or protocol-instance-base.

Every architecture has its own pros and cons. Direct function calls for
any interested protocol is faster than doing syscalls for every unix
socket reads/writes and consumes less CPU resources.
Large route updates/reads are addressed in bird by splitting them into
smaller parts permitting other protocols doing their IO

Anyway, I'm talking about improving parts in _current_ architecture, not
about changing architecture (protocols exchange model) at all.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4VcecACgkQwcJ4iSZ1q2nUHwCgopUrpeRbCCljQ5+JFqfDbnuo
pmkAnjxo041Yep0mgEh6RcZknEiqdsG3
=5Evq
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ondrej Zajicek wrote:

On Thu, Jul 07, 2011 at 01:09:48AM +0400, Alexander V. Chernikov wrote:

...

Hello list!

Are there any plans to move from different daemons to single one?

From user point of view: We will live with both v4+v6 for the next 10+ years, having all dynamic routing in single place with single CLI is much more convenient.

From developer point of view: At the moment all code is based on ip_addr address type which is defined to be v4 OR v6 at compile time. FIBs API assume the same: IPv4 OR IPv6.

My idea [*] about the future of IPv4/IPv6 split is to allow IPv4 addresses be embedded in IPv6 ip_addr (probably using IPv4-mapped address prefix). That would allow integration with minimal changes (probably just some UI changes, some FIB integration and some tricks with dual compilation of one-AF protocols).

Bird4 would still be IPv4-only (with ip_addr of size 4 B) mainly for users with big route server deployments, but bird6 would support both IPv4 and IPv6.

Is this model consistent with your requirements / way of development? It depends on FIB/tricks implementation :) Actually, I'm trying to discuss those implementation details.

At the moment we have at least the following non-standard things in the world of routing: * VPNv4 address family (RFC 4364) (8-bytes route distinguisher, 4 byte IPv4 address) * VPNv6 address family (RFC 4659) (8-byte route distinguisher, 16 byte IPv6 address) * MPLS address family (RFC 3032) (size varies, it may be 16 bytes or more since label stack depth is implementation-specific. for example, sizeof(sockaddr_mpls) is ~80 bytes for my implementation) First two are purely BGP (RR or MPLS VPN PE client) internal tables and can be rolled within BGP protocol only. MPLS is more tricky since it operates numbers (labels) instead of IP addresses. additionally, label is only a key to another data (action and label stack to be imposed). We also need to install it to kernel somehow. For kernel it us just usual sockaddr structure, but passing it to krt_* function is not so easy. I'm thinking about a bit more general approach for FIB tables: All the time (except sh route CLI command) we need exact match only. If, for example, we: * introduce fib2_* (or mpfib_*) api specifying address family and sizeof() for "address" * use pointers instead of passing arguments by value in (at least fib2_* api) and all protocol hooks * do compare by memcpy() for searching (and use AF-dependent hash based on value passed in _init) life will be easier for non-IPv4/IPv6 AF and the first step towards ipv4+ipv6 merge will be done

[*] originally suggested by Martin Mares.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4VlI8ACgkQwcJ4iSZ1q2mnigCdHOMAnFIntZ/BJ+U7cuFalnZr v4gAnjeY00dyTicAxx1YVpRCqzuvm1hL =bP8v -----END PGP SIGNATURE-----

Ondrej Zajicek wrote:

On Thu, Jul 07, 2011 at 03:12:15PM +0400, Alexander V. Chernikov wrote:

...

It depends on FIB/tricks implementation :) Actually, I'm trying to discuss those implementation details.

At the moment we have at least the following non-standard things in the world of routing: * VPNv4 address family (RFC 4364) (8-bytes route distinguisher, 4 byte IPv4 address) * VPNv6 address family (RFC 4659) (8-byte route distinguisher, 16 byte IPv6 address) * MPLS address family (RFC 3032) (size varies, it may be 16 bytes or more since label stack depth is implementation-specific. for example, sizeof(sockaddr_mpls) is ~80 bytes for my implementation)

So you are developing doing some MPLS for BIRD development [*]? This is interesting. Definitely we could merge it when it will be ready. Before talking about some implementation details i would like to know your overall idea of how MPLS could be integrated to BIRD and how it will interact with other BIRD parts. It seems that MPLS is a bit different from traditional routing in several ways, so it is not straightforward (for example, how MPLS 'routes' will be represented in BIRD core, in struct rte like common routes? In separate tables from IPv4/v6 routes?) What are interactions (in BIRD) between MPLS and IPv4/v6 routing? What new concepts have to be introduced?

[*] Rhetorical question, i found http://freebsd.mpls.in/

To show "overall" view we have to describe what we will add and what will be required from BIRD first. First of all, mpls operates labels (20-bit number). Labels can be assigned to different entities (IPv4/IPv6 prefix, for example). Label is associated with action to do with this packet and has _local_ significance. The following actions are defined: * POP (pop one label from label stack) * PUSH (add one or more label to existing packet) * SWAP (replace top label) Small picture illustrating: http://upload.wikimedia.org/wikipedia/commons/e/eb/MPLS-swapping-071218.JPG All packets entering MPLS network are prepended by (one or more) MPLS labels (1). Router doing this is called Ingress LSR (Label Switch Router) and is PE (Provider Edge) router. After that, packet travels in MPLS networks via P (Provider) routers routed by its label (getting rewritten on every router) (2). In the end, packet exits from MPLS network on Egress LSR which is PE router, too (3). Appropriate signaling is needed to permit all this happen. Label exchange can be done different ways, for example: * LDP (RFC 5036), easy p2mp protocol like OSPF * RSVP-TE (RFC 3209) extension to RSVP, focused on provider features (Qos, fast rerouting, tunnels for explicit traffic flow, ..) * MPBGP (RFC 4364) BGP extension carrying labels and prefixes via extended communities in VPNv4/VPNv6 address family I've got more or less (actually less) working LDP implementation at the moment. MPLS labels can (and will be!) stacked together. This is used to provide services on MPLS network: top label is mostly used to reach destination PE router in MPLS cloud, and upper label(s) are used as service identification. I will describe L3 VPN setup from BIRD point of view. Very good and easy VPN explanation (using RSVP, but this doesn't matter) : http://www.ist-nobel.org/Nobel2/imatges/L3VPN_Training_course.pdf * ABSTRACT VIEW Imagine Provider network with P and PE routers. IGP is OSPF and LDP is enabled on all appropriate interfaces. OSPF is running in GRT (Global Routing Table), LDP connects to this table, too. LDP establishes relationship with all routers (exactly like OSPF does) and begin exchanging LMAPs (label mappings) (map FEC (forwading equivalent class, IPv4/IPv6 prefix for simplicity) to some number (label)). Every router generate LMAPs for every prefix in its GRT. After LMAP for some prefix is received and verified we need to notify kernel that route to given prefix is MPLS-enabled (case 1). Additionally, we assign local label to that prefix and install MPLS label with IGP nexthop for this prefix into kernel (AF_MPLS "route") (case 2). There are some special labels with pre-defined meaning. Label 0, for example is called "IPv4NULL". Router receiving packet with this label pops it and, if there is last label on stack assumes packet data to be IPv4 packet. Usual IP routing is the used to send packet. Imagine now we have a customer asking for L3 VPN for its 3 sites connected to our ISP routers PE1, PE2 and PE3. We now configure separate routing table on those 3 PE routers. Some globally unique RD (Route distinguisher) has to be assigned to this VPN instance (assigned by user). We than have to convert routes received from new routing table to VPNv4 routes with some custom attributes (stored in ext communities) containing RD, label assigned to this route and vice versa. We also have to notify kernel (update IP route and add AF_MPLS "route") for every prefix we need to. As a result, we will get the following picture (prefixes/label are random) on every PE router: route table "new" Prefix RD Router LABEL 192.168.1.0/24 31337:1 PE1 -- 192.168.2.0/24 31337:1 PE2 PUSH {31, 47} 192.168.3.0/24 31337:1 PE3 PUSH {44, 35} 192.168.13.0/24 31337:1 PE3 PUSH {44, 36} * BIRD USER VIEW table new; protocol ospf ospf0 { # some OSPF configuration in GRT } protocol ldp { export all; label range 20 4000; interface "em*" {}; interface "vlan*" {}; } protocol bgp bgp0 { description "Link to RR"; mpls vpn; # Some usual configuration } protocol l3vpn { table new; rd 31337:1; # Some import/export filters, by default - import # all routes with RT (route target) equal to RD # and export all routes with RT equal to RD } protocol direct { table new; interfaces "vlan136"; } * UNDER THE HOOD *** KERNEL INTERACTION *** Case 1: Route update can happen differently: we can install updated route IFF * LDP label exists * IGP nexthop is one of advertised LDP neighbour nexthops. LDP LMAP can arrive before or after IGP announce, so there is 2 different cases: 1) Prefix already exists from some IGP and LMAP arrives. Here we can find appropriate kernel instance and feed exactly the same route with new attribute (EAP_ADDITIONAL) containing MPLS sockaddr. We can, of course, call rt_update stuff, but: * Route is not considered better if some extended attributes are changed at the moment * There is no need to call all other protocols since they should not be interested in such update Direct updating seems much more appropriate 2) LMAP already exists and rt_notify is called. At the moment it is not possible for a protocol to alter announce: rt_notify calling order cannot be predicted, import_control has only local significance. Some pre-announce hook should be added permitting all interested protocols to add their attributes, at least. (we will insert EAP_ADDITIONAL attribute here) Case 2: This is more tricky. We can handle LIB (Label Information Database) as internal hash table, the main problem is kernel interaction. We can handle this either * adding some private hook to kernel (since there is no need to notify other protocols even in case of LDP + RSVP-TE (separate label space should be used). However, dumping (for the purpose of cleaning) AF_MPLS table requires another hook * By upgrading FIB / rtable: If (from the point of user) config tables will be not AF_bound (e.g. IPv4+IPv6) we will have to do enhance FIB api. My vision is the following: * make fib AF_ bound, specifying AF and sizeof(object) at fib_init (or fib2_init) * pass pointers to all fib_* related functions instead of addresses * do compare by memcpy() for searching (and use AF-dependent hash based on value passed in _init) * Pass AF in appropriate protocol hooks * Change struct network (move rte *routes up) to permit adding some dynamic-sized address after struct fib_node * Each rtable contains fib pointers to supported AFs Using this approach we can send route update by simply announcing label in GRT table with AF_MPLS *** PROTOCOL INTERACTION **** We have to change paradigm "All protocols are equal" to "All protocols are equal, but some protocols are more equal than others" We need some sort of API which permits to call some protocol-specific hook for given protocol type in given rtable. This is needed due to * LDP -> kernel protocol invocation * L3vpn label requests from LDP (see below) Alternatively, post-configure protocol hook should be added (current postconfigure is actually post-successfull-parse-and-config-structure-filled hook) to permit updating protocol pointers after config change Assuming multi protocol rtables each L3vpn instance subscribes on VPNv4/VPNv6 GRT fib instances and listens for routes announced by bgp sessions with "mpls vpn" keyword. (Some filters work should be done to permit filtering by RT) After route passed filtering l3vpn instance retrieves actual IPv4/IPv6 prefix and remote label, does recursive route lookup, requests local label from LDP and installs/updates kernel routes. Very much like pipe protocol In case of new route appearing into l3vpn base table ("new") it passes export filter, packs into VPNv4/VPNv6 family, another local label gets requested from LDP and finally route gets announced into appropriate VPN family in GRT. * PORTABILITY Actually, even all [known] mpls label,sockaddr and other definitions are not portable across platforms: Linux one (linux-mpls project): http://mpls-linux.git.sourceforge.net/git/gitweb.cgi?p=mpls-linux/mpls-linux... OpenBSD one: http://fxr.watson.org/fxr/source/netmpls/mpls.h?v=OPENBSD NetBSD one: http://fxr.watson.org/fxr/source/netmpls/mpls.h?v=NETBSD FreeBSD (from my implementation): http://freebsd.mpls.in/svn/filedetails.php?repname=FREEBSD+MPLS&path=%2Frele... rtsock is more or less the same for *BSD netlink is different, as usual Some additional (system-dependent) run-time kernel configuration is required at least in Linux and FreeBSD. I'm implementing FreeBSD part only (however I'll try to do as much portability as I can) Least common denominator we can get: * More flexible API permitting RR/MPLS * BGP VPN extensions * LDP implementation * L3VPN implementaion * Protocols interaction

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ondrej Zajicek wrote:
> On Tue, Jul 12, 2011 at 04:47:06AM +0400, Alexander V. Chernikov wrote:
>> To show "overall" view we have to describe what we will add and what
>> will be required from BIRD first.
> 
> 
> Thanks for the great overview. Sorry for a late answer, it took
> a while for me to get into MPLS and think about it.
> 
Sorry for a late answer, too. ETIME issues :(
>> * UNDER THE HOOD
>> *** KERNEL INTERACTION ***
> 
> 
> So essentially, there are three kinds of routes:
> 
>  * Standard IP routes with IP nexthops, which we already support.
> 
>  * MPLS routes, keyed by MPLS label and with MPLS action (NHLFE), these
> form a MPLS routing table (ILM). I will call these MPLS routes.
> 
>  * IP routes with MPLS action, used for encapsulation of incoming
> IP packets (FTN mapping), these share a routing table with standard IP
> routes (because depending of which route is chosen packet is either
> forwarded in a standard way, or encapsulated to MPLS). I will call these
> encapsulating routes.
> 
> 
> If i understand correctly your mail, you use some EAP_ADDITIONAL
> external attribute to represent encapsulating routes and use some new
> hook to attach these routes by third party protocol. I think this is not
> a good idea - to be semantically consistent, i think encapsulation
> routes should be represented by routes with new destination type
> (RTD_MPLS in dest field of struct rta) and whole NHLFE should be stored
> in new struct rta_mpls (or rta_nhlfe), which would be extension of
> struct rta (containing struct rta in the first field and NHLFE after
> that). Such structure could be easily passed as struct rta and functions
> from rt-attr.c can work with that, with jome some minor modifications
> (allocating, freeing and printing) dispatched based on dest field.
> Otherwise, they are very similar to standard IP routes and probably
> would need just some minor tweaks (and obviously kernel protocol support).
> 
> Therefore, such encapsulating route should be generated in a standard
> way as a new route - by rte_update, with LDP (or some other protocol)
> as true originator (in rta->proto and rta->source). I will comment
> that later.
Understood. This is much better than calling some protocol hooks directly.
> 
> 
> MPLS routes could use the same struct rta_mpls as encapsulating routes,
> but struct network (their fib_node) contains MPLS label instead of IP address.
> As MPLS label is small (and complex action is outside) i don't see any problems
> in reuse ip_addr prefix. Most things would work without modifications.
> There should be AF field in struct rtable and struct rte to distinguish
> routes.
Storing AF in rte makes much more sense if we use separate AFs for
inet/inet6.
> 
> 
> Therefore there would be two types of routing tables - IP and MPLS. I
> don't think it is a good idea to mix these. This may look inconsistent
> with idea of embedding IPv4 to IPv6, but IP protocols are much more
> similar, have a natural way to embed one in the other, have similar
> roles and protocol structure. MPLS routing table could be used to LDP -
> kernel interaction (routes imported from LDP and exported to kernel).
> This solves your Case 2 without any hacks.
So, from user point of view, I define
table xxx; for both ipv4 and IPv6 routes and
mpls table yyy; for MPLS routing table?
There should be base MPLS rtable (mpls_default, for example) as in IP.
We can also add a hack for automatically subscribe protocols for MPLS
routing table by type and other attributes. For example, every LDP
instance gets connected to an MPLS table (default or defined in config).
Kernel protocol instance gets connected to MPLS table only if its IP
table is the default one (GRT) or 'mpls table' keyword is supplied
explicitely. What about VPNv4/VPNv6 ? The same approach?

 Btw, how we will distinguish inet/inet6 rtes? (I'm talking about MP-BGP
/ IPv4-mapped cases)

> 
>> Case 1:
>> Route update can happen differently: we can install updated route IFF
>> * LDP label exists
>> * IGP nexthop is one of advertised LDP neighbour nexthops.
> 
> I think it is possible to handle all these cases and protocol
> interaction in an elegant way. LDP protocol, instead of just import and
> export to one table, could be connected to more tables, with different
> meanings. There are four interactions of LDP protocol - generating MPLS
> routes, generating encapsulating routes, importing label requests (can
> be handled as routes) [*] and tracking IGP table (to update nexthops of
> generated routes). These all can be handled as import or export of
> routes to proper tables. Standard table connection (to IP table) could
> be used for import (from LDP) of generated encapsulating routes and
> export (to LDP) of label requests. Another connection to MPLS table
> would be used for import (from LDP) of generated MPLS routes, and the
> last one is used for tracking IGP changes:
> 
> protocol ldp {
> 	export all; # label requests
> 	import all; # encapsulating routes
> 	mpls import all;  # MPLS routes
> 	# it is probably pointless to have configurable filters for IGP tracking
> 
> 	table t1; # table for import label requests and export encapsulating routes
> 	mpls table t2; # table for MPLS routes
> 	igp table t1; # table for tracking IGP routes, usually (and by default) the same as main table.
> }
> 
> [*] when i wrote that i thought that labels are distributed just by LDP
> and the purpose of label request is to propagate the label through LDP
> area. i didn't noticed that BGP/MPLS also distributes labels so they
> need to know assigned labels. So the idea would need some modifications.
Not sure this will work. Since t1 is an IP table cases when we need to
request specific label for:
* AToM
* RSVP-TE tunnels
will not work since there are no prefixes that can be mapped to such
request.


> (I assume that LDP generates encapsulating routes as a true originator,
> as i wrote before, not just attaching some attribute to the existing
> route.)
> 
> So my idea of your Case 1 scenario is like this:
> 
> In both subcases (LDP LMAP arrives and internal table with LMAPs changed;
> rt_notify() on 'tracked IGP connection' is used to signalize that
> tracked table changed), the same procedure is executed:
> 
> Internal LMAP table is examined, tracked IGP table is examined. If both
> are ready (for given prefix), appropriate encapsulating and MPLS routes
> are generated and propagated using rte_update(), otherwise nothing is
> generated and the previously generated route is withdrawn (rte_update()
> with NULL is called) (or perhaps an unreachable route is generated if
> LMAP is here but IGP route is missing). Simple and elegant.
.. and in case of label release we should remove label only and keep
original route
> If the encapsulated routes are saved
> 
> Case 2 scenarions are trivial - just standard updates.
> 
> 
> There are some tricky parts of IGP tracking - it is problematic
> to use standard RA_OPTIMAL update for this purpose, because if
> generated encapsulating routes are imported to the same table,
> these probably became the optimal ones and IGP routes would be
> shaded. Solution would be to use RA_ANY, and ignore notifications
> containing encapsulating routes, similarly 'examining the tracked
> IGP table' means looking up the fib node and find the best route,
> ignoring encapsulating ones.
> 
> For implementation of this behavior, there are two minor changes that
> needs to be done to the rt table code: First, currently accept_ra_types
> (RA_OPTIMAL/RA_ANY) is a property of a protocol, it needs to be a
> property of an announce hook (as LDP would have two hooks with
> RA_OPTIMAL and one hook with RA_ANY). Second, rte_announce() for 
> both in rte_recalculate should be moved after the route list
> is updated/relinked.
Agreed. Distinguishing RA_OPTIMAL and RA_ANY in current code is not a
trivial task and requires internals understanding. Either announce type
should be passed to announce hook or new hook should be added for RA_ANY
 event. The latter is more appropriate IMHO since RA_ANY is used by pipe
protocol only. Kernel protocol should track RA_ANY protocol hooks
looking for update source (LDP / RSVP) and re-install appropriate
routes. The only downside is situation when LDP signalling starts faster
than IGP. In that case we will get 3 updates instead of one (at least in
RTSOCK):
* RTM_ADD for original prefix
* RTM_DEL for this prefix (as part of krt_set_notify())
* RTM_ADD for modified prefix

RTM_CHANGE can be used in notify, but still: this gives 2 updates
instead of one.

> 
> 
> BTW, this whole dependency 'IGP table -> LDP function' is a bit similar
> to situation with recursive nexthops in IBGP, where IGP change also
> leads to change of IBGP route nexthop. In IBGP case it is handled
> automatically by rtable code (see rta_set_recursive_next_hop()
> discussion in route.h, hostcache and hostentry), LDP situation is a bit
> different, but perhaps the same mechanism could be extended to call
> protocol hook instead just update nexthop. This mechanism is useful if
> protocol waits for a change of a result of some recursive lookup in tracked
> table. But the LDP situation is much simpler, it just waits for an exact match
> change in tracked table.
> 
> 
>> * There is no need to call all other protocols since they should not be
>> interested in such update
> 
> Not true, other protocol may have filters that changes answer if you
> do some changes to route attributes. Ignoring that would lead to
> inconsistencies in route propagation.
> 
>> * By upgrading FIB / rtable:
>> If (from the point of user) config tables will be not AF_bound (e.g.
>> IPv4+IPv6) we will have to do enhance FIB api.
>>
>> My vision is the following:
>> * make fib AF_ bound, specifying AF and sizeof(object) at fib_init (or
>> fib2_init)
>> * pass pointers to all fib_* related functions instead of addresses
>> * do compare by memcpy() for searching (and use AF-dependent hash based
>> on value passed in _init)
>> * Pass AF in appropriate protocol hooks
> 
> As i wrote above, if we consider just IP (v4 and v6) and MPLS routes,
> i think that fixed size fib would be enough. But problems are with
> VPNvX AFs.
> 
> Originally i thought that having FIB / rtable with VPNvX routes is not a
> good idea - these AFs are just some wire representation of multiple 
> independent IP spaces, and we already have better representation of that
>  - just multiple routing tables. Having both these representations seemed
> unnecessary and would require some conversion between the parts that
> request the first representation and the parts that request the second
> one. But not having VPNvX routes is also cumbersome - protocols that
> uses these have to be bound to multple routing tables through some
> multiplexer. So it is probably easier to have tables with VPNvX
> AFs.
> 
> 
> Therefore, it is probably a good idea to extend FIBs in a way you
> suggested, with minor details changed. FIB / rtables would be uniform
> (AF_ bound), but there are just three AFs (IP, MPLS, VPN) - IPv4 and IPv6
> could be handled as one AF, embedded, the same for VPNv4 and VPNv6). To
> minimize code changes, struct fib_node would have ip_addr prefix, but
> might be allocated larger. 
Okay, so for IPv4+IPv6-enabled daemon we will allocate an ip_addr large
enough for holding IPv6 address? This can bump memory consumption for
setups with several full-views significantly.
> 
> Because each protocol and each its announce_hook have appropriate role,
> it is IMHO unnecessary to have AF in protocol hooks, but there should be
> check whether protocol/announce_hook is connected to appropriate rtable.
> 

To summarize required changes (please correct me):
1) Differentiate between RA_ANY and RA_OPTIMAL (new hook, possibly)
2) Add 3 AFs (AF_IP, AF_MPLS, AF_VPN) to the following structures:
* rtable
* fib
* rte
3) Add fib2_init with sizeof(AF object) supplied. Add appropriate field
to struct fib to hold this value.
4) Move to memcmp() in fib_find / fib_get
5) Set up default rtable for every supported AF. Connect protocol
instances to such default AFs based on protocol types
...

Most of this are more or less trivial changes not MPLS-bound (VPNv4/6
can be used in case of bird used as RR in MPLS network, for example).
Should I supply patches for these? What are your plans about commit
routemap ?













)



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4onmIACgkQwcJ4iSZ1q2lOcwCfT3CcT/bsxIlg1UiiArLWPq4k
w9EAnAzx7YifSgszTpHBcdwAvf01KI7S
=6LzQ
-----END PGP SIGNATURE-----

On 22.07.2011 14:52, Ondrej Zajicek wrote:
> On Fri, Jul 22, 2011 at 01:47:14AM +0400, Alexander V. Chernikov wrote:
>>> Therefore there would be two types of routing tables - IP and MPLS. I
>>> don't think it is a good idea to mix these. This may look inconsistent
>>> with idea of embedding IPv4 to IPv6, but IP protocols are much more
>>> similar, have a natural way to embed one in the other, have similar
>>> roles and protocol structure. MPLS routing table could be used to LDP -
>>> kernel interaction (routes imported from LDP and exported to kernel).
>>> This solves your Case 2 without any hacks.
>> So, from user point of view, I define
>> table xxx; for both ipv4 and IPv6 routes and
>> mpls table yyy; for MPLS routing table?
>
> Yes.
>
>> There should be base MPLS rtable (mpls_default, for example) as in IP.
>> We can also add a hack for automatically subscribe protocols for MPLS
>> routing table by type and other attributes. For example, every LDP
>> instance gets connected to an MPLS table (default or defined in config).
>> Kernel protocol instance gets connected to MPLS table only if its IP
>> table is the default one (GRT) or 'mpls table' keyword is supplied
>> explicitely. What about VPNv4/VPNv6 ? The same approach?
>
> Perhaps even default MPLS table should be explicitly configured [*] (as i guess
> not many BIRD users would use MPLS). Protocols requiring MPLS table would
> fail if it is not configured, protocol with optional MPLS support (kernel,
> static?) just do not connect to MPLS in that case. The same approach
> for VPNvX table.
>
> [*] probably like: mpls table XXX default;
Maybe it's better to turn on "general" mpls support?
e.g. 'mpls support;' or just 'mpls;' instead of propagating some table 
to be default?
>
>>   Btw, how we will distinguish inet/inet6 rtes? (I'm talking about MP-BGP
>> / IPv4-mapped cases)
>
> I planned to use IPv4-mapped prefix (::ffff:0:0/96), which is used for
> similar purposes in IP stack. But this should not be checked directly
> in protocols, there should be some macros in lib/ipv6.h for that.
>
>>> [*] when i wrote that i thought that labels are distributed just by LDP
>>> and the purpose of label request is to propagate the label through LDP
>>> area. i didn't noticed that BGP/MPLS also distributes labels so they
>>> need to know assigned labels. So the idea would need some modifications.
>> Not sure this will work. Since t1 is an IP table cases when we need to
>> request specific label for:
>> * AToM
>> * RSVP-TE tunnels
>> will not work since there are no prefixes that can be mapped to such
>> request.
>
> You are probably right. I originally thought about some specific
> 'request table' (where requests coded as routes with specific AF),
> but perhaps there should be used some other mechanism / other protocol
> hook. But it should be generic enough (some bus, allows at least more
> 'producers' and perhaps more 'consumers').
Okay, i see this as follows:
New rtable hook, service_hook, with uint32_3 bitmask specifying request 
classes we are responsible to:
/* Defined classes */
#define RCLASS_LABEL 0x01 /* MPLS label request */

Some request function:
int
request_data(rtable *t, struct service_request *req, void **buf, size_t 
*bufsize)

struct service_request {
    uint32_t    request; /* Single request class set */
    uint32_t    subclass; /* Subclass specific for request */
    proto       *p; /* caller protocol */
    char        data[0]; /* request-specific data follows */
}

function loops thru all registered hooks for given _class_ checking for 
reply until SR_OK or SR_FAIL is returned. It is up to protocol hook to 
check subclass.
#define SR_OK      0x01 /* Request successful */
#define SR_FAIL    0x02 /* Request failed */
#define SR_NEXT    0x03 /* Request skipped */
#define SR_UNAVAIL 0x04 /* No providers for this request */

As a result, caller get SR_UNAVAIL in case of no providers were able to 
serve request or SR_OK|SR_FAIL.

caller can setup buffer itself and pass pointer to pointer to buffer and 
pointer to buffer size to function, or request provider to allocate data 
for him setting *buf to NULL and bufsize to 0

struct service_reply { /* is returned in reply buffer */
   uint32_t    request;
   uint32_t    subclass;
   proto       *p; /* protocol, providing data */
   char        data[0]; /* request-specific data */
}



>
>>> Internal LMAP table is examined, tracked IGP table is examined. If both
>>> are ready (for given prefix), appropriate encapsulating and MPLS routes
>>> are generated and propagated using rte_update(), otherwise nothing is
>>> generated and the previously generated route is withdrawn (rte_update()
>>> with NULL is called) (or perhaps an unreachable route is generated if
>>> LMAP is here but IGP route is missing). Simple and elegant.
>> .. and in case of label release we should remove label only and keep
>> original route
>
> Yes.
>
>>> There are some tricky parts of IGP tracking - it is problematic
>>> to use standard RA_OPTIMAL update for this purpose, because if
>>> generated encapsulating routes are imported to the same table,
>>> these probably became the optimal ones and IGP routes would be
>>> shaded. Solution would be to use RA_ANY, and ignore notifications
>>> containing encapsulating routes, similarly 'examining the tracked
>>> IGP table' means looking up the fib node and find the best route,
>>> ignoring encapsulating ones.
>>>
>>> For implementation of this behavior, there are two minor changes that
>>> needs to be done to the rt table code: First, currently accept_ra_types
>>> (RA_OPTIMAL/RA_ANY) is a property of a protocol, it needs to be a
>>> property of an announce hook (as LDP would have two hooks with
>>> RA_OPTIMAL and one hook with RA_ANY). Second, rte_announce() for
>>> both in rte_recalculate should be moved after the route list
>>> is updated/relinked.
>
>> Agreed. Distinguishing RA_OPTIMAL and RA_ANY in current code is not a
>> trivial task and requires internals understanding. Either announce type
>> should be passed to announce hook or new hook should be added for RA_ANY
>>   event. The latter is more appropriate IMHO since RA_ANY is used by pipe
>> protocol only.
>
> I thought about that when i created RA_ANY and have chosen this approach.
> Probably best way is just to change rt_notify to have appropriate
> struct announce_hook as a second argument instead of struct rtable.
> struct announce_hook would contain RA_ANY/RA_OPTIMAL and possibly
> some protocol-specific data. As (probably) all protocols are in-tree,
> doing some wide but trivial changes is not a problem.
>
>> Kernel protocol should track RA_ANY protocol hooks
>> looking for update source (LDP / RSVP) and re-install appropriate
>> routes.
>
> I think kernel protocol should use RA_OPTIMAL as usual. This kind
> of RA_ANY usage is for protocols that export routes to the same
> table they listen (so 'source' routes would be shaded by their
> routes). These routes (LDP / RSVP) should have just highest
> priority.
>
>> The only downside is situation when LDP signalling starts faster
>> than IGP. In that case we will get 3 updates instead of one (at least in
>> RTSOCK):
>> * RTM_ADD for original prefix
>> * RTM_DEL for this prefix (as part of krt_set_notify())
>> * RTM_ADD for modified prefix
>>
>> RTM_CHANGE can be used in notify, but still: this gives 2 updates
>> instead of one.
>
> No, because RA_ANY is handled strictly before RA_OPTIMAL and routes
> are propagated synchronously depth-first:
>
> OSPF --RA_ANY-->  LDP
> LDP --RA_OPTIMAL-->  kernel
> OSPF --RA_OPTIMAL-->  kernel
>
Still I can't understand how exactly I can modify an announced IP route 
(still, from FreeBSD kernel point of view encapsulated route is a usual 
route with an attribute attached. From Linux point of view this should 
be more or less the same since an IP route lookup have to be done for 
incoming packet anyway and doing several different lookups is not a best 
idea). I've got RA_ANY hook called for a new route (and I should know 
that it is actually RA_OPTIMAL without some complex logic!), what I 
should do next ?

> But it is true that this is much dependent on internal implementation
> of route propagation. The first idea i had was to use separate
> tables for original and labeled routes (when just RA_OPTIMAL hooks),
> but that looks too cumbersome for users and ability to push a better
> route to the same (input) table has other possible usages.
>
>>> Therefore, it is probably a good idea to extend FIBs in a way you
>>> suggested, with minor details changed. FIB / rtables would be uniform
>>> (AF_ bound), but there are just three AFs (IP, MPLS, VPN) - IPv4 and IPv6
>>> could be handled as one AF, embedded, the same for VPNv4 and VPNv6). To
>>> minimize code changes, struct fib_node would have ip_addr prefix, but
>>> might be allocated larger.
>> Okay, so for IPv4+IPv6-enabled daemon we will allocate an ip_addr large
>> enough for holding IPv6 address? This can bump memory consumption for
>> setups with several full-views significantly.
>
> It increases memory consumtion, but not so much in a relative view - for
> each struct network there is at least one struct rte and in both of them
> there is just one ip_addr and both structures are nontrivial. So this
> relative increase would be about 1.15-1.2. Really big users would
> probably keep current splitted setting.
Okay, it's much easier from developer point of view. If you're not 
afraid of your users :)
>
>>> Because each protocol and each its announce_hook have appropriate role,
>>> it is IMHO unnecessary to have AF in protocol hooks, but there should be
>>> check whether protocol/announce_hook is connected to appropriate rtable.
>>>
>>
>> To summarize required changes (please correct me):
>> 1) Differentiate between RA_ANY and RA_OPTIMAL (new hook, possibly)
>> 2) Add 3 AFs (AF_IP, AF_MPLS, AF_VPN) to the following structures:
>> * rtable
>> * fib
>> * rte
>> 3) Add fib2_init with sizeof(AF object) supplied. Add appropriate field
>> to struct fib to hold this value.
>> 4) Move to memcmp() in fib_find / fib_get
>> 5) Set up default rtable for every supported AF. Connect protocol
>> instances to such default AFs based on protocol types
>
> 1a) other changes in rte_recalculate() related to propagation
> (clean up the table before calling RA_ANY hook).
>
> 1) and 1a) i will do myself and send you the patch, and also make
> some trivial example for exporting to the same table.
>
> 2) i am not sure if there is a reason to put explicit AF info
> to struct fib, AF compatibility could be handled on higher level
> (struct rtable in general, other direct users probably use just
> one AF).
No problem, I misinterpreted "FIB / rtables would be uniform (AF_ 
bound)" as "FIB / rtable needs AF infor in structure fields"
>
> 3) and hashing callback (and perhaps fib_route, but not sure if this is
> needed).
>
> 4) probably encapsulate that to some static inline key_equal() function.
>
> 5) see my related note above. Protocol binding to tables should check AFs.
>
> more:
>
> 6) RTD_MPLS in dest field, struct rta_mpls, as i wrote in the previous mail:
>
>>> i think encapsulation
>>> routes should be represented by routes with new destination type
>>> (RTD_MPLS in dest field of struct rta) and whole NHLFE should be stored
>>> in new struct rta_mpls (or rta_nhlfe), which would be extension of
>>> struct rta (containing struct rta in the first field and NHLFE after
>>> that). Such structure could be easily passed as struct rta and functions
>>> from rt-attr.c can work with that, with jome some minor modifications
>>> (allocating, freeing and printing) dispatched based on dest field.
>
>>> This rta could be used without changes also for MPLS routes.

I'll try to send you patches for all these as I see it in several days.
>
>
>> Most of this are more or less trivial changes not MPLS-bound (VPNv4/6
>> can be used in case of bird used as RR in MPLS network, for example).
>> Should I supply patches for these? What are your plans about commit
>> routemap ?
>
> I create GIT branch 'mpls' and would merge these patches to that branch
> soon. When we will have some major release, we could merge 'mpls' branch
> to master if there is some sufficient usage (i think that even just
> static and kernel protocol support for MPLS would be a good example
> usage). Other protocols (LDP, ...) probably should be merged when they
> are reasonable ready.
Will this branch available from official git repo ? It is not accessible 
(from its web interface at least).


Btw, some bird/LDP "status" report:

bird> show ldp neighbour
     Peer LDP Ident: 10.2.33.4:0; Local LDP Ident 10.0.0.88:0
          TCP connection: 10.2.33.4.11212 - 0.0.0.0.0
          State: Operational; Msgs sent/rcvd: 21/61; Downstream
          Up time: 00:02:27
          LDP discovery sources:
            em1, Src IP addr: 10.1.5.4
     Peer LDP Ident: 10.2.33.3:0; Local LDP Ident 10.0.0.88:0
          TCP connection: 10.2.33.3.11009 - 0.0.0.0.0
          State: Operational; Msgs sent/rcvd: 29/60; Downstream
          Up time: 00:02:20
          LDP discovery sources:
            em2, Src IP addr: 10.1.6.3
bird> show ldp bindings
   lib entry: 10.2.0.0/30
       local binding:  label: 25
       remote binding:  lsr: 10.2.33.4:0, label: ImpNULL
       remote binding:  lsr: 10.2.33.3:0, label: 23
   lib entry: 10.1.6.0/24
       remote binding:  lsr: 10.2.33.3:0, label: ImpNULL
       remote binding:  lsr: 10.2.33.4:0, label: 25
   lib entry: 10.0.0.0/24
       remote binding:  lsr: 10.2.33.3:0, label: 19
       remote binding:  lsr: 10.2.33.4:0, label: 23
   lib entry: 10.2.0.2/32
       local binding:  label: 26
       remote binding:  lsr: 10.2.33.4:0, label: 16
       remote binding:  lsr: 10.2.33.3:0, label: 24
   lib entry: 10.1.4.0/24
       local binding:  label: 29
       remote binding:  lsr: 10.2.33.4:0, label: ImpNULL
       remote binding:  lsr: 10.2.33.3:0, label: ImpNULL
   lib entry: 10.1.5.0/24
       remote binding:  lsr: 10.2.33.4:0, label: ImpNULL
       remote binding:  lsr: 10.2.33.3:0, label: ImpNULL
   lib entry: 1.2.3.5/32
       remote binding:  lsr: 10.2.33.3:0, label: 20
       remote binding:  lsr: 10.2.33.4:0, label: 21
   lib entry: 10.1.33.0/24
       local binding:  label: 28
       remote binding:  lsr: 10.2.33.4:0, label: ImpNULL
       remote binding:  lsr: 10.2.33.3:0, label: ImpNULL
   lib entry: 10.2.33.3/32
       local binding:  label: 31
       remote binding:  lsr: 10.2.33.3:0, label: ImpNULL
   lib entry: 10.2.33.4/32
       local binding:  label: 27
       remote binding:  lsr: 10.2.33.4:0, label: ImpNULL
       remote binding:  lsr: 10.2.33.3:0, label: 25
   lib entry: 10.1.6.88/32
       remote binding:  lsr: 10.2.33.3:0, label: 18
       remote binding:  lsr: 10.2.33.4:0, label: 19
   lib entry: 10.0.0.88/32
       remote binding:  lsr: 10.2.33.4:0, label: 17
       remote binding:  lsr: 10.2.33.3:0, label: 16
   lib entry: 10.1.5.88/32
       remote binding:  lsr: 10.2.33.3:0, label: 21
       remote binding:  lsr: 10.2.33.4:0, label: 18
bird> show ldp forwardingtable
Local  Outgoing       Prefix             Bytes Label    Outgoing   Next Hop
Label  Label or VC    or Tunnel Id       Switched       interface
20     SWAP           10.2.0.0/30        0              ? 
10.1.5.4
21     SWAP           10.2.0.2/32        0              ? 
10.1.5.4
22     SWAP           10.2.33.4/32       0              ? 
10.1.5.4
23     SWAP           10.1.33.0/24       0              ? 
10.1.5.4
24     SWAP           10.1.4.0/24        0              ? 
10.1.5.4
25     SWAP           10.2.0.0/30        0              ? 
10.1.5.4
26     SWAP           10.2.0.2/32        0              ? 
10.1.5.4
27     SWAP           10.2.33.4/32       0              ? 
10.1.5.4
28     SWAP           10.1.33.0/24       0              ? 
10.1.5.4
29     SWAP           10.1.4.0/24        0              ? 
10.1.5.4
30     SWAP           10.2.33.3/32       0              ? 
10.1.6.3
31     SWAP           10.2.33.3/32       0              ? 
10.1.6.3


>

It is sad to see how mutch effort there is for causing new problems and 
bugs buy trying merge chicken and dog to gether. In our system is over 
50 routers and over 500 routers via ospf. There is still buntch of bugs 
what cause un sync problems and domino effects and need to be fix. Two 
separated engine was purely good thing when we speak production 
networks. Actually on many large production networks ipv4 aind ipv6 
routers are on different machines for limiting problems.


31.7.2011 11:38, Alexander V. Chernikov kirjoitti:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alexander V. Chernikov wrote:
>> On 22.07.2011 14:52, Ondrej Zajicek wrote:
>>> On Fri, Jul 22, 2011 at 01:47:14AM +0400, Alexander V. Chernikov wrote:
>>>>> Therefore there would be two types of routing tables - IP and MPLS. I
>>>>> don't think it is a good idea to mix these. This may look inconsistent
>>>>> with idea of embedding IPv4 to IPv6, but IP protocols are much more
>>>>> similar, have a natural way to embed one in the other, have similar
>>>>> roles and protocol structure. MPLS routing table could be used to LDP -
>>>>> kernel interaction (routes imported from LDP and exported to kernel).
>>>>> This solves your Case 2 without any hacks.
>>>> So, from user point of view, I define
>>>> table xxx; for both ipv4 and IPv6 routes and
>>>> mpls table yyy; for MPLS routing table?
>>> Yes.
> Patch permitting fibs to be used for any address family attached.
> It should be considered as PoC patch for review. It works for my setup,
> but I haven't tested it in production. netlink is not tested at all.
>
> Some notes:
> * fib has to have address type field (due to fib_get and other functions
> using pointer to fib, not rtable)
> * Due to address variable length we store it inside fib node this way:
>
> |--------------------|
> |  struct fib_node   |
> |  *addr         --------\
> |--------------------|   |
> |  some user data    |   |
> |                    |   |
> |--------------------|   |
> | address data<-------/
> |                    |
> |--------------------|
> * Since we've got pointer to address data instead of data (ip_addr)
> itself, all 9000 places with "%I/%d" needs to be changed, so more
> general fib_print and fib2_print functions are implemented
>
> * Several net_* calls were converted to fib_*
>
>
>
> Btw, some IPv4/IPv6 merging questions/thoughts:
> * show route will show complete mess for table with both v4 and v6
> routes. Some sorting or 'afi ipv4|ipv6' has to be implemented.
> * fill_in_sockaddr|get_sockaddr from io.c are somehow inconsequent:
> fill_* uses OS-dependent set_inaddr to fill actual address data but
> get_* uses direct calls to memcpy and ipa_ntoh instead of existing
> OS-dependent get_inaddr. Moreover, set_ and get_ implementations are the
> same for linux, bsd (and they should be the same for other UNIX-like
> systems AFAIR, at least for IPv4/IPv6)
>
>
>
>>>> There should be base MPLS rtable (mpls_default, for example) as in IP.
>>>> We can also add a hack for automatically subscribe protocols for MPLS
>>>> routing table by type and other attributes. For example, every LDP
>>>> instance gets connected to an MPLS table (default or defined in config).
>>>> Kernel protocol instance gets connected to MPLS table only if its IP
>>>> table is the default one (GRT) or 'mpls table' keyword is supplied
>>>> explicitely. What about VPNv4/VPNv6 ? The same approach?
>>> Perhaps even default MPLS table should be explicitly configured [*]
>>> (as i guess
>>> not many BIRD users would use MPLS). Protocols requiring MPLS table would
>>> fail if it is not configured, protocol with optional MPLS support
>>> (kernel,
>>> static?) just do not connect to MPLS in that case. The same approach
>>> for VPNvX table.
>>>
>>> [*] probably like: mpls table XXX default;
>> Maybe it's better to turn on "general" mpls support?
>> e.g. 'mpls support;' or just 'mpls;' instead of propagating some table
>> to be default?
>>>>    Btw, how we will distinguish inet/inet6 rtes? (I'm talking about
>>>> MP-BGP
>>>> / IPv4-mapped cases)
>>> I planned to use IPv4-mapped prefix (::ffff:0:0/96), which is used for
>>> similar purposes in IP stack. But this should not be checked directly
>>> in protocols, there should be some macros in lib/ipv6.h for that.
>>>
>>>>> [*] when i wrote that i thought that labels are distributed just by LDP
>>>>> and the purpose of label request is to propagate the label through LDP
>>>>> area. i didn't noticed that BGP/MPLS also distributes labels so they
>>>>> need to know assigned labels. So the idea would need some
>>>>> modifications.
>>>> Not sure this will work. Since t1 is an IP table cases when we need to
>>>> request specific label for:
>>>> * AToM
>>>> * RSVP-TE tunnels
>>>> will not work since there are no prefixes that can be mapped to such
>>>> request.
>>> You are probably right. I originally thought about some specific
>>> 'request table' (where requests coded as routes with specific AF),
>>> but perhaps there should be used some other mechanism / other protocol
>>> hook. But it should be generic enough (some bus, allows at least more
>>> 'producers' and perhaps more 'consumers').
>> Okay, i see this as follows:
>> New rtable hook, service_hook, with uint32_3 bitmask specifying request
>> classes we are responsible to:
>> /* Defined classes */
>> #define RCLASS_LABEL 0x01 /* MPLS label request */
>>
>> Some request function:
>> int
>> request_data(rtable *t, struct service_request *req, void **buf, size_t
>> *bufsize)
>>
>> struct service_request {
>>     uint32_t    request; /* Single request class set */
>>     uint32_t    subclass; /* Subclass specific for request */
>>     proto       *p; /* caller protocol */
>>     char        data[0]; /* request-specific data follows */
>> }
>>
>> function loops thru all registered hooks for given _class_ checking for
>> reply until SR_OK or SR_FAIL is returned. It is up to protocol hook to
>> check subclass.
>> #define SR_OK      0x01 /* Request successful */
>> #define SR_FAIL    0x02 /* Request failed */
>> #define SR_NEXT    0x03 /* Request skipped */
>> #define SR_UNAVAIL 0x04 /* No providers for this request */
>>
>> As a result, caller get SR_UNAVAIL in case of no providers were able to
>> serve request or SR_OK|SR_FAIL.
>>
>> caller can setup buffer itself and pass pointer to pointer to buffer and
>> pointer to buffer size to function, or request provider to allocate data
>> for him setting *buf to NULL and bufsize to 0
>>
>> struct service_reply { /* is returned in reply buffer */
>>    uint32_t    request;
>>    uint32_t    subclass;
>>    proto       *p; /* protocol, providing data */
>>    char        data[0]; /* request-specific data */
>> }
>>
>>
>>
>>>>> Internal LMAP table is examined, tracked IGP table is examined. If both
>>>>> are ready (for given prefix), appropriate encapsulating and MPLS routes
>>>>> are generated and propagated using rte_update(), otherwise nothing is
>>>>> generated and the previously generated route is withdrawn (rte_update()
>>>>> with NULL is called) (or perhaps an unreachable route is generated if
>>>>> LMAP is here but IGP route is missing). Simple and elegant.
>>>> .. and in case of label release we should remove label only and keep
>>>> original route
>>> Yes.
>>>
>>>>> There are some tricky parts of IGP tracking - it is problematic
>>>>> to use standard RA_OPTIMAL update for this purpose, because if
>>>>> generated encapsulating routes are imported to the same table,
>>>>> these probably became the optimal ones and IGP routes would be
>>>>> shaded. Solution would be to use RA_ANY, and ignore notifications
>>>>> containing encapsulating routes, similarly 'examining the tracked
>>>>> IGP table' means looking up the fib node and find the best route,
>>>>> ignoring encapsulating ones.
>>>>>
>>>>> For implementation of this behavior, there are two minor changes that
>>>>> needs to be done to the rt table code: First, currently accept_ra_types
>>>>> (RA_OPTIMAL/RA_ANY) is a property of a protocol, it needs to be a
>>>>> property of an announce hook (as LDP would have two hooks with
>>>>> RA_OPTIMAL and one hook with RA_ANY). Second, rte_announce() for
>>>>> both in rte_recalculate should be moved after the route list
>>>>> is updated/relinked.
>>>> Agreed. Distinguishing RA_OPTIMAL and RA_ANY in current code is not a
>>>> trivial task and requires internals understanding. Either announce type
>>>> should be passed to announce hook or new hook should be added for RA_ANY
>>>>    event. The latter is more appropriate IMHO since RA_ANY is used by
>>>> pipe
>>>> protocol only.
>>> I thought about that when i created RA_ANY and have chosen this approach.
>>> Probably best way is just to change rt_notify to have appropriate
>>> struct announce_hook as a second argument instead of struct rtable.
>>> struct announce_hook would contain RA_ANY/RA_OPTIMAL and possibly
>>> some protocol-specific data. As (probably) all protocols are in-tree,
>>> doing some wide but trivial changes is not a problem.
>>>
>>>> Kernel protocol should track RA_ANY protocol hooks
>>>> looking for update source (LDP / RSVP) and re-install appropriate
>>>> routes.
>>> I think kernel protocol should use RA_OPTIMAL as usual. This kind
>>> of RA_ANY usage is for protocols that export routes to the same
>>> table they listen (so 'source' routes would be shaded by their
>>> routes). These routes (LDP / RSVP) should have just highest
>>> priority.
>>>
>>>> The only downside is situation when LDP signalling starts faster
>>>> than IGP. In that case we will get 3 updates instead of one (at least in
>>>> RTSOCK):
>>>> * RTM_ADD for original prefix
>>>> * RTM_DEL for this prefix (as part of krt_set_notify())
>>>> * RTM_ADD for modified prefix
>>>>
>>>> RTM_CHANGE can be used in notify, but still: this gives 2 updates
>>>> instead of one.
>>> No, because RA_ANY is handled strictly before RA_OPTIMAL and routes
>>> are propagated synchronously depth-first:
>>>
>>> OSPF --RA_ANY-->   LDP
>>> LDP --RA_OPTIMAL-->   kernel
>>> OSPF --RA_OPTIMAL-->   kernel
>>>
>> Still I can't understand how exactly I can modify an announced IP route
>> (still, from FreeBSD kernel point of view encapsulated route is a usual
>> route with an attribute attached. From Linux point of view this should
>> be more or less the same since an IP route lookup have to be done for
>> incoming packet anyway and doing several different lookups is not a best
>> idea). I've got RA_ANY hook called for a new route (and I should know
>> that it is actually RA_OPTIMAL without some complex logic!), what I
>> should do next ?
>>
>>> But it is true that this is much dependent on internal implementation
>>> of route propagation. The first idea i had was to use separate
>>> tables for original and labeled routes (when just RA_OPTIMAL hooks),
>>> but that looks too cumbersome for users and ability to push a better
>>> route to the same (input) table has other possible usages.
>>>
>>>>> Therefore, it is probably a good idea to extend FIBs in a way you
>>>>> suggested, with minor details changed. FIB / rtables would be uniform
>>>>> (AF_ bound), but there are just three AFs (IP, MPLS, VPN) - IPv4 and
>>>>> IPv6
>>>>> could be handled as one AF, embedded, the same for VPNv4 and VPNv6). To
>>>>> minimize code changes, struct fib_node would have ip_addr prefix, but
>>>>> might be allocated larger.
>>>> Okay, so for IPv4+IPv6-enabled daemon we will allocate an ip_addr large
>>>> enough for holding IPv6 address? This can bump memory consumption for
>>>> setups with several full-views significantly.
>>> It increases memory consumtion, but not so much in a relative view - for
>>> each struct network there is at least one struct rte and in both of them
>>> there is just one ip_addr and both structures are nontrivial. So this
>>> relative increase would be about 1.15-1.2. Really big users would
>>> probably keep current splitted setting.
>> Okay, it's much easier from developer point of view. If you're not
>> afraid of your users :)
>>>>> Because each protocol and each its announce_hook have appropriate role,
>>>>> it is IMHO unnecessary to have AF in protocol hooks, but there
>>>>> should be
>>>>> check whether protocol/announce_hook is connected to appropriate
>>>>> rtable.
>>>>>
>>>> To summarize required changes (please correct me):
>>>> 1) Differentiate between RA_ANY and RA_OPTIMAL (new hook, possibly)
>>>> 2) Add 3 AFs (AF_IP, AF_MPLS, AF_VPN) to the following structures:
>>>> * rtable
>>>> * fib
>>>> * rte
>>>> 3) Add fib2_init with sizeof(AF object) supplied. Add appropriate field
>>>> to struct fib to hold this value.
>>>> 4) Move to memcmp() in fib_find / fib_get
>>>> 5) Set up default rtable for every supported AF. Connect protocol
>>>> instances to such default AFs based on protocol types
>>> 1a) other changes in rte_recalculate() related to propagation
>>> (clean up the table before calling RA_ANY hook).
>>>
>>> 1) and 1a) i will do myself and send you the patch, and also make
>>> some trivial example for exporting to the same table.
>>>
>>> 2) i am not sure if there is a reason to put explicit AF info
>>> to struct fib, AF compatibility could be handled on higher level
>>> (struct rtable in general, other direct users probably use just
>>> one AF).
>> No problem, I misinterpreted "FIB / rtables would be uniform (AF_
>> bound)" as "FIB / rtable needs AF infor in structure fields"
>>> 3) and hashing callback (and perhaps fib_route, but not sure if this is
>>> needed).
>>>
>>> 4) probably encapsulate that to some static inline key_equal() function.
>>>
>>> 5) see my related note above. Protocol binding to tables should check
>>> AFs.
>>>
>>> more:
>>>
>>> 6) RTD_MPLS in dest field, struct rta_mpls, as i wrote in the previous
>>> mail:
>>>
>>>>> i think encapsulation
>>>>> routes should be represented by routes with new destination type
>>>>> (RTD_MPLS in dest field of struct rta) and whole NHLFE should be stored
>>>>> in new struct rta_mpls (or rta_nhlfe), which would be extension of
>>>>> struct rta (containing struct rta in the first field and NHLFE after
>>>>> that). Such structure could be easily passed as struct rta and
>>>>> functions
>>>>> from rt-attr.c can work with that, with jome some minor modifications
>>>>> (allocating, freeing and printing) dispatched based on dest field.
>>>>> This rta could be used without changes also for MPLS routes.
>> I'll try to send you patches for all these as I see it in several days.
>>>
>>>> Most of this are more or less trivial changes not MPLS-bound (VPNv4/6
>>>> can be used in case of bird used as RR in MPLS network, for example).
>>>> Should I supply patches for these? What are your plans about commit
>>>> routemap ?
>>> I create GIT branch 'mpls' and would merge these patches to that branch
>>> soon. When we will have some major release, we could merge 'mpls' branch
>>> to master if there is some sufficient usage (i think that even just
>>> static and kernel protocol support for MPLS would be a good example
>>> usage). Other protocols (LDP, ...) probably should be merged when they
>>> are reasonable ready.
>> Will this branch available from official git repo ? It is not accessible
>> (from its web interface at least).
>>
>>
>> Btw, some bird/LDP "status" report:
>>
>> bird>  show ldp neighbour
>>      Peer LDP Ident: 10.2.33.4:0; Local LDP Ident 10.0.0.88:0
>>           TCP connection: 10.2.33.4.11212 - 0.0.0.0.0
>>           State: Operational; Msgs sent/rcvd: 21/61; Downstream
>>           Up time: 00:02:27
>>           LDP discovery sources:
>>             em1, Src IP addr: 10.1.5.4
>>      Peer LDP Ident: 10.2.33.3:0; Local LDP Ident 10.0.0.88:0
>>           TCP connection: 10.2.33.3.11009 - 0.0.0.0.0
>>           State: Operational; Msgs sent/rcvd: 29/60; Downstream
>>           Up time: 00:02:20
>>           LDP discovery sources:
>>             em2, Src IP addr: 10.1.6.3
>> bird>  show ldp bindings
>>    lib entry: 10.2.0.0/30
>>        local binding:  label: 25
>>        remote binding:  lsr: 10.2.33.4:0, label: ImpNULL
>>        remote binding:  lsr: 10.2.33.3:0, label: 23
>>    lib entry: 10.1.6.0/24
>>        remote binding:  lsr: 10.2.33.3:0, label: ImpNULL
>>        remote binding:  lsr: 10.2.33.4:0, label: 25
>>    lib entry: 10.0.0.0/24
>>        remote binding:  lsr: 10.2.33.3:0, label: 19
>>        remote binding:  lsr: 10.2.33.4:0, label: 23
>>    lib entry: 10.2.0.2/32
>>        local binding:  label: 26
>>        remote binding:  lsr: 10.2.33.4:0, label: 16
>>        remote binding:  lsr: 10.2.33.3:0, label: 24
>>    lib entry: 10.1.4.0/24
>>        local binding:  label: 29
>>        remote binding:  lsr: 10.2.33.4:0, label: ImpNULL
>>        remote binding:  lsr: 10.2.33.3:0, label: ImpNULL
>>    lib entry: 10.1.5.0/24
>>        remote binding:  lsr: 10.2.33.4:0, label: ImpNULL
>>        remote binding:  lsr: 10.2.33.3:0, label: ImpNULL
>>    lib entry: 1.2.3.5/32
>>        remote binding:  lsr: 10.2.33.3:0, label: 20
>>        remote binding:  lsr: 10.2.33.4:0, label: 21
>>    lib entry: 10.1.33.0/24
>>        local binding:  label: 28
>>        remote binding:  lsr: 10.2.33.4:0, label: ImpNULL
>>        remote binding:  lsr: 10.2.33.3:0, label: ImpNULL
>>    lib entry: 10.2.33.3/32
>>        local binding:  label: 31
>>        remote binding:  lsr: 10.2.33.3:0, label: ImpNULL
>>    lib entry: 10.2.33.4/32
>>        local binding:  label: 27
>>        remote binding:  lsr: 10.2.33.4:0, label: ImpNULL
>>        remote binding:  lsr: 10.2.33.3:0, label: 25
>>    lib entry: 10.1.6.88/32
>>        remote binding:  lsr: 10.2.33.3:0, label: 18
>>        remote binding:  lsr: 10.2.33.4:0, label: 19
>>    lib entry: 10.0.0.88/32
>>        remote binding:  lsr: 10.2.33.4:0, label: 17
>>        remote binding:  lsr: 10.2.33.3:0, label: 16
>>    lib entry: 10.1.5.88/32
>>        remote binding:  lsr: 10.2.33.3:0, label: 21
>>        remote binding:  lsr: 10.2.33.4:0, label: 18
>> bird>  show ldp forwardingtable
>> Local  Outgoing       Prefix             Bytes Label    Outgoing   Next Hop
>> Label  Label or VC    or Tunnel Id       Switched       interface
>> 20     SWAP           10.2.0.0/30        0              ? 10.1.5.4
>> 21     SWAP           10.2.0.2/32        0              ? 10.1.5.4
>> 22     SWAP           10.2.33.4/32       0              ? 10.1.5.4
>> 23     SWAP           10.1.33.0/24       0              ? 10.1.5.4
>> 24     SWAP           10.1.4.0/24        0              ? 10.1.5.4
>> 25     SWAP           10.2.0.0/30        0              ? 10.1.5.4
>> 26     SWAP           10.2.0.2/32        0              ? 10.1.5.4
>> 27     SWAP           10.2.33.4/32       0              ? 10.1.5.4
>> 28     SWAP           10.1.33.0/24       0              ? 10.1.5.4
>> 29     SWAP           10.1.4.0/24        0              ? 10.1.5.4
>> 30     SWAP           10.2.33.3/32       0              ? 10.1.6.3
>> 31     SWAP           10.2.33.3/32       0              ? 10.1.6.3
>>
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk41FJEACgkQwcJ4iSZ1q2kZNwCfZHk19PuXn2esNZ/KrvXOir5v
> zTMAoKe78CsexI0pPJ4li50e8teBCcpa
> =yqPo
> -----END PGP SIGNATURE-----


-- 
Kaikki viestissä ilmoitetut summat ovat alvittomia, ellei toisin ole kyseisen summan yhteydessä ilmoitettu.

--
F-Solutions Oy

Tapio Haapala

PL 7, 90571 Oulu
GSM   040-0998371
Skype burner-
IRC   Burner@ircnet

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ondrej Zajicek wrote:
> On Fri, Jul 22, 2011 at 01:47:14AM +0400, Alexander V. Chernikov wrote:
>>> Therefore there would be two types of routing tables - IP and MPLS. I
>>> don't think it is a good idea to mix these. This may look inconsistent
>>> with idea of embedding IPv4 to IPv6, but IP protocols are much more
>>> similar, have a natural way to embed one in the other, have similar
>>> roles and protocol structure. MPLS routing table could be used to LDP -
>>> kernel interaction (routes imported from LDP and exported to kernel).
>>> This solves your Case 2 without any hacks.
I've tried to use this approach to add VPNv4|VPNv6 MP-BGP support.

Unfortunately I can't see any benefits in this idea.
I work with an IPv4 version (because using IPv6 version for IPv4
protocols will require me to make patches for all appropriate protocols
based on non-reviewed fib patch which is another not even discussed task).
As a result I'm stuck with with sizeof(ip_addr) == 4 and supporting IPv6
(at least not breaking existing support) within the same code in MP-BGP
drives me crazy.

Some of the following arguments are not valuable from an ipv6-only
daemon slowly starting to support IPv4 approach, but still: merging IPv4
and IPv6 in single table is wrong IMHO.

Most of bird network protocols support single family by design: rip,
ospfv2, ospfv3. Those protocols doesn't require unified addresses/tables
at all.

For BGP there are no benefits, too:
* ip_addr is not unified enough to support all MP-BGP families. (and it
is not enough for kernel protocol, too)
* IPv4 and IPv6 are handled completely different in BGP (BGP4 attributes
vs MP-BGP attributes)
* Next hop rta have to be altered or more complex logic for determining
address family are required
* It is much easier to use specific address prefixes for every address
family instead of using this approach in general but have some exceptions
* Generic rtable approach seems to be more complex: for some 'real'
families tables are different, for some - not.
* We have to add 'fake' families to rtable for the purpose of getting
sizeof(address data)

I've ended with rolling my own ip4_addr and ip6_addr for updating MP-BGP
implementation.


I see the following alternative solution for IPv4/IPv6 tables & stuff:
* Use separate tables for IPv4 and IPv6 instead of unified one
* Permit (internally) to create multiple rtables with the same name but
different AF
* Restrict users to do this
* Config file definition 'table XXX' creates both IPv4 AND IPv6 rtables
* Config file definition 'table XXX ipv4|ipv4' creates table for
requested AF only.
* Protocols with multiple AFs support (static, direct, kernel, BGP)
declare this  (maybe as supported protocols mask?) at the beginning and
get connected to appropriate rtables

- From user point of view nothing is changed. 'sh route' sorting problem
gets away, too.

Some fixes have to be done for filtering framework (af checking for
every rule?)

>> So, from user point of view, I define
>> table xxx; for both ipv4 and IPv6 routes and
>> mpls table yyy; for MPLS routing table?
> 
> Yes.
> 
>> There should be base MPLS rtable (mpls_default, for example) as in IP.
>> We can also add a hack for automatically subscribe protocols for MPLS
>> routing table by type and other attributes. For example, every LDP
>> instance gets connected to an MPLS table (default or defined in config).
>> Kernel protocol instance gets connected to MPLS table only if its IP
>> table is the default one (GRT) or 'mpls table' keyword is supplied
>> explicitely. What about VPNv4/VPNv6 ? The same approach?
> 
> Perhaps even default MPLS table should be explicitly configured [*] (as i guess
> not many BIRD users would use MPLS). Protocols requiring MPLS table would
> fail if it is not configured, protocol with optional MPLS support (kernel,
> static?) just do not connect to MPLS in that case. The same approach
> for VPNvX table.
> 
> [*] probably like: mpls table XXX default;
> 
>>  Btw, how we will distinguish inet/inet6 rtes? (I'm talking about MP-BGP
>> / IPv4-mapped cases)
> 
> I planned to use IPv4-mapped prefix (::ffff:0:0/96), which is used for
> similar purposes in IP stack. But this should not be checked directly
> in protocols, there should be some macros in lib/ipv6.h for that.



> 
>>> [*] when i wrote that i thought that labels are distributed just by LDP
>>> and the purpose of label request is to propagate the label through LDP
>>> area. i didn't noticed that BGP/MPLS also distributes labels so they
>>> need to know assigned labels. So the idea would need some modifications.
>> Not sure this will work. Since t1 is an IP table cases when we need to
>> request specific label for:
>> * AToM
>> * RSVP-TE tunnels
>> will not work since there are no prefixes that can be mapped to such
>> request.
> 
> You are probably right. I originally thought about some specific
> 'request table' (where requests coded as routes with specific AF),
> but perhaps there should be used some other mechanism / other protocol
> hook. But it should be generic enough (some bus, allows at least more
> 'producers' and perhaps more 'consumers').
> 
>>> Internal LMAP table is examined, tracked IGP table is examined. If both
>>> are ready (for given prefix), appropriate encapsulating and MPLS routes
>>> are generated and propagated using rte_update(), otherwise nothing is
>>> generated and the previously generated route is withdrawn (rte_update()
>>> with NULL is called) (or perhaps an unreachable route is generated if
>>> LMAP is here but IGP route is missing). Simple and elegant.
>> .. and in case of label release we should remove label only and keep
>> original route
> 
> Yes.
> 
>>> There are some tricky parts of IGP tracking - it is problematic
>>> to use standard RA_OPTIMAL update for this purpose, because if
>>> generated encapsulating routes are imported to the same table,
>>> these probably became the optimal ones and IGP routes would be
>>> shaded. Solution would be to use RA_ANY, and ignore notifications
>>> containing encapsulating routes, similarly 'examining the tracked
>>> IGP table' means looking up the fib node and find the best route,
>>> ignoring encapsulating ones.
>>>
>>> For implementation of this behavior, there are two minor changes that
>>> needs to be done to the rt table code: First, currently accept_ra_types
>>> (RA_OPTIMAL/RA_ANY) is a property of a protocol, it needs to be a
>>> property of an announce hook (as LDP would have two hooks with
>>> RA_OPTIMAL and one hook with RA_ANY). Second, rte_announce() for 
>>> both in rte_recalculate should be moved after the route list
>>> is updated/relinked.
> 
>> Agreed. Distinguishing RA_OPTIMAL and RA_ANY in current code is not a
>> trivial task and requires internals understanding. Either announce type
>> should be passed to announce hook or new hook should be added for RA_ANY
>>  event. The latter is more appropriate IMHO since RA_ANY is used by pipe
>> protocol only.
> 
> I thought about that when i created RA_ANY and have chosen this approach.
> Probably best way is just to change rt_notify to have appropriate
> struct announce_hook as a second argument instead of struct rtable.
> struct announce_hook would contain RA_ANY/RA_OPTIMAL and possibly
> some protocol-specific data. As (probably) all protocols are in-tree,
> doing some wide but trivial changes is not a problem.
> 
>> Kernel protocol should track RA_ANY protocol hooks
>> looking for update source (LDP / RSVP) and re-install appropriate
>> routes.
> 
> I think kernel protocol should use RA_OPTIMAL as usual. This kind
> of RA_ANY usage is for protocols that export routes to the same
> table they listen (so 'source' routes would be shaded by their
> routes). These routes (LDP / RSVP) should have just highest
> priority.
> 
>> The only downside is situation when LDP signalling starts faster
>> than IGP. In that case we will get 3 updates instead of one (at least in
>> RTSOCK):
>> * RTM_ADD for original prefix
>> * RTM_DEL for this prefix (as part of krt_set_notify())
>> * RTM_ADD for modified prefix
>>
>> RTM_CHANGE can be used in notify, but still: this gives 2 updates
>> instead of one.
> 
> No, because RA_ANY is handled strictly before RA_OPTIMAL and routes
> are propagated synchronously depth-first:
> 
> OSPF --RA_ANY--> LDP
> LDP --RA_OPTIMAL--> kernel
> OSPF --RA_OPTIMAL--> kernel
> 
> But it is true that this is much dependent on internal implementation
> of route propagation. The first idea i had was to use separate
> tables for original and labeled routes (when just RA_OPTIMAL hooks),
> but that looks too cumbersome for users and ability to push a better
> route to the same (input) table has other possible usages.
> 
>>> Therefore, it is probably a good idea to extend FIBs in a way you
>>> suggested, with minor details changed. FIB / rtables would be uniform
>>> (AF_ bound), but there are just three AFs (IP, MPLS, VPN) - IPv4 and IPv6
>>> could be handled as one AF, embedded, the same for VPNv4 and VPNv6). To
>>> minimize code changes, struct fib_node would have ip_addr prefix, but
>>> might be allocated larger. 
>> Okay, so for IPv4+IPv6-enabled daemon we will allocate an ip_addr large
>> enough for holding IPv6 address? This can bump memory consumption for
>> setups with several full-views significantly.
> 
> It increases memory consumtion, but not so much in a relative view - for
> each struct network there is at least one struct rte and in both of them
> there is just one ip_addr and both structures are nontrivial. So this
> relative increase would be about 1.15-1.2. Really big users would
> probably keep current splitted setting.
> 
>>> Because each protocol and each its announce_hook have appropriate role,
>>> it is IMHO unnecessary to have AF in protocol hooks, but there should be
>>> check whether protocol/announce_hook is connected to appropriate rtable.
>>>
>> To summarize required changes (please correct me):
>> 1) Differentiate between RA_ANY and RA_OPTIMAL (new hook, possibly)
>> 2) Add 3 AFs (AF_IP, AF_MPLS, AF_VPN) to the following structures:
>> * rtable
>> * fib
>> * rte
>> 3) Add fib2_init with sizeof(AF object) supplied. Add appropriate field
>> to struct fib to hold this value.
>> 4) Move to memcmp() in fib_find / fib_get
>> 5) Set up default rtable for every supported AF. Connect protocol
>> instances to such default AFs based on protocol types
> 
> 1a) other changes in rte_recalculate() related to propagation
> (clean up the table before calling RA_ANY hook).
> 
> 1) and 1a) i will do myself and send you the patch, and also make
> some trivial example for exporting to the same table.
> 
> 2) i am not sure if there is a reason to put explicit AF info 
> to struct fib, AF compatibility could be handled on higher level
> (struct rtable in general, other direct users probably use just
> one AF).
> 
> 3) and hashing callback (and perhaps fib_route, but not sure if this is
> needed).
> 
> 4) probably encapsulate that to some static inline key_equal() function.
> 
> 5) see my related note above. Protocol binding to tables should check AFs.
> 
> more:
> 
> 6) RTD_MPLS in dest field, struct rta_mpls, as i wrote in the previous mail:
> 
>>> i think encapsulation
>>> routes should be represented by routes with new destination type
>>> (RTD_MPLS in dest field of struct rta) and whole NHLFE should be stored
>>> in new struct rta_mpls (or rta_nhlfe), which would be extension of
>>> struct rta (containing struct rta in the first field and NHLFE after
>>> that). Such structure could be easily passed as struct rta and functions
>>> from rt-attr.c can work with that, with jome some minor modifications
>>> (allocating, freeing and printing) dispatched based on dest field.
> 
>>> This rta could be used without changes also for MPLS routes.
> 
> 
>> Most of this are more or less trivial changes not MPLS-bound (VPNv4/6
>> can be used in case of bird used as RR in MPLS network, for example).
>> Should I supply patches for these? What are your plans about commit
>> routemap ?
> 
> I create GIT branch 'mpls' and would merge these patches to that branch
> soon. When we will have some major release, we could merge 'mpls' branch
> to master if there is some sufficient usage (i think that even just
> static and kernel protocol support for MPLS would be a good example
> usage). Other protocols (LDP, ...) probably should be merged when they
> are reasonable ready.
> 



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4+becACgkQwcJ4iSZ1q2kKhwCfZyy8bQ8s8kzq8zmbMD1w2I6z
eacAniMi+6YHkas0UQ+adO/QRewQL6fP
=eXEr
-----END PGP SIGNATURE-----