[mpls-linux-general] questions

[Yon U. <hav...@gm...>]

Hi Jim,

 allow me to dump some random things out off my head on you.

 In past you said you were developing a hacked version of zebra to support
mpls. Have you done anything on that? (appart from your day job and vrf work,
are you on speed or what? ;-)

 I had some thoughts on that which I'm rescueing from mental swap now. I even
started to write some code, but it wasnt much, like 100 lines or so. Nothing
usefull.

 I guess 1st it is just a matter of writing lsr-portable, implementing
the lsr mib just like you did implement the ldp mib in ldp-portable's *.h.
This might allow reusing the impl.h from ldp-portable.

 There 2 approaches I can think of:
1) integrate lsr-portable into zebra
2) write another daemon (zebra beastie) just like ipinfusion did (maybe just
     to avoid the GPL of zebra?)

 Approach 1 seems the easiest. It will need expanding the zebra protocol,
but not as much. It will need routing tables a la juniper's inet.X (and
mpls.X, IIRC) (I did implement something alike in the last zebra port release).
And it avoids extra interdaemon chat (and latency).

 Approach 2 might seem interesting to distribute the load (not that I would
expect much load (wrt to say a celeron 700Mhz)).

 Label requests would have to be routed over the zebra protocol anyway, and
probably in a synchronous way (which cant be assured in the actual zebra
implementation), at least ldp-portable needs synchrounous label requests.
A solution would be to simulate this by requesting blocks (ranges) of labels
from lsr-portable (over the zebra protocol) at startup time, requesting
another range on a high water mark to avoid exhaustion. Another solution
could be to open a separate (synchronous, only 1 req outstanding, no
unrequested messages) channel for label requests (and other sync. messages).
IIRC, Juniper uses static label range allocations to the different protocols,
and is thus open to exhaustion. Maybe this is no longer the case, havent
read a juniper-mpls doc in a while.

 Routes sent over to zebra would need to have at least an optional label
appended and optionally things like 2547 RD/RT/random bytes if you want
to have a single zebra instance on a host, instead of many vrf-vound
(man chvrf(1)) instances.

 martini support in ldp-portable. Have you done anything? Do you have any
(3rd party) patches?

 cr-ldp: you (and her) said venisa cabrilla had some (beta) code, but it
wasnt quite working. Anything new?

 I think it would be nice to have an overloaded release, with all the patches
thrown in. Not unlike -RELEASE, -STABLE, -ENGINEERING in some other projects.
Maybe -BLOATED_WILL_CORE_DUMP? What do you think?

 I havent checked the sourceforge patch list in a while, now I realize, will
check it out.

 PHP, Label 3: would it be usefull/easy, to modify the kernel to interpret
label 3 as what it is? This would avoid special case handling in ldp-portable.
Or having to use label instructions, AFAIK.

 How can I get the NHLFE nexthop (the ip address) in the /proc files? I would
like to see it, but I can only get it with netlink/ioctl (if at all)?

regards
 yon