Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf