Re: [rrg] Host changes vs. network changes

[Patrick Frejborg <[e-mail]>]

Hi,

after one nights sleep and looking on it again I noticed a flaw in the
diagrams. The MPTCP subflow can not be initiated/terminated on
different ITRs/ETRs, it must be assembled/disassembled on the same
endpoint (xTR).

-- patte

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