Re: [rrg] Host changes vs. network changes

[Patrick Frejborg <[e-mail]>]

Hi all,

Sorry for spamming the list with a presentation but it was the fastest
and easiest way to show my findings when I checked the corner cases if
both camps are integrated into one framework.

When e.g. LISP is used between two endpoints, there is nothing new
When hIPv4 is used between two endpoints, that is described in my
draft and nothing new

Two new use cases needs to be checked, i.e.
1) legacy client with an ITR in front establishing a session to a
hIPv4 enabled server
2) a hIPv4 client establishes a session to a legacy server with an ETR in front

To better understand I need to explain some syntax, please don't throw
stones on me because it has been a hot topic for while :-)
- endpoint locator, ELOC = endpoint identifier, EID in LISP
- RLOC, as defined in LISP
- ALOC, as defined in hIPv4
So three types of locators are needed, but in the Map-server and DNS
either ALOC or RLOC is used at a time for an entry - depending upon
the status of the site, are the endpoints upgraded to hIPv4 or not.

And the xTRs could also act as MPTCP proxies :-)

This is an early brain dump, so give it hard times - but it seems to
be possible to integrated both into one framework and then the
Internet citizens do have a choice to upgrade what suits them best.

Comments?

-- patte
On Mon, Dec 7, 2009 at 10:11 PM, Joel M. Halpern <[e-mail]> wrote:
> I like the picture painted below of synergistic, incremental, flexbile
> deployment of improved behavior.
>
> However, this two-ended incentive relates to one of the things that concerns
> me about the current paths of this work.
>
> On the one hand, we are looking at a variety of tunneling mechanisms
> designed to relive the PI pressure on the core.
> One of the other important goals of most of these proposals is that they
> remove the difficulty of multihoming and changing providers (thus providing
> an incentive for enterprise cooperation / deployment.)
>
> Meanwhile, other sides of our house are looking at interesting ideas such as
> TCP Multipath support.  These techniques work most simply when the tcp
> sender and receiver have visibility to the attachment addresses of the site
> to the Internet, and the ability to select which one is used.
> All of the network based tunneling techniques I can see seem to have the
> property that in providing for multihoming and the ability to change
> providers, they remove exactly the visibility that our other hand is trying
> to utilize.
>
> There seems to be a systemic disconnect.
>
> Yours,
> Joel
>
> Shane Amante wrote:
>>
>> Scott,
>>
>> On Dec 7, 2009, at 11:06 MST, Scott Brim wrote:
>>>
>>> Excerpts from Brian E Carpenter on Mon, Dec 07, 2009 09:30:45AM +1300:
>>>>
>>>> I was thinking about commenting on this point too, but Christian
>>>> beat me to it.
>>>>
>>>> We *can* propagate changes to the numerically significant host
>>>> operating systems. It takes years, so any solution based on this
>>>> must be one with a completely incremental deployment model. One
>>>> view of the IPv6 deployment problem is that it depends on *both*
>>>> incremental deployment to all hosts *and* centralised deployment
>>>> by operators. That's the worst case, but seems inevitable for
>>>> an actual change of the IP packet format.
>>>>
>>>> So, I think that tells us that a solution that requires host stack
>>>> changes only, *or* infrastructure changes only, but not both,
>>>> is deployable.
>>>>
>>>> Personally, I wouldn't expect something called "routing research
>>>> group" to propose a strategy based 100% on host changes and 0% on
>>>> changes to the routing system. But we could conceivably propose
>>>> something based on changes to both, and that would surely be
>>>> a big mistake.
>>>
>>> Right.  And best of all is to start at both ends and work toward
>>> something good.  Do something in endpoints that helps them accomplish
>>> their goals without depending on the network.  Do something in the
>>> network that has the ability to help scale routing and addressing even
>>> assuming hosts don't change, BUT is designed so that as the hosts DO
>>> change that ability can be abandoned, and the whole system can become
>>> more streamlined.
>>
>> I *very* much agree with all of the above points!  Specifically, it's
>> critical that we develop both types of solutions as different
>> networks/domains are going to be vastly different in terms budget, staff,
>> priorities and size/scale.  For example, those with large size/scale may
>> have a significant amount of 'legacy' equipment they have to maintain "as
>> is" (or it would take [much] longer to 'upgrade' it in some form), therefore
>> they're likely to start with a network-based solution.  OTOH, those networks
>> that are green-field, planning/obligated to do host O/S upgrades and/or
>> small(er) networks may choose to start with a host-based solution.
>>
>> An analogy from a security standpoint is that hopefully most
>> administrators realize that host-based firewall solutions are superior
>> (particularly for laptops, etc. that roam outside a corporate firewall)[1];
>> however, 'legacy systems' may not [ever, or initially] support host-based
>> firewall solutions, therefore a network-based firewall is necessary to
>> provide protection to them ...
>>
>> The bottom-line is various networks (and, hosts in them) are continually
>> evolving *and* are evolving at different time-scales.
>>
>> -shane
>>
>> [1] This would be analogous to host-based ID/Loc split solutions, assuming
>> they provide adequate mobility.
>> _______________________________________________
>> rrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/rrg
>>
> _______________________________________________
> rrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/rrg
>