Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?

Patrick Frejborg <pfrejborg@gmail.com> Tue, 26 January 2010 17:49 UTC

Return-Path: <pfrejborg@gmail.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481DA3A67CC for <rrg@core3.amsl.com>; Tue, 26 Jan 2010 09:49:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level:
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-CbsEX85Mmw for <rrg@core3.amsl.com>; Tue, 26 Jan 2010 09:49:34 -0800 (PST)
Received: from mail-gx0-f227.google.com (mail-gx0-f227.google.com [209.85.217.227]) by core3.amsl.com (Postfix) with ESMTP id ABC5C3A6774 for <rrg@irtf.org>; Tue, 26 Jan 2010 09:49:34 -0800 (PST)
Received: by gxk27 with SMTP id 27so4389962gxk.7 for <rrg@irtf.org>; Tue, 26 Jan 2010 09:49:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=5qBSSm+XL37LQe69vhrsaJ30UuC4fXk/wqPHe1YtEz8=; b=g+HQabHCjmxkE5aKoYpQijHhiSSxf+qKIW1ZslaNwf8TxFCafl6JzWvRSo6YDTF1oP u9Z0iWMM3rlM56L8q4RF5F4Q4kUz1r0l9OnBdn26Xz6YNHWVr8YLgeFQl7NPb4UJYOXJ r4RLiNmKL5xe1jbsdDbV0fsSGK2cx5zzx8ia0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Wtz7oUxxPrKj7mGYTLsJseqAhsrZWA1ndjE8Rwc2V7jYnS2YbUGPRZClngZywIJR0R mOprtdFFh8JWVlZXzNYU3kgYzscic/4NZr9pe6GOjKEEw6r946wI+KAmAdELUW3T+14E CrDu05EsVIqqwa0UL5hZ34d2LRnWQlq81eoVg=
MIME-Version: 1.0
Received: by 10.100.1.8 with SMTP id 8mr10117683ana.212.1264528184041; Tue, 26 Jan 2010 09:49:44 -0800 (PST)
In-Reply-To: <4B5EDE81.5060607@firstpr.com.au>
References: <4B5904EF.5060208@firstpr.com.au> <5bc37fd41001220054x1a557517i12f1efa713d0d912@mail.gmail.com> <4B5A83C1.4020702@firstpr.com.au> <5bc37fd41001230453g5188cffdy1f3b7af6415cd77@mail.gmail.com> <4B5D7B30.20708@firstpr.com.au> <5bc37fd41001250603v4e4d3d5ck251905f02c49e4df@mail.gmail.com> <4B5DBE88.100@firstpr.com.au> <5bc37fd41001252300j25ce71fdybe60bc1316e5a4fb@mail.gmail.com> <4B5EDE81.5060607@firstpr.com.au>
Date: Tue, 26 Jan 2010 19:49:43 +0200
Message-ID: <5bc37fd41001260949k15b4b7a8nd116d5dbd44e4a32@mail.gmail.com>
From: Patrick Frejborg <pfrejborg@gmail.com>
To: Robin Whittle <rw@firstpr.com.au>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: RRG <rrg@irtf.org>
Subject: Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 17:49:36 -0000

Hi Robin,

finally got an understanding of CES, sorry for taking so long. Let see
if I got it right this time...

For a conventional host A (PA address) -> CES enabled B host:
Actually the closer the ITR functionality (DITR/PTR) is to the xDSL
routers the better the cache scales, since most likely the residential
users access the same services and the cache will not grow that much.
The more CES enabled sites a DITR/PTR has to handle the more stress it
will put on the ITR cache - so here is a dependency between
geographically distributed DITRs/PTRs and amount of CES enabled sites.
The cache scalability is all about to get the DITRs/PTRs in optimal
places.

In a nutshell, CES is all about taking out the multi-homed PI
addresses from the DFZ - transforming them into PA-addresses (RLOCs,
which are aggregated) and provide a multi-homing solution for IPv6 so
it will not further expand the size of DFZ.

Thanks for your patient and education - my sincere apologizes for
being slow on learning. But is has been useful for me, sorry for
wasting yours and Noels time.

-- patte

On Tue, Jan 26, 2010 at 2:22 PM, Robin Whittle <rw@firstpr.com.au> wrote:
> Short version:   Trying to clarify that putting an ITR function
>                 in a DSL router does not mean the DSL customer
>                 is using SPI space.  DSL etc. customers will
>                 keep using PA space, except for a few who
>                 want to multihome.
>
>                 Any existing DSL etc. customer which wants to
>                 multihome will still use their existing PA
>                 address, and get another one from another
>                 link such as WiMAX, HFC or fibre.  But then
>                 their hosts will be using SPI addresses.
>
>                 Very few home or SOHO customers will want or
>                 need portability or multihoming, since their
>                 existing service is quite reliable enough.
>
>
> Hi patte,
>
> You wrote:
>
>>> Not necessarily.  The ITR function could be in the sending host
>>> (Ivip, not LISP, except LISP-MN), or in any other router.  The packet
>>> from host-B to host-A doesn't necessarily go back through, or even
>>> near, the device which performed the ETR function on the first packet.
>>>
>>> If host-A is on a conventional address (ordinary PI or PA) then
>>> there's no need for an ITR anyway.  If it is on SPI address (Ivip -
>>> or for LISP "EID" space) then at some stage the host-B to host-A
>>> packet will be encapsulated by an ITR.  In Ivip, if there is no ITR
>>> function in host-B, then the packet may be processed by an ITR
>>> function in the  host-B's network (perhaps the same device which did
>>> the ETR function for the first packet) or a router in the ISP network
>>> (likewise - maybe the ETR was in the ISP network, rather than
>>> host-B's network).  If there is no ITR in that path, then the packet
>>> will go out of the ISP and be forwarded to the nearest DITR (Default
>>> ITR in the DFZ - which in LISP is called a Proxy Tunnel Router).
>>> That encapsulates the packet and tunnels it to the correct ETR.
>>
>> Ok, got it. An ETR has never a cache but for the returning traffic you
>> might need an ITR (could be most likely the ETR for the initiating
>> session). So, yes, there is no cache for an ETR -  the cache is always
>> on the ITR.
>
> Yes - the ITR and ETR functions are separate.  The ITR
> caches mapping  and the ETR doesn't.  Ivip ETRs don't have
> anything to do with mapping.
>
> (LISP ETRs are typically the authoritative source of
> mapping for the one or more end-user networks whose
> packets they handle - so if there are two such ETRs in
> different ISPs, both are typically authoritative for the
> mapping of this end-user network's EID prefixes, as far
> as I know.)
>
>
>>>> Think
>>>> there needs to be a cache table so that this ITR can assemble the
>>>> outer, UDP and LISP headers - the host can not know those headers
>>>> unless it is upgraded and if the host is upgraded it is no longer a
>>>> full blown CES solution.
>>>
>>> ITR functions are much the same in principle no matter where it is
>>> done.  The ITR caches mapping information, and if it doesn't have
>>> mapping for a micronet covering the destination address, say of
>>> host-A for the second packet in this example, then it sends a mapping
>>> request to get this.
>>>
>>> In Ivip, the ITR buffers the packet for a few tens of milliseconds at
>>> most, since the mapping comes quickly and reliably from a local full
>>> database query server, such as in the same ISP or end-user network.
>>>
>>> With LISP-ALT, the ITR drops the packet and sends a request into the
>>> global ALT overlay network, directly or via a local Map Resolver.
>>> The reply comes back - via the Internet.  Since this is a global
>>> network and the path in the ALT system could be longer than an RTT
>>> across the the Earth and back, the ITR does not buffer the packet.
>>> Instead, once it has received the mapping (which might take a short
>>> time, but will often be 400ms to maybe a second or so - assuming no
>>> packets are lost) then whenever the host sends another packet to the
>>> same destination, the ITR encapsulates that one - and it is tunneled
>>> to the ETR.
>>>
>>> An ITR function may be in the same box (a router or a server) as an
>>> ETR function, but the two functions don't communicate in Ivip - or as
>>> far as I know, in LISP.
>>
>> Yes, agreed and that what is what I was referring to - an ITR in front
>> of a popular server (that might be an ETR for the initiating traffic
>> from a client). But I stop using that term, instead "ITR in front of a
>> server" is the term.
>>
>> Then to the issue. If you take the CES functionality to the xDSL
>> routers you will get a lot more entries on the ITR in front of a
>> server at a popular site.
>
> No - the DSL services will still be on conventional PA
> space, as they today.  The ITRs in a popular site
> (whether they are separate devices, or ITR functions
> in the sending hosts) don't need to look up mapping or
> tunnel packets for all this plethora of packets going
> out to large numbers of these DSL PA IP addresses.
>
> The addition of an ITR function in the DSL router
> doesn't change this.  Just because a sending host has
> an ITR function, or some router in a network X has
> ITRs, doesn't mean that this host or any host in
> network X is on SPI space (EID for LISP).
>
> In my previous message I contemplated a special
> router for a SOHO situation whereby it implemented
> two ETRs, one for the DSL link and one for the HFC
> cable link.  Then, the hosts on that SOHO network
> would be on SPI addresses, since this is now a
> multihomed end-user network.
>
> ITRs in busy server sites will be tunneling packets
> to such hosts - to whatever hosts are on SPI addresses.
>
> Ordinary home and SOHO users are probably fine with
> their current PI space.  So I am not suggesting that
> they adopt SPI space either for portability or for
> multihoming and/or inbound TE.
>
> However, there will be hosts in many end-user networks
> which do have SPI space, such as those of larger
> businesses and other organisations which need
> portability and/or multihoming.  So a significant
> proportion of packets transacted across the DFZ will
> be for SPI addresses - they will be tunneled across
> the DFZ.
>
> TTR mobility involves each mobile host having at least
> one IPv4 address, which would be a single micronet -
> or an IPv6 /64.   This is SPI space.  I am sure that in
> the future, most Internet hosts will be hand-held mobile
> devices (probably most on IPv6) and I believe the TTR
> Mobility architecture is the only one which can provide
> global mobility of these addresses, no matter where the
> MN is connected, including behind NAT.
>
> So this will be a lot of hosts on SPI addresses and in
> general, in the long-term future, any busy web-site or
> hosting company etc. is likely to be sending out a lot
> of its packets addressed to SPI addresses and therefore
> which will be tunneled to ETR addresses.
>
> For most DSL, fibre, WiMAX etc. mass-market non-
> physically-mobile customers, I believe the existing PI
> space arrangements will remain just fine.
>
>> The reason is that the xDSL prefixes are
>> quite well aggregated in today's DFZ. But once you apply the CES
>> solution on the xDSL router it will carve up the aggregated (PA)
>> prefixes on the ITR in front of popular servers.
>
> This is not the case.  I hope my explanation above
> makes this clear.
>
>> E.g. if an ISP uses today a /20 aggregate for their xDSL connections
>> and the residential users are allocated /29 prefixes for their
>> networks. If the residential users would deploy a CES solution in
>> their xDSL routers you will have lot more entries in the ITR in front
>> of popular servers - in the current architecture you have only /20
>> entry in the FIB but in the CES architecture you can't predict how
>> many entries you will have in the FIB - it depends if, when and how
>> many xDSL users are accessing your server. And if your site is very
>> popular do you need more FIB entries than today's router do have, just
>> in case the CES solution gets very popular and deployed very close to
>> the edge?
>>
>> This is my concern and the reason why I think a CES solution also
>> should include a CEE approach.
>>
>> Or do I still miss something?
>
> Yes.  Most DSL etc. customers will remain just as they
> are today.  Putting an ITR in their DSL router is just
> to save on the cost of the alternative - putting an ITR
> in the ISP network (or not having such an ITR, and letting
> the packets go out to a DITR in the DFZ).
>
> Having an ITR function is to handle packets these DSL hosts
> send to other hosts which are on SPI addresses.  It does not
> necessarily mean that the DSL service or the hosts behind
> its router are using SPI addresses.
>
>  - Robin
>
>
>