Re: [rrg] Host changes vs. network changes

[Patrick Frejborg <[e-mail]>]

Hi all,

played around a little bit with this and had to update the
presentation...throwing another early brain dump on the table...

The reason is - what if the ALT network is the current DFZ????

Then early adapters could start to build their own ALOC realms, find
peering partners and once in place start to move their customers from
DFZ to their ALOC realm. This would give the early adapters an
advantage, once they have completed their transition of customers they
control the size of their RIB and do not need to pay for a possible
upgrade of FIBs in the DFZ zone.
The ALOC realm might be build by introducing another address-family or
by using MPLS VPN L3 address-family during the transition phase.

The DFZ would slowly implode - which I think is the main goal :-)

I hope the RRG-team can consider this approach during the evaluation
of proposals - unfortunately I have no time to update my draft at the
moment, sorry.

-- patte

On Wed, Dec 9, 2009 at 3:58 AM, Patrick Frejborg <[e-mail]> wrote:
> 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
>>
>