On 04/16/10 01:18 PM, Nicolas Williams wrote:
> I agree that if there's any way to apply the strong host multi-homed
> model in such a way that it does not result in routing loops when the
> host is actually _also_ a router, that'd be a good thing.
There are three modes here: Weak ES, Strong ES, and "source priority."
By saying "strong host," you seem to be talking about Strong ES, but I'm
not. I don't care how broken Strong ES with routing may be, because
Strong ES is already _known_ to break routing. That's uninteresting.
I'm talking about the "source priority" mode. My argument is that
there's no need at all to make source matching take precedence over
longest prefix search, regardless of whether the feature is intended to
be used with "routing." In other words there are two issues:
- Does source address match take priority over prefix length or is
prefix length checked first and then source address?
- Does the source address checking work for forwarded packets or
only for locally originated packets?
For the first question, I see no point in making source address take
priority over prefix length. Doing so does break routing protocols --
regardless of whether the local host is actually FORWARDING, it can
LISTEN to routing protocols -- including the "protocol" of static
routing. That's right; this feature even breaks static routes, by
violating the basic rules of IP interface selection.
There appears to be no need for this breakage, as checking length first
is formally equivalent: any situation you could support using
source-dominates is trivially translatable into a configuration using
normal length-first matching with source preference.
For the second question, that's where actual forwarding (what I think
you're referring to as "routing") gets involved. I think it's
substantially suboptimal to make the output interface selection
mechanism used by locally-generated packets differ from the selection
performed by IP forwarding, but I can see how code changes may have made
this distinction unavoidable.
> > But I also know when I'm failing to make progress, so if you're
> > comfortable with this, then drive on. It'll just be unusable for me.
>
> I don't see why we actually need the strong host multi-homed model +
> router functionality at the same time in any of our products, so I think
> Sowmini is on solid ground.
I don't share that view.
Note that "routing" (running routing protocols) is really quite
different from "forwarding" (receiving packets on one interface and
resending them on another, possibly based on learned routing
information). Confusing the two terms is a big part of the problem here.
The feature described is incompatible with actual routing, regardless of
whether forwarding is enabled or in use, and Sun's products have
(historically at least) supported that form of routing. For example,
see OSPF-MP -- a rather intentional Sun product that could benefit from
a source preference mechanism.
I realize that product-related issues really aren't proper on this list,
but I don't think the assertion you're making really matches either the
basis of my objections or the extant set of products.
--
James Carlson 42.703N 71.076W <[email protected]>
_______________________________________________
opensolaris-arc mailing list
[email protected]
