Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels

Robin Whittle <rw@firstpr.com.au> Fri, 15 June 2007 07:48 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6XQ-0007uB-0c; Fri, 15 Jun 2007 03:48:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6XO-0007u3-Ia for ram@iab.org; Fri, 15 Jun 2007 03:48:06 -0400
Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz6XM-0007bK-Ks for ram@iab.org; Fri, 15 Jun 2007 03:48:06 -0400
Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id A028459E4A; Fri, 15 Jun 2007 17:48:02 +1000 (EST)
Message-ID: <46724429.1040909@firstpr.com.au>
Date: Fri, 15 Jun 2007 17:47:53 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: ram@iab.org
Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels
References: <46720DED.9090608@firstpr.com.au> <1FDC4EF3-97D4-4CA7-A7EF-5012D4EA5DB8@cisco.com> <46723A5A.9000809@firstpr.com.au> <776CCBA4-FB53-4EC7-9733-C8E1F5CCC67C@cisco.com>
In-Reply-To: <776CCBA4-FB53-4EC7-9733-C8E1F5CCC67C@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

Hi Dino,

The NERD url was to save other people looking it up.

I apologise for writing:

>> My understanding of LISP may be faulty, but I thought that the IP
>> addresses which are used as locators do not come from prefixes which
>> are advertised via BGP.

I meant "addresses which are used as identifiers".

>> Therefore, to my understanding, if a host
>> in an edge network wants to send a packet to such an IP address, the
>> edge network needs a LISP ITR function in one or more routers -
>> either inside the edge network or at the border router.
> 
> The host sends to an EID, and that requires an ITR to attach locators to
> the packet. EIDs are not routable in the BGP Internet and Locators are.

With my proposal, the IP address the sending host uses as an EID is
part of a prefix which is routable via BGP on the Net.

The idea is that it gets forwarded to an ITR, one of potentially
many, which may be at the border of the sending host's edge network
but may also be somewhere in the "core" of the Net - meaning not at
the border of an edge network: a transit router or perhaps some
separate specialised ITR connected to transit and edge routers, but
not part of any edge network.

If the ITR treated the entire advertised prefix the same, such as
tunnelling all packets addressed to the BGP-advertised prefix to a
single ETR, there would be little or no benefit.  The idea is that
it can split up that prefix's address range arbitrarily, potentially
down to individual IP addresses, and tunnel each one to a different,
independently controlled, ETR.  I understand that LISP can do the
same.


>> My mention of anycast is probably wrong.  What I want to achieve is
>> multiple routers such as transit or border routers to perform the
>> ITR function, and my plan was that they would all advertise the same
>> prefix: 22.22.0.0/16.  I don't know if there is a precedent for this
>> with BGP or whether it is impossible, but anycast is a separate
>> technology which is probably not needed here.
> 
> I thought you wanted it so you can off-load a single ITR for the entire
> Internet load.

No - lots of ITRs, but with ViP there doesn't need to be an ITR in
an edge network for hosts in those networks to be able to send
packets to an IP address for which ViP mapping exists.

Without LISP- or ViP-mapping, all the packets which match a BGP
advertised prefix get forwarded to the one border router.

With a LISP- or ViP-mapped address, the ITR can tunnel the packets
to any ETR which is ready to accept them, with a different ETR per
"EID" IP address, if necessary.

>>>>      However, it would be technically possible to have the ITR
>>>>      function performed by a single-homed border router or by
>>>>      specialised router which has only a single interface which
>>>>      connects to a transit router or to any border router.
>>
>> . . .
>>
>>> Tell me what is different here than a LISP ITR running on a CE router
>>> with BGP enabled?
>>
>> There's no technical difference.  Its just that, as I understand it,
>>  with LISP, the edge network needs to run an ITR if its users are to
>> be able to send packets to LISP-mapped addresses.
> 
> The PE router at an ISP could be an ITR as well.

Yes, for both LISP and ViP.  (If anyone can think of a better name .
. . .)

Christian, I think you understand what I am trying to say.  It is
not very complex and I don't expect it is very novel.  But since I
couldn't think of anything which does exactly this, I wrote it up.

   - Robin


_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram