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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
