On 2008-01-11 10:23, Tony Li wrote: > >> Correct. And that is a significantly harder problem than multihoming >> for an enterprise network that only has one point of interconnection >> to the outside. > > > Our job is to solve the hard problems, not just the easy ones.
Yes, of course - I was attempting to agree with you that we must not ignore this case. > > >>> Optimal routing implies that there will be different locator >>> preferences for different hosts. Mobility within the >>> organization itself implies that creating and maintaining meaningful >>> identifier prefixes is going to prove challenging. >> >> Indeed it is challenging, so why bother? > > > Because our job is to fix the routing and addressing architecture. OK, I was too telegraphic. I don't believe that mobility that preserves a global routing prefix is a requirement. [Discussion of the value of Mobile IP elided.] I do mean global - there are certainly scenarios where mobile prefixes are a requirement, but those won't be prefixes that ever need to be in the public Internet, so they aren't part of what I thought we were discussing here. > > >> Having roamed around that >> organization pretty widely over ten years, and roamed around it >> virtually by remote VPN on a daily basis, I never had or needed >> a meaningful prefix beyond 9/8. Internal servers, otoh, don't roam. >> Externally visible servers aren't even in Net 9, because of various >> techniques for security, load balancing, and traffic management. > > > I'd say that's an admission (ok, Yet Another Admission) that the routing > & addressing architecture isn't working. When a site needs multiple > prefixes for whatever reason, that's a problem that we should solve. Actually I suspect that when you analyze *why* IBM's public web servers aren't in Net 9, it will turn out to be because they need RLOCs but Net 9 addresses behave like EIDs. So yes, I didn't mean to imply that everything is hunky-dory. > >> Certainly I'd expect EID space for large enterprises to be sliced >> and diced down to the geographical-site or even server-farm level. >> I don't think it's necessary down to host level. > > > Why not? That seems like a fairly arbitrary architectural decision. Well, it's not so much a decision as a prediction of likely operational practice... YMMV. > > >>> In other words, I think that we need host level granularity in the >>> mapping function. >> >> I'd prefer to say: we need to support arbitrary granularity, but the >> normal level will remain as a site (for some definition of site). > > > The distinction here escapes me (unless you're already thinking > mechanisms). See previous comment - I think we need an architecturally general solution but the scaling target is a matter of prediction. > > >>> I *don't* think that we need per-interface granularity, as the >>> semantics of an identifier should be host-specific, not identifier >>> specific. > > > Oops. s/identifier specific/interface specific/ > > >> I hope that's right, but since you can't tell by looking at two IP >> addresses if they refer to two interfaces on the same host, it's >> unenforcable. > > > Fair, but we needn't architect to assume interface specificity either. We agree on that. Brian -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
