[rrg] Map and Encaps

[Dino Farinacci]

Can HIP proxies support an IPv4 site?

Dino

On Dec 19, 2008, at 12:57 AM, Pekka Nikander wrote:

> Noel,
>
> I fully agree with your argumentation about the importance of a  
> deployment path.  I am painfully aware we did not see the issue when  
> we were developing the original HIP in 1999-2006.
>
> However, I disagree with your assessment of the present situation  
> with HIP.  The HIP proxy approach [1] is structurally very similar  
> to what you do with LISP.  From the practical point of view, you  
> just install a magic box (the HIP proxy) between your legacy IP  
> subnetwork and the rest of the network, and when there is the same  
> box at the other end, the subnetwork becomes mobile, multi-homed,  
> and reachable with IPv4, NATted IPv4, and IPv6.  (Of course, for  
> reachability you need STUN servers and/or HIP rendezvous servers,  
> depending on the exact flavour of HIP NAT traversal you use.)  When  
> there is no such box in the other end, you continue just like today  
> (or deploy some NAT-like solution towards the legacy sites).
>
> Considering your list of LISP "features", I think HIP proxy does  
> "better" than LISP does:
>
> - The current HIP proxy specs and implementation provide the use of  
> IPv4, IPv6, and even NATed IPv4 between the proxies (which are equal  
> to the xTRs in LISP).
>
> - With HIP proxies, the routers and hosts do not need to be modified  
> at all, just like with LISP.  However, the boundary can be trivially  
> moved closer to and eventually to the hosts.
>
> So, in this light, I don't understand your statement that "HIP does  
> nothing to provide us with a superior internetwork layer (including  
> a new routing architecture)".  It is true that HIP was not designed  
> with that in mind, but AFAICS, there is no real difference in this  
> respect between the present LISP approach and the HIP proxy  
> approach.  The big difference is that HIP is more "future friendly";  
> there is a clear and tested way how to make it to work in hosts.
>
> IMHO, most probably the technically best solution might be  
> achievable by combining the HIP proxy approach and the LISP  
> approach, e.g. by taking the signalling, reachability, mobility and  
> multi-homing functions from HIP and taking the mapping function and  
> routing related aspects from LISP.
>
> --Pekka
>
> [1] Patrik Salmela and Jan Melen, "Host Identity Protocol Proxy", E- 
> business and Telecommunication Networks Second International  
> Conference, ICETE 2005, Reading, UK, October 3-7, 2005. Selected  
> Papers.
>
> http://www.springerlink.com/content/m72v767465578741/
>
> On 16 Dec 2008, at 21:00, Noel Chiappa wrote:
>
>> <I know this is rather a slow reply, but it has some points at the  
>> end which
>> I really thought deserved a substantial reply...>
>>
>>> From: "Fleischman, Eric" <eric.fleischman at boeing.com>
>>> Date: Mon, 1 Dec 2008 10:45:43 -0800
>>
>>> Map-and-encaps shields the host from knowing the actual network
>>> topology such that an arbitrarily complex network topology can be
>>> created that is transparent to the end user host
>>
>> This is also true of the existing internetwork layer, though...  
>> It's an
>> interesting point as to whether this is a correct architectural  
>> choice, or
>> whether some applications want/need to be _able_ to see more (i.e.  
>> it would
>> not be mandatory, and those applications which didn't need it could/ 
>> would
>> continue in blissful ignorance, just as most applictions now don't  
>> care about
>> virtual memory) - but that's not the main point I want to go over  
>> here, so
>> I'll pass on, and leave that for another day/thread.
>>
>>
>>> I believe that map-and-encaps should solely be a network  
>>> infrastructure
>>> design alternative. To be effective, the hosts should not be aware  
>>> that
>>> map-and-encaps .. exists.
>>> .. claims such as "LISP provides an identifier-locator split" is
>>> fundamentally unrelated to the fact that HIP provides an
>>> identifier-locator split. Quite obviously, HIP does so in a manner  
>>> that
>>> is real to the host (including applications) while LISP does so in a
>>> manner that is known to routers only. [My own bias is that LISP's
>>> claims in this regard are marketing while HIP's claims are close to
>>> what the ROAD Group originally intended.]
>>
>> You've made a number of points here, both explicitly and  
>> implicitly, that I
>> want to respond to.
>>
>> Most importantly, I want to talk about your point that LISP is a  
>> router-only
>> solution, and its implication that LISP is therefore a limited  
>> solution. If
>> one is only talking about what's in LISP documents so far, that's  
>> accurate,
>> but my hopes for the long-term future of LISP - or rather, the path  
>> on which
>> LISP is but a first step - are much larger than that. (Based on  
>> discussions
>> I've had, those hopes are to some degree shared by some - perhaps  
>> many? - of
>> the people working on LISP - although each individual will no doubt  
>> have
>> varying degrees of agreement with my ideas, and I'll have let them  
>> speak for
>> themselves.) And I wouldn't have the slightest interest in working  
>> on LISP if
>> all it was, and would ever be, was a router-based M+E system using  
>> IPv4/v6.
>> Why?
>>
>> I think the past decade or so (as far back as ROAD, in some sense)  
>> has taught
>> us that replacing the internetwork layer with something superior is  
>> not easy.
>> Whether or not one believes that IPv6 is viable on an architectural  
>> level (a
>> discussion I don't want to derail into), its deployment history has  
>> made us
>> all aware that 'forklift upgrades' don't work, and that viable  
>> deployment
>> strategies for anything new have to have economic benefit for early  
>> adopters.
>>
>> In fact, I'd now say that when analyzed from a practical angle,  
>> what's _most_
>> important about any replacement piece of the internetwork  
>> architecture is not
>> how nice a design it is, but how good its deployment path is -  
>> including
>> especially the very earliest stages. I might have the world's best
>> clean-slate design, but if I don't have a deployment plan which is
>> economically feasible, it's just a very mildly interesting piece of  
>> paper.
>>
>> It is from that mindset that I look at LISP. LISP as currently  
>> documented is
>> just, to me, a first step on a longer road - but one that passes  
>> that key
>> test of 'can it take off, to start with'? I liken the problem of  
>> deploying
>> entirely new replacement subsystems (such as a new internetwork  
>> layer) to
>> rolling a snowball down a hill - unless you can start with a big  
>> enough
>> initial snowball to start with, and find a hill of the right  
>> steepness (i.e.
>> the right path for it to travel, once it starts moving), your  
>> snowball isn't
>> going to go anywhere.
>>
>> In fact, even though LISP was designed with a heavy focus on  
>> passing this
>> 'initial deployment' bar, there are still concerns that it won't  
>> make it,
>> through lack of enough compelling features for people to change. In
>> particular: i) simpler multihoming is a good feature, but people  
>> may be happy
>> with the existing expensive/unscalable solutions; ii) freeing up  
>> address
>> space (since EIDs can be allocated more densely, and the amount of  
>> address
>> space needed for RLOCs is an order of magnitude or more less than  
>> that needed
>> for end hosts) is nice, but 'tragedy of the commons' means if a  
>> site already
>> has addresses, they don't care about the new guys ('I'm all right,  
>> Jack -
>> they can NAT').
>>
>> Yes, as initially deployed, LISP is targeted at deployment in  
>> routers at the
>> edge of sites (precisely to minimize the impact on existing plant),  
>> and uses
>> existing protocols. But the concept is that, _if done right, with  
>> the right
>> hooks, and thinking forward about the future_, it can be the first  
>> step on a
>> path to something better. The exact path is way too complicated to  
>> put in
>> this margin, but here are some examples.
>>
>> - The initial spec provides for use of IPv4 between xTRs - but with  
>> a system
>> of xTRs deployed, it would be feasible to replace that inter-xTR  
>> protocol
>> with something better - a layer that e.g. recognized traffic  
>> aggregates as
>> first-class objects (so that traffic engineering would no longer  
>> have to rely
>> on routing hacks), or had built-in tools for aggregation of routing
>> information (think a hierarchy of nested areas), instead of having  
>> to have it
>> be hand-configured as now. I think we've seen that deploying new  
>> stuff like
>> this is virtually impossible _if the hosts have to understand it_ -  
>> so it
>> makes great sense to initially hide it behind a set of mapping  
>> boxes - but
>> how does one get the mapping boxes deployed to do it? Well, you  
>> have to offer
>> them some short-term benefit....
>>
>> - The initial concept is that routers and hosts would not need to be
>> modified, to make deployment feasible. (See Figure 1.) However,  
>> once there is
>> some added value to what's on the other side of the xTR, it might  
>> make sense
>> to incrementally move that boundary closer and closer to the hosts,  
>> and
>> perhaps eventually expose the hosts to the new inter-xTR protocol  
>> directly.
>> I'm not sure the xTRs would ever go away completely; as long as we  
>> have
>> unmodified hosts - which is something we _have_ to support, and  
>> support well
>> - we'll need them. However, there is at least a feasible and viable  
>> migration
>> path which allows us to eventually see a new architecture deployed.
>>
>> The key is to have this future path in mind while one is building  
>> the initial
>> snowball, as it were. For example, any identity->locator resolution  
>> system
>> needs to be able to handle mappings that map not just to IPv4/6  
>> addresses,
>> but other syntaxes as well, so it would be possible (without a great
>> headache) deploy a new locator namespace in the future.
>>
>> So far, there aren't many people, and not a lot of resources, so  
>> the future
>> can only get so much thought. Right now it has to all be focussed  
>> on getting
>> that initial snowball moving - because with that, detailed plans  
>> for the
>> future are a waste of energy...
>>
>> In any event, as I recently pointed out to a bunch of LISP people,  
>> the lesson
>> of large projects is that one can't plan it all out beforehand  
>> (even if we
>> had the resources/personnel for such an effort, which we don't),  
>> and expect
>> it to work. One has to have, as Corbato said, an ability to change  
>> course
>> based on experience, without which a large project is a ship  
>> without a rudder
>> (which, IIRC, was his simile). So the basic concept is to get  
>> something
>> rolling down the hill, and then go around the design -> implement - 
>> > deploy
>> -> gather-real-experience loop as fast as possible, while  
>> proceeding down the
>> general path to a more capable system.
>>
>>
>> As far as HIP goes, I think it's a neat concept, includes good  
>> ideas, and I
>> hope it catches on. However, two things. First, the installed-base/ 
>> evolution
>> issues are significant - while new applications can use it, HIP  
>> isn't a great
>> deal of help when dealing with legacy hosts/applications/etc.  
>> Second, HIP
>> does nothing to provide us with a superior internetwork layer  
>> (including a
>> new routing architecture).
>>
>> Please, do not take this is a smack against HIP - as I said above,  
>> I think
>> it's good, and I hope it catches on. But it is primarily a shim  
>> layer between
>> the internetwork layer and transport/application modules - and it's  
>> the
>> internetwork layer which I am interested in.
>>
>>
>> While LISP clearly doesn't provide the same degree of separation of  
>> location
>> and identity as HIP, I think it's incorrect to say any claims it  
>> makes to
>> separation of location and identity are '[purely] marketing'. LISP  
>> EIDs may
>> initially have limited location scope, but they certainly don't  
>> have global
>> location scope - and the design is the way it is for seem like good  
>> reasons:
>> the ability to work with _unmodified_ hosts and routers - needed to  
>> make that
>> initial snowball feasible. We either have to give up making EIDs  
>> purely
>> identifiers (i.e. retain some location semantics, within a local  
>> scope), or
>> else we have to modify all the internal routers at a site - and the  
>> latter is
>> a non-starter for deployment.
>>
>> LISP certainly does allow an organization to do a number of  
>> _practical_
>> things, like change its ISP without changing its host addresses -  
>> and not
>> just inside the site, but in external places as well, such as  
>> configuration
>> data on other sites (e.g. for access control).
>>
>> If LISP wasn't intended to allow _some_ degree of separation of  
>> location and
>> identity, we wouldn't have put so much time into CONS, which does  
>> nothing
>> more than... provide a mapping from identity to location! (Although  
>> I do
>> concede that in a blank-slate architecture, this function might not  
>> be
>> needed, alas, we have to deal with the deployed base/architecture  
>> we have.)
>> The fact that it's not on the front burner has a lot more to do  
>> with 'focus
>> on getting that initial snowball together' than anything else.
>>
>> LISP is certainly not the architecture I would come up with, given  
>> a clean
>> slate - but we obviously don't have the luxury of a clean slate.
>>
>> 	Noel
>> _______________________________________________
>> rrg mailing list
>> rrg at irtf.org
>> https://www.irtf.org/mailman/listinfo/rrg
>>
>
> _______________________________________________
> rrg mailing list
> rrg at irtf.org
> https://www.irtf.org/mailman/listinfo/rrg