Re: [lisp] Comments on draft-fuller-lisp-alt-04

Scott Brim <swb@employees.org> Wed, 18 February 2009 20:14 UTC

Return-Path: <swb@employees.org>
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C943A6D5A for <lisp@core3.amsl.com>; Wed, 18 Feb 2009 12:14:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.301
X-Spam-Level:
X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 A2vsC9DztAsG for <lisp@core3.amsl.com>; Wed, 18 Feb 2009 12:14:38 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9B3F73A6ACD for <lisp@ietf.org>; Wed, 18 Feb 2009 12:14:25 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,230,1233532800"; d="scan'208";a="37510856"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2009 20:14:22 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1IKEMTp015743 for <lisp@ietf.org>; Wed, 18 Feb 2009 15:14:22 -0500
Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1IKEMc4008566 for <lisp@ietf.org>; Wed, 18 Feb 2009 20:14:22 GMT
Date: Wed, 18 Feb 2009 15:14:15 -0500
From: Scott Brim <swb@employees.org>
To: lisp@ietf.org
Message-ID: <20090218201415.GE65658@cisco.com>
Mail-Followup-To: Scott Brim <swb@employees.org>, lisp@ietf.org
References: <498C8B55.4010807@uclouvain.be> <20090218012017.GA6179@cisco.com> <20090218191816.GA26992@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20090218191816.GA26992@cisco.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral
Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2009 20:14:38 -0000

Excerpts from Vince Fuller on Wed, Feb 18, 2009 11:18:16AM -0800:
> In a separate discussion, Dino pointed-out that an ALT router may be
> running vanilla BGP and GRE with no knowledge at all of LISP. This
> may, in fact, be the common case. If so, then the ALT router will
> not know anything about the Map-Request - it will only know that the
> destination IP address (the EID) is unreachable and will simply drop
> the packet. Not clear whether it should even return an ICMP
> unreachable.

How would you make the distinction between a prefix that is
operational but not reachable, and one that just isn't operational?
Are you going to configure all intermediate ALT routers with all of
the allocated prefixes?  How is it going to know which ones are not
just allocated but operational?  Not only that, but suppose a
high-in-the-hierarchy ALT router loses all routes to a next-longer
prefix, even though that next-longer prefix is an aggregate?  How is
it going to know if all of that prefix is supposed to be operational?
This is a lot of configuration.  I think you're better off not trying
to be too smart here, and if there truly isn't a route on the ALT,
just drop the Map-Request