kbfd-devel Mailing List for kbfd
Status: Alpha
Brought to you by:
thehajime
Menu
▾
▴
kbfd-devel — Mailing list for developer
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(11) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Peter S. <pes...@gm...> - 2008-06-11 14:07:49
|
On Wed, Jun 11, 2008 at 12:59 PM, Hajime Tazaki <ta...@sf...> wrote: > > > And you have your own application for kbfd? > Great! I'd like to see it if you don't mind. ;) Of course. It is a research project at the university present in my signature, aiming to provide a reasonably usable implementation of the Not-via IP Fast Reroute algorithm (which is an IETF draft maintained by Cicso, see http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-ipfrr-notvia-addresses-02.txt). IP Fast Reroute techniques in general try to provide QoS in IP networks by re-routing traffic around a failed component (e.g. router or link). They aim to be fast by utilizing two key features: there is no global signalling of the failure (contrary to OSPF which would originate LSAs announcing the topology change), and secondly, each node prepares for any possible single failure in advance, before anything actually has failed. This approach enables them to act immediately (that is, to re-route without further computation) and locally (routers not adjacent to the failure don't have to do anything). For all of this to be achieved, each router has to know when one of its neighbours goes down, or is operational again. This task is fulfilled by running BFD sessions between each pair of adjacent routers, for which we use kbfd. If you are interested in the source code, I will upload a tarball to let you examine it. It has been written in C++ for Linux, and so far stood the proof of a couple of live demos, so should be stable enough for others to check out. Regards, Peter -- Peter Szilagyi Budapest University of Technology and Economics Project page: http://opt.tmit.bme.hu/~kbfd/ |
|
From: Peter S. <pes...@gm...> - 2008-06-11 13:39:38
|
On Wed, Jun 11, 2008 at 12:43 PM, Hajime Tazaki <ta...@sf...> wrote: > > How about the adding information to bfd_peer_fill_info()? > Also if you would change that function, modification for > userspace is required. Good point, I've just updated the patches to provide that piece of information via bfd_peer_fill_info(). > And if possible, please try to modify zebra/quagga source to > call BFD_SETDSCP. I will look into this if I have some time. If I happen to know it well, quagga does not officially support bfd, only through your patch, which dates back to the end of January this year. Is there perhaps a more recent version of this quagga-bfd-support.patch? Regards, Peter -- Peter Szilagyi Budapest University of Technology and Economics Project page: http://opt.tmit.bme.hu/~kbfd/ |
|
From: Hajime Tazaki<ta...@sf...> - 2008-06-11 10:59:34
|
At Wed, 11 Jun 2008 12:47:12 +0200, Peter Szilagyi wrote: > >On Wed, Jun 11, 2008 at 12:34 PM, Hajime Tazaki <ta...@sf...> wrote: >> >> I guess that you are talking about using bfd from BGP. >> #ospfd/ospf6d can recognize ifindex when they create the new >> session. > >Hi, > >I was setting up BFD connections from my own application, not through >quagga's ospfd. Since than I've managed to figure out that I should >simply have called if_nametoindex() and fill in the bfd_nl_linkinfo >struct accordingly. It was by no means any fault of kbfd, just my >ignorance about this ifindex stuff. I see. And you have your own application for kbfd? Great! I'd like to see it if you don't mind. ;) thanks, hajime |
|
From: Peter S. <pes...@gm...> - 2008-06-11 10:47:03
|
On Wed, Jun 11, 2008 at 12:34 PM, Hajime Tazaki <ta...@sf...> wrote: > > I guess that you are talking about using bfd from BGP. > #ospfd/ospf6d can recognize ifindex when they create the new > session. Hi, I was setting up BFD connections from my own application, not through quagga's ospfd. Since than I've managed to figure out that I should simply have called if_nametoindex() and fill in the bfd_nl_linkinfo struct accordingly. It was by no means any fault of kbfd, just my ignorance about this ifindex stuff. Thanks for your reply, Peter |
|
From: Hajime Tazaki<ta...@sf...> - 2008-06-11 10:44:18
|
Hi Peter, Thank you for you patch! How about the adding information to bfd_peer_fill_info()? Also if you would change that function, modification for userspace is required. And if possible, please try to modify zebra/quagga source to call BFD_SETDSCP. Thank you very much! hajime At Wed, 11 Jun 2008 10:40:52 +0200, Peter Szilagyi wrote: > >Hi, > >I have added a new netlink message type BFD_SETDSCP to allow users of >kbfd set the DiffServ Code Point of BFD control packets. The patches >are available at the usual site: http://opt.tmit.bme.hu/~kbfd/ > >Regards, >Peter > >-- >Peter Szilagyi >Budapest University of Technology and Economics >Project page: http://opt.tmit.bme.hu/~kbfd/ > >------------------------------------------------------------------------- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >Kbfd-devel mailing list >Kbf...@li... >https://lists.sourceforge.net/lists/listinfo/kbfd-devel |
|
From: Hajime Tazaki<ta...@sf...> - 2008-06-11 10:35:13
|
Hi Peter,
Welcom to the kbfd-devel ML!
I'm waiting for you.
At Sun, 8 Jun 2008 21:19:23 +0200,
Peter Szilagyi wrote:
>I have a question regarding the recently implemented BFD interval
>command (BFD_SETLINK).
>
>In order to change BFD timer intervals, one has to fill in a
>bfd_nl_linkinfo structure, and send it through the netlink socket to
>kbfd. How can I obtain the correct value for the ifindex field of this
>structure from userspace, if I have just set up a new session with a
>peer? All I know is the source and destination interface addresses
>involved in this BFD session.
I guess that you are talking about using bfd from BGP.
#ospfd/ospf6d can recognize ifindex when they create the new
session.
Ah, this might be a bug.
If the session was created, and userspace didn't specify
ifindex of this session, kbfd would try to get the ifindex
value from the destination address of this session.
Like below, (from bfd_session_new() in kbfd_session.c:)
if (ifindex == 0)
ifindex = bfd->proto->get_oif(dst);
But if there is no route information to the destination at
this time, kbfd cannot get this ifindex value. After that,
"show bfd neighbors" command would show "unknown" interface.
This should be fixed with retrying to set the value of
ifindex when session's state would change to "BSM_Up".
And when the session of bfd has just created, and the route
to the destination isn't prepared, we cannot see which
interface would be used by this session.
Actually kbfd support only 1-hop neighbor, so this should be
done by operator at now.....
#Did you mean that?
I hope this is your question......
regards,
hajime
|
|
From: Peter S. <pes...@gm...> - 2008-06-11 08:40:46
|
Hi, I have added a new netlink message type BFD_SETDSCP to allow users of kbfd set the DiffServ Code Point of BFD control packets. The patches are available at the usual site: http://opt.tmit.bme.hu/~kbfd/ Regards, Peter -- Peter Szilagyi Budapest University of Technology and Economics Project page: http://opt.tmit.bme.hu/~kbfd/ |
|
From: Peter S. <pes...@gm...> - 2008-06-09 07:06:54
|
On Sat, Jun 7, 2008 at 2:50 PM, Hajime Tazaki <ta...@sf...> wrote: > > Prioritizing packet with DSCP is good idea, but I think that > this couldn't be absolute solution, though.. > But some situation is helped by this trick. > > BTW, I think that BFD needs some "flapping protection > method" in core specification. The problem you explained > might be happened in real world. I'm not sure flapping protection is within the scope of BFD, if by flapping we mean real interface failure/recovery. BFD should report link state changes according to its timeout settings, and should not obscure them even if it considers them to be flapping. OTOH if we try to deal with the problem I described above (that is, a "virtual" flapping due to delayed/lost BFD control packets), there's not much to do in BFD level except using enlarged timer intervals -- or, some kind of priority given to BFD packets, e.g. DSCP. Whether BFD packets need this special treatment is to be judged by the user of the BFD implementation, not by the implementation itself. > The prioritizing technique doesn't work all situation, and > if one box could prioritize the BFD processing with OS > support or hardware assist, the intermediate node would not > treat such way. The internet is always so. You are right in general, but if someone manages a routing domain on his own, it is possible to set up a QoS-aware packet scheduler in every router (at least on the links monitored by BFD). > So the best way for us is only DSCP, I think. Indeed, I think it would improve the quality of failure detection by enabling the use of smaller timeout intervals without being prone to packet loss or delay. We plan to test this solution within a couple of weeks, and I will assemble a patch if we found it useful in practice. Regards, Peter |
|
From: Peter S. <pes...@gm...> - 2008-06-08 19:19:16
|
Hi, I have a question regarding the recently implemented BFD interval command (BFD_SETLINK). In order to change BFD timer intervals, one has to fill in a bfd_nl_linkinfo structure, and send it through the netlink socket to kbfd. How can I obtain the correct value for the ifindex field of this structure from userspace, if I have just set up a new session with a peer? All I know is the source and destination interface addresses involved in this BFD session. Thank you, Peter -- Peter Szilagyi Budapest University of Technology and Economics Project page: http://opt.tmit.bme.hu/~kbfd/ |
|
From: Hajime Tazaki<ta...@sf...> - 2008-06-07 12:50:48
|
Hi, At Sat, 7 Jun 2008 11:00:40 +0200, Peter Szilagyi wrote: > >Hi, > >Since BFD control packets are currently not favored to any other >packets on a link, heavy traffic load (e.g. streaming a video) on the >same links can trigger rapid BSM_Down/Up events leading to interface >flapping. Even if no packet loss happens, BFD control packets can be >delayed due to congestion, thus the BFD timers expire, rendering the >interface Down. As soon as the delayed packet(s) arrive, the interface >enters Up state again. > >Our idea is to set an appropriate DiffServ Code Point (DSCP) on BFD >control packets in order to prioritize them over background streams >(according to RFC4594, page 18, it should be Code Point CS6, with >value 110000). However, the most flexible solution would be to let the >user decide which Code Point to use (or none at all), and introduce >some get/set_dscp() functions which signal the user's request through >the netlink socket to the kbfd module. Prioritizing packet with DSCP is good idea, but I think that this couldn't be absolute solution, though.. But some situation is helped by this trick. BTW, I think that BFD needs some "flapping protection method" in core specification. The problem you explained might be happened in real world. The prioritizing technique doesn't work all situation, and if one box could prioritize the BFD processing with OS support or hardware assist, the intermediate node would not treat such way. The internet is always so. So the best way for us is only DSCP, I think. > >What's your opinion about the problem and the above solution? If you >know some other methods which could solve this issue, let us discuss >them. The best would be a kbfd mailing list which could stick people >interested in kbfd (and BFD on Linux in general) together. You can use "kbf...@li..." if you would like to (I'm cc-ed). >Project page: http://opt.tmit.bme.hu/~kbfd/ I look though this page. Thank you for your work! I'm always waiting for such a exciting opportunity! regards, hajime > >Best Regards, >Peter > >-- >Peter Szilagyi >Budapest University of Technology and Economics >Project page: http://opt.tmit.bme.hu/~kbfd/ |
|
From: Hajime Tazaki<ta...@sf...> - 2008-06-07 12:33:06
|
This is a test mail hajime |
