Re: [rrg] Host changes vs. network changes

Patrick Frejborg <> Thu, 10 December 2009 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D3EB3A68A4 for <>; Thu, 10 Dec 2009 09:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FUpNOKV6M8gs for <>; Thu, 10 Dec 2009 09:53:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 25D843A6B41 for <>; Thu, 10 Dec 2009 09:53:03 -0800 (PST)
Received: by ywh35 with SMTP id 35so22023ywh.7 for <>; Thu, 10 Dec 2009 09:52:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+AAlPPNOMuVqJQj87kcPovpN/3jfaG0tlDLmM26pvbA=; b=LEnGt+i8iyR0htmouVHY4r1gaTqlkW9kgF2y/BV1k2A5uIVeroduVNtgNMamDZ75lu 7NuCyHRvZWZ8GKovfyAVdlcAhXT1rL/xPOo+lFCRU6w0Db33uAa8zkiI3wwveX+YkQXG M7jxYp/mZIwzvfWgMq4HRVU4SlqKTQx/jEHgk=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RzmOruEcwYf9qGnqyfZ7PAL92M9rsR2sVdg5v8n3rk5GKXk1AvwYkq3NOWfrwTz3A2 vJlAxjnJ9vqkKqIwozGN8MxiSEPFOEOupUWPAb4O/mxjf4ZaxBt4EqLTlFgP1nwIEsMg O7OuuOCRsXF4+RA4PaCTF94v/8ONBjScEZGhQ=
MIME-Version: 1.0
Received: by with SMTP id g27mr360069ani.100.1260467570645; Thu, 10 Dec 2009 09:52:50 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Thu, 10 Dec 2009 19:52:50 +0200
Message-ID: <>
From: Patrick Frejborg <>
To: "Joel M. Halpern" <>,
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rrg] Host changes vs. network changes
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Dec 2009 17:53:04 -0000


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 <> 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 <> 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 <> 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
>>> _______________________________________________
>>> rrg mailing list