Date: Wed, 30 Apr 2008 11:47:32 -0700 From: Julian Elischer <julian@elischer.org> To: Bruce M Simpson <bms@incunabulum.net> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Kevin Oberman <oberman@es.net> Subject: Re: multiple routing tables review patch ready for simple testing. Message-ID: <4818BEC4.7060800@elischer.org> In-Reply-To: <4818B58B.3050400@incunabulum.net> References: <20080429185100.57C2445010@ptavv.es.net> <4817743B.6090107@elischer.org> <48178452.4050700@FreeBSD.org> <4817881B.7010409@elischer.org> <4818926F.8010309@incunabulum.net> <4818AB9F.7000607@elischer.org> <4818B58B.3050400@incunabulum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce M Simpson wrote: > Julian Elischer wrote: >> >> what's SSM? > > Source-specific multicast, where multicast flows (channels) are > identified by both their original source address, and group address. > Multicast addresses have no meaning on their own beyond the scope of a > single link. > >> I haven't changed any of that.. Basically I've kept clear of >> M/Cast. The way I see it, if you don't define ROUTETABLES=2 (or more) >> or don;t define it at all in your config then you get what you had >> before and I shouldn't have broken anything. > > Cool! Doing multicast "right" is Hard. Doing it "right" in ad-hoc > topologies is Harder. > > It makes sense to steer clear of it for now. It can no doubt benefit > from the hierarchy offered by multiple FIBs, but again, the policy > routing mechanisms don't really exist just now, and things like PIM need > changes to encompass it. > > They will need to come into existence for the model to work on a macro > scale, for the same reason SSM was put on the table. > >> >> I take it from this that you don't have any major complaints >> as far as what I've done. > > No problems here... I haven't tried testing. please please do.. just apply the patch to a regular source tree and compile.. :-) > > I would say though if we are going to be renaming rtalloc() and friends, > that names should really change to be descriptive of what it does. > It doesn't "allocate a route", it tries to look up a forwarding table > entry, and returns a reference to it. It's important to not break source compatibility for 3rd party suppliers and users. (e.g. ironport, juniper, nokia, issilon, etc. etc.) they know about rtalloc... having said that I do plan on a pass over the code to rationalise some of the names that may have "evolved" during developement of the patch. > > cheers > BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4818BEC4.7060800>