References: <[EMAIL PROTECTED]
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> <EA339852-22A4-477D-9420-A2D2F6
[EMAIL PROTECTED]>
Subject: RE: [RRG] Comments on draft-lewis-lisp-interworking
Date: Mon, 24 Mar 2008 20:32:27 -0700
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[EMAIL PROTECTED]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AciOJKGG6X5KILJPSuiq+8W4q4NJ9wAA8fLA
Authentication-Results: sj-dkim-3; [EMAIL PROTECTED];
dkim=neutral
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 25 Mar 2008 03:32:31.0204 (UTC)
FILETIME=[DB791240:01C88E28]
Hi again Dino,
|I am saying there are multiple ways to go. You could have a LISP site
|that does NAT even when there are PTRs deployed.
|
|But when the LISP site sources packets, it's one type of
|address, that
|is the source address of the packet that is put on the CE-PE link. So
|when a LISP site talks to another LISP site, that source
|address is an
|RLOC from the ISPs block. When that same LISP site is sending
|to a non-
|LISP site, the ITR can translate it's source address to the same RLOC
|as in the LISP-to-LISP case.
Ok, I'm fine with that. You're effectively shifting to a NAT
approach for
transition. If you do that, do you even need PTRs anymore?
Well you know the knee-jerk reaction to NATs.
|Well, I'll ask you the same thing I ask Yakov, give me an alternative
|that has a lower cost of deployment.
I'm not out to optimize for the lower cost of deployment. That's a
price
that we pay once. I'm much more concerned with having the right end-
goal.
A cheap deployment of a lousy end-goal isn't worth it in the first
place.
I don't think "deployment" is binary. It is continual, and as the
scale increases, costs could be more.
Agree, on the end-goal. But as you might know, I think we have a
decent one when all things are considered. We don't have perfection
but I don't think we can.
Dino
--
to unsubscribe send a message to [EMAIL PROTECTED] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
