Re: [rrg] RRG to hibernation

jnc@mercury.lcs.mit.edu (Noel Chiappa) Mon, 12 November 2012 16:02 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C3921F85B4 for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 08:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.506
X-Spam-Level:
X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNejvLbHtIWp for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 08:02:56 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id B8DFD21F84D8 for <rrg@irtf.org>; Mon, 12 Nov 2012 08:02:56 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id ECDBD18C0C3; Mon, 12 Nov 2012 11:02:54 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20121112160254.ECDBD18C0C3@mercury.lcs.mit.edu>
Date: Mon, 12 Nov 2012 11:02:54 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [rrg] RRG to hibernation
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/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: Mon, 12 Nov 2012 16:02:57 -0000

    > From: Dae Young KIM <dykim@cnu.kr>

    > the original rationale for RRG was to find a solution to mitigate the
    > DFZ routing table explosion.

That's a good point.

However, I think the routing system has more problems 'coming down the road'
(as the English expression goes) than just routing table explosion, and it
would be good to 'get out in front of them' (i.e. start working on solutions
before they become incredibly painful).

However, as _deploying_ those solutions will be considerable work, I don't
think we'll be able to deploy a solution before they do become painful (since
nobody will want to do the work unless/until it's absolutely necessary).
However, the 'routing' community could at least think about the problems, and
solutions, so that when the larger community turns to us for a solution, we
have agreed what the road forward is.


    > One might argue that LIS does not help reduce the DFZ routing table
    >  size
    > ...
    > With multiple Internet service providers(ISPs) serving your site in
    > multihoming, which PA locator sets should you load your client nodes,
    > all of them or either of them?

You don't configure nodes with locators (for all the very good reasons you
give). They are configured with identifiers.

    > How about ISP migration which is a degenerate case of multihoming? You
    > have to renumber your locators whenever you're to migrate to a
    > different ISP. Renumbering is so painful that no network managers would
    > like to do.

Which is why it is identifiers which are configured, not locators. Those are
_not_ changed when a site moves to a different ISP.

	Noel