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

jnc@mercury.lcs.mit.edu (Noel Chiappa) Tue, 26 January 2010 04:34 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
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 916DA3A681F for <rrg@core3.amsl.com>; Mon, 25 Jan 2010 20:34:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.079
X-Spam-Level:
X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 hX5FkMeR9qi9 for <rrg@core3.amsl.com>; Mon, 25 Jan 2010 20:34:09 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id C8F1B3A62C1 for <rrg@irtf.org>; Mon, 25 Jan 2010 20:34:09 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 42F116BE5D6; Mon, 25 Jan 2010 23:34:17 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20100126043417.42F116BE5D6@mercury.lcs.mit.edu>
Date: Mon, 25 Jan 2010 23:34:17 -0500
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
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 04:34:10 -0000

   > From: Patrick Frejborg <pfrejborg@gmail.com>

I should first point out that my original response was in response to, and in
the context of, your comment:

    >>> I believe that the Trojan Horse is called MPTCP

and my observations were specifically questions about MPTCP (and let me
repeat by reference my previous comments about how MPTCP is great for its
core designed functionality, and so I hope it is a success, but it does not
solve all problems).


    > I think an enterprise should have PI-addresses always, PA-addresses is
    > for residential users.

OK, I'll bite. I couldn't quickly find data on the number of companies in the
world, but there are something like 2.5 million companies with 5 or more
employees in the US. Since the EU has more people than the US, and China and
India each have more people than that (although are less economically
developed), there are probably something like 10 million non-trivial companies
worldwide.  Are you really propose dumping 10 million PI entries into the DFZ?


    > [is] a CES solution is only aimed for multi-homed solutions only?

Depends on the particular CES solution, I would think.


    > the problem is, when is a site becoming a LCP site, it is event driven,
    > isn't it? Anytime there is something happening that passes the news
    > threshold some servers are starting to get hits, depending upon the
    > nature of the news.

Sure, and sometimes a site melts down because it doesn't have enough server
capacity, or enough bandwidth, or whatever. Sites not coping well with massive
increases in traffic volumes is, I would imagine, not uncommon, and it
manifests itself in a number of ways - some of which are not easily
ameliorated (e.g. going from a single-server system to a server cluster).


    > the returning traffic doesn't need be looked up by a mapping solution,
    > it is populated by the initiating traffic

The simplistic versions of this tactic can lead to DoS attacks and/or traffic
hijacking. If you want to avoid a lookup in the return direction, you have to
authenticate 'unsolicited' bindings.

	Noel