IETF Logo Mail Archive

Re: [rrg] [Re: [lisp] [ipdir] LISP WG]

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 17 March 2009 21:41 UTC

Return-Path: <Fred.L.Templin@boeing.com>
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 4FA3B3A67FA for <rrg@core3.amsl.com>; Tue, 17 Mar 2009 14:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.206
X-Spam-Level:
X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.393, 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 5mk-vkQ1pQwT for <rrg@core3.amsl.com>; Tue, 17 Mar 2009 14:41:45 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 3D0F13A67D9 for <rrg@irtf.org>; Tue, 17 Mar 2009 14:41:45 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2HLgQQY024586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 14:42:27 -0700 (PDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2HLgQsN027387; Tue, 17 Mar 2009 14:42:26 -0700 (PDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2HLgP26027341; Tue, 17 Mar 2009 14:42:26 -0700 (PDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 14:42:24 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 17 Mar 2009 14:42:23 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105B48992@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <20090317210327.GA90400@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rrg] [Re: [lisp] [ipdir] LISP WG]
Thread-Index: AcmnRMiJl2ih4OU4Qi6yAu+ac2syowAAUvaA
References: <20090317175750.9036E59EB56@mercury.lcs.mit.edu> <20090317210327.GA90400@cisco.com>
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Scott Brim <swb@employees.org>, Noel Chiappa <jnc@mercury.lcs.mit.edu>
X-OriginalArrivalTime: 17 Mar 2009 21:42:24.0770 (UTC) FILETIME=[428C1E20:01C9A749]
Cc: rrg@irtf.org
Subject: Re: [rrg] [Re: [lisp] [ipdir] LISP WG]
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, 17 Mar 2009 21:41:46 -0000

Scott,

> -----Original Message-----
> From: Scott Brim [mailto:swb@employees.org]
> Sent: Tuesday, March 17, 2009 2:03 PM
> To: Noel Chiappa
> Cc: rrg@irtf.org
> Subject: Re: [rrg] [Re: [lisp] [ipdir] LISP WG]
> 
> I have a few questions about LISP-in-the-host:

I haven't heard about LISP-in-the-host, but if we are
talking about a *pure* host (i.e., and not a router that
acts like a host) we already have a widely-deployed
mechanism for that [RFC5214][draft-templin-isatapv4].
If we are talking about a router that acts like a host,
we have VET for that [draft-templin-autoconf-dhcp].

>   - Liveness: Compare draft-meyer-loc-id-split-implications.  What
>     level in what stack discovers that packets are not getting
>     through, and deals with it?  The network layer is the only one
>     that knows what RLOCs are possible.

[RFC5214], section 7.2 covers RLOC failure detection through
negative acknowledgments, and [RFC5214], Section 8.4 covers
RLOC liveness testing through positive acknowledgements:

"7.2.  Handling ICMPv4 Errors

   ISATAP interfaces SHOULD process Address Resolution Protocol (ARP)
   failures and persistent ICMPv4 errors as link-specific information
   indicating that a path to a neighbor may have failed (Section 7.3.3
   of [RFC4861]).

...

8.4.  Neighbor Unreachability Detection

   ISATAP hosts SHOULD perform Neighbor Unreachability Detection
   (Section 7.3 of [RFC4861]).  ISATAP routers MAY perform Neighbor
   Unreachability Detection, but this might not scale in all
   environments.

   After address resolution, ISATAP hosts SHOULD perform an initial
   reachability confirmation by sending Neighbor Solicitation messages
   and receiving a Neighbor Advertisement message.  ISATAP routers MAY
   perform this initial reachability confirmation, but this might not
   scale in all environments."

>   - Goodput: is there any way for us to change to using a different
>     src/dst RLOC pair based on performance?

If there are multiple RLOCs, why not?

Fred
fred.l.templin@boeing.com

> By the way see also
>
http://www.dagstuhl.de/Materials/Files/09/09102/09102.BrimScott1.Slides.
pdf
> ("REAP or Multipath: Should We Bother?").  I'm not sure I would still
> agree with my conclusions but I believe some of the thoughts are
useful.
> _______________________________________________
> rrg mailing list
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg

v2.23.0 | Report a Bug | By Email