Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept
"Templin, Fred L" <Fred.L.Templin@boeing.com> Fri, 16 January 2009 16:03 UTC
Return-Path: <lisp-bounces@ietf.org>
X-Original-To: lisp-archive@ietf.org
Delivered-To: ietfarch-lisp-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98F328C25C; Fri, 16 Jan 2009 08:03:57 -0800 (PST)
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 579363A6823; Thu, 15 Jan 2009 10:48:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.118
X-Spam-Level:
X-Spam-Status: No, score=-6.118 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 tiPevTw0QMWF; Thu, 15 Jan 2009 10:48:41 -0800 (PST)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 3DB093A6774; Thu, 15 Jan 2009 10:48:41 -0800 (PST)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n0FImHl4028153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 10:48:21 -0800 (PST)
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 n0FImHsd013430; Thu, 15 Jan 2009 10:48:17 -0800 (PST)
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 n0FImF5Z013349; Thu, 15 Jan 2009 10:48:17 -0800 (PST)
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); Thu, 15 Jan 2009 10:48:16 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 15 Jan 2009 10:48:15 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1056E76B6@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rrg] No liveness requirement in the ID/Loc Split concept
Thread-Index: Acl3QPrVUmF2Ehb1QAOVLgoB8peYCQAAGgBg
References: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com>
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Fleischman, Eric" <eric.fleischman@boeing.com>, lisp@ietf.org
X-OriginalArrivalTime: 15 Jan 2009 18:48:16.0488 (UTC) FILETIME=[D3B00E80:01C97741]
X-Mailman-Approved-At: Fri, 16 Jan 2009 08:03:57 -0800
Cc: rrg@irtf.org
Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: lisp-bounces@ietf.org
Errors-To: lisp-bounces@ietf.org
Eric, >-----Original Message----- >From: Fleischman, Eric >Sent: Thursday, January 15, 2009 10:42 AM >To: lisp@ietf.org >Cc: rrg@irtf.org >Subject: [rrg] No liveness requirement in the ID/Loc Split concept > >Coworkers, > >In response to the draft-meyer-loc-id-implications-00.txt I-D, I sent >private observations to the authors of that I-D together with a small >subset of interested parties. Somebody (Dave Meyer??) requested that >this private dialog should rather be moved to this email list for >participation of the larger community. Towards that end, I would like to >summarize the view from my knothole about the RLOC/EID split issue to >this list: > >1) Routing systems using RLOCs naturally reference RLOCs for routing >aggregation. Every network system that I have worked with except for IP >(e.g., OSI, SNA, BSC, XNS, etc.) instead does routing on EIDs. These >latter systems do not recognize RLOCs. > >2) In historic IP, IP addresses became semantically overloaded with both >RLOC and EID semantics. I surmise that the IP designers originally >thought they were doing EIDs like every other protocol then existing but >they actually invented RLOCs, without recognizing the implications of >the difference. Regardless, both semantic concepts became located within >the IP layer. In practice this meant that EIDs were not operative for IP >routing at all: EID is usually NULL for traditional IP routing; EID >primarily semantically appears for protocols operating above the IP >layer, causing cross-layer protocol dependencies in such systems. > >3) IP combined the RLOC and EID concepts into a single system that >lacked the ability to disambiguate between them. Consequently, some >systems (e.g., routing) presumed that they were talking with an RLOC and >other systems presumed that they were talking with an EID. The IP system >didn't provide any assurance that either reference or presumption was >actually the case (e.g., anycast). This became known as the "IP identity >problem", which is a fundamental and pervasive security flaw within IP >systems that is solved by the RLOC/EID split concept (e.g., HIP). Within >historic IP we either locate something without identifying it or else we >identify it without locating it. This provides the foundation for >"Rekhter's Law". That we cannot authoritatively know which reference is >operative provides the foundation for the "IP identity problem". > >4) Multihoming is an EID concept. EID-based routing systems naturally >and transparently support multihoming. RLOC-based routing systems cannot >naturally support multihoming because they lack the information to be >able to naturally recognize the occurrence of multihoming. > >5) In RLOC/EID separation systems like HIP, the RLOC and EID each occurs >on different layers of the protocol stack. Therefore, attempting to get >IP routing, which works on the IP layer (i.e., RLOC layer) to be aware >of multi-homing, which occurs on the EID layer (i.e., the session layer >within HIP), is a protocol layer violation. > >6) IP routing is not equipped to natively be able to do multi-homing and >attempts to enhance it to do so further complicate the RLOC-EID >confusion and actively harm the Internet. Attempting to enhance routers >to handle multi-homing inherently violates the loc/ID split concept. The >desired distinction between EID and RLOC needlessly becomes replaced by >mutual dependencies between the two concepts. By adding EID dependencies >to RLOC, there cannot be "better aggregation in the RLOC space" because >no RLOC space can exist. Rather, that space potentially becomes EID*RLOC >space, which probably represents significantly worse aggregation than >the historic IP routing system. > >7) The RLOC-EID split concept therefore means that multihoming needs to >be solved at a layer above the IP layer that can naturally see the EID. >Attempts to simultaneously achieve a Loc/Id split and have routing doing >multihoming are vectors that internally war with each other. The net >result are the types of problems identified in >draft-meyer-loc-id-implications-00.txt, problems that cannot occur if >the RLOC-EID distinction is done properly (i.e., RLOC and EID at >different layers of the protocol stack). > >8) When RLOC-EID is done properly (e.g., like HIP where each concept >appears on a different layer of the protocol stack), there is no >liveness problem (nor can there be one). Rather, the "liveness problem" >described in draft-meyer-loc-id-implications-00.txt is a generic problem >of map-and-encaps systems, not of RLOC-EID. The title and text of >draft-meyer-loc-id-implications-00.txt is therefore inappropriately >scoped as being caused by RLOC-EID when it is rather a common attribute >of map-and-encaps. Note that LISP is a map-and-encaps system. > >9) It is useful to discuss both map-and-encaps and multihoming from the >insights contained within Fred Templin's VET/RANGER/SEAL I-D trilogy. >This trilogy discusses scalable map-and-encaps systems and indicates how >to resolve the liveness problem for those systems. It also provides an >important context for describing multihoming because it identifies the >recursive nature of the "enterprise" concept. Without leveraging the >insights of this trilogy, multihoming may appear to mean different >things in different contexts: Autonomous systems can be multihomed. >Mobile platforms can be multihomed. Hosts can be multihomed. Etc. These >different environments are recursive instances to different sized >"enterprise" entities. Failing to realize this complicates discussions >about multi-homing. FWIW, this is completely consistent with the latest version of VET that I have just posted: http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-27.txt but I think you will find that the new version is much more comprehensive in terms of PI addressing, site multi-homing, ingress filtering, routing scaling suppression, MTU robustness, locator liveness determination, etc. etc.) Thanks - Fred fred.l.templin@boeing.com > >--Eric > > >_______________________________________________ >rrg mailing list >rrg@irtf.org >http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
- Re: [lisp] [rrg] No liveness requirement in the I… David Meyer
- Re: [lisp] [rrg] No liveness requirement in the I… Scott Brim
- Re: [lisp] [rrg] No liveness requirement in the I… Scott Brim
- Re: [lisp] [rrg] No liveness requirement in the I… Scott Brim
- Re: [lisp] [rrg] No liveness requirement in the I… Robin Whittle
- [lisp] No liveness requirement in the ID/Loc Spli… Fleischman, Eric
- Re: [lisp] [rrg] No liveness requirement in the I… Templin, Fred L
- Re: [lisp] [rrg] No liveness requirement in the I… marcelo bagnulo braun
- Re: [lisp] [rrg] No liveness requirement in the I… Fleischman, Eric
- Re: [lisp] [rrg] No liveness requirement in the I… marcelo bagnulo braun
- Re: [lisp] [rrg] No liveness requirement in the I… Fleischman, Eric
- Re: [lisp] [rrg] No liveness requirement in the I… Noel Chiappa