On Apr 15, 2009, at 7:11 AM, Bernie Volz (volz) wrote:
How realistic is that most RGs with multiple interface will connect to
DIFFERENT service providers? And, in the case where they do, this
likely
means someone (the owner of the RG) has to make some decisions --
requiring appropriate configuration.
(Apologies in advance for being so long-winded - I think the
conclusion I reached at the bottom is interesting, and I didn't
realize I was going to reach it until I walked through the line of
reasoning I'm long-windedly including here, so I feel like it's worth
sharing that line of reasoning in case it helps someone else to get to
the same conclusion.)
The only scenario that springs to mind for me is something like the
Kyocera cellular data gateway, only with a WiFi outward-facing port as
well. It might connect opportunistically to open WiFi networks and
also roam to 3G networks that cost more or less.
The primary problem is, how do we figure out which outgoing route to
prefer? Obviously we want to use the cheap connection; how do we
know it's cheap? It may be that the primary cellular data network is
free, whereas roaming is not, and we would have to know that somehow.
But the secondary problem is the killer: we're advertising prefixes.
The routing decision is really made by the client, when it chooses the
source address. Even if the gateway always routes the packet out the
cheap port, it's going to come back on the port corresponding to the
prefix the client chose. And you probably can't do that because
there's probably egress filtering on the cheap prefix anyway.
Bear in mind that I'm using the routing scenario as an *analogy* for
what to do with the container option. I'm not a routing expert, and
I'm not proposing new routing protocols to solve this problem. What
I *am* saying is that in this analogy the client has to decide, and
it's crucial that the client make a good decision here. And I think
the analogy applies perfectly to the container option. So if we want
to solve this problem, we have to solve it in such a way that the
*client* has enough information to make a good decision, even though
it's the RG that's actually *getting* the container options.
I should say that in IPv4, the question is moot, because there's no
way to even give the client an opportunity to make this decision.
And to circle back around to my original point, I'd just like to point
out that the scenario I just came up with is brutally contrived.
Nobody actually makes devices like the Kyocera cellular data gateway
that *also* have a second outward-facing WiFi interface, and I think
there's a good reason nobody does - it's not a good idea.
So although I was able to contrive a scenario where we have a real
problem that needs to be solved, I don't think that scenario would
happen in real life. I think in real life Bernie's scenario is the
right model. You have a static gateway, set up to be multihomed by
someone who knows what they are doing. They manually configure it as
to what decision it should make regarding information it gets from
multiple DHCP servers.
So to me, the interesting problem is really how that RG handles the
vicissitudes of daily life for a router - links, which are expected to
be persistent, going up and down, and what to do with the container
options received on those links when they go up and down.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf