From jari.arkko@piuha.net Thu Dec 1 14:38:04 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B245211E80F8 for ; Thu, 1 Dec 2011 14:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omOGqZDNjfhQ for ; Thu, 1 Dec 2011 14:38:04 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 9986A11E80CA for ; Thu, 1 Dec 2011 14:38:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E9D6D2CC43 for ; Fri, 2 Dec 2011 00:38:02 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+I6gOtH-T-j for ; Fri, 2 Dec 2011 00:38:02 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id ED4D02CC31 for ; Fri, 2 Dec 2011 00:38:01 +0200 (EET) Message-ID: <4ED801C9.7040105@piuha.net> Date: Fri, 02 Dec 2011 00:38:01 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] FW: next steps on draft-ietf-lisp X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 22:38:04 -0000 Copying the WG list as well on the results of the IESG review of draft-ietf-lisp: ---- We discussed this draft on our IESG call tonight. The draft (as well as other Lisp drafts) has been very carefully reviewed by everyone on the IESG, and I think the feedback is useful. Of course there are a few misunderstandings here and there as well. There are a number of discusses (see https://datatracker.ietf.org/doc/draft-ietf-lisp/ballot/), but I think I we see a reasonable way forward. Here's what I would proposal that we do: *1) Detailed technical comments:* - Adrian Farrell's second issue in his Discuss and everything after that - Sean Turner's Discuss - Stephen Farrell's Discuss - Stewart Bryant's Discuss, second item - Ron Bonica's Discuss, items 5 and 7-8 These seem like valid technical questions that deserve at least an answer and probably in most cases a small document change. Please work on suggested edits for these. *2) Traffic cases* - Stewart Bryant's Discuss, first item Stewart has a good question about non-connection oriented traffic, such as UDP flows or even unidirectional traffic. Unless there is an obvious answer (I think not), you should add this as a case to test in Section 15. Note that Stewart is not asking you to change the protocol in anyway. *3) Applicability statements, defining the experiment, scope of the proposal* - Ron Bonica's Discuss, parts 1-4, 6, and 9 - Pete Resnick's Comment - Adrian Farrell's Discuss, first part These should be addressed by further work on Section and making it clearer what are the main issues where further testing is needed. Obviously Section 15 is already a good start on that, but my AD colleagues though that it needed some additions. Here's what I think we talked about during the call: - Section 15 should also include positive aspects to test for (Pete) - Section 15 should be clearer about the ability to connect the legacy and Lisp Internet. For instance, add this text to the end of the fourth bullet in Section 15: "Without an interworking solution, the Lisp and legacy Internet cannot communicate." (Ron) - Section 15 should say something about finding out the actual real-world effect on the need to insert more entries to the global routing table, what the impact is TCP sessions by the special treatment of first packets towards a network, the impact of making control plane dependent on data plane (Ron) - Section 15 should move to a place where it is more visible to readers of the document, right after introduction (Stewart, Adrian) *4) EID allocation* - Ralph Droms' Discuss Ralph and few other ADs have asked about EID allocation procedures, and think that some of the text in the drafts are not giving the full picture. The suggestion that we talked about in the call was to take the EID allocation discussion out from draft-ietf-lisp-alt: "EID-prefixes are expected to be allocated to a LISP site by Internet Registries" and discuss it only in draft-ietf-lisp. Obviously, the document to allocate some EID space is not yet on the publication queue. However, the base should say something about this, at least that procedures for allocating EID space for the purposes of running the early test deployments are under development. Finally, I think when that document comes to us, it should say that IANA manages the allocations, I think it is too early for the IETF to ask Internet Registries to hand out EID space. IANA can handle a reasonable number of requests, just like they do for various other number spaces. Also, we've already exchanged some e-mails about saying something about the IPv4 EID space, as it is not readily available for allocation. *5) Waiting on IANA* - My Discuss IANA has not yet done a review. I need to wait a couple of days for that. Thoughts? Comments? Did I miss anything? Jari From terry.manderson@icann.org Thu Dec 1 17:26:25 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF56211E80DE for ; Thu, 1 Dec 2011 17:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgSqf5AiRNif for ; Thu, 1 Dec 2011 17:26:25 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6280511E80BA for ; Thu, 1 Dec 2011 17:26:25 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 1 Dec 2011 17:26:25 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 1 Dec 2011 17:26:22 -0800 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: AcybL9JIMKfbY2xyRg+bVh3INXP5pAVYZQGO Message-ID: In-Reply-To: <1C585A9B-2883-487C-8ACF-0A0B4F29EAE5@juniper.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 01:26:26 -0000 After a receiving the suggestions from Yakov and John, emailing some ADs, the draft charter is as follows: Please review, and highlight any areas missed. I'd like to close this off b= y next Friday (9th Dec), and pass to our AD. The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP including any base protocol changes required to enable VPN and mobile topologies (precise operational definitions of these topologies should be left for IETF WGs focused on these technologies)= . The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for LISP and the various LISP mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on as well as the manageability and operability of LISP. Goals and Milestones Jun 2012 Forward draft-ietf-lisp-mib to the IESG Jun 2012 Forward draft-ietf-lisp-sec to the IESG Jun 2012 Forward to the IESG an operational document which should include cache management and ETR synchronization techniques (draft-ietf-lisp-deployment). Dec 2013 Publish an example cache management specification. Dec 2013 Forward to the IESG an evaluation of the security threat to cache maintenance (draft-ietf-lisp-threats) Dec 2013 Forward to the IESG a document addressing the areas which require further experimentation. Jun 2014 Evaluate the applicability and coverage for LISP from a reuse of SIDR technology. Jun 2014 Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. Jun 2014 Analyze and document the implications of LISP deployments in Internet topologies and forward to IESG for publication. Dec 2014 Re-charter or close From dino@cisco.com Thu Dec 1 22:30:54 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415811F0C35 for ; Thu, 1 Dec 2011 22:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq2dqHvK9+Nz for ; Thu, 1 Dec 2011 22:30:53 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id EDE1111E807F for ; Thu, 1 Dec 2011 22:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1315; q=dns/txt; s=iport; t=1322807325; x=1324016925; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ra3KejZyYxNyN4oRTI0HrIXBIv9vw1tgWcMLjr4uFQg=; b=WlYPGnP2ebdKz0g2tr2CgfmBHOW9gti+4T5fBF/5wfcCUf6HTMrSVDXm j9k2C9rT3z45DbW0rgdFnrKf10y3z8aUUekHxNcoAPlO5c2TpaXm0n+lH 4Y41KITY7j1XvfGFqZQAcDWYl1K2HjD6WEoevynUTiTdLIdd0F8AY0zdY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMtv2E6rRDoI/2dsb2JhbAA5CqsFgQWBcgEBAQMBEgEnPwULCxI0SQ4GNYdlmSwBnkaHbYJRYwSIKIwvkjM X-IronPort-AV: E=Sophos;i="4.71,282,1320624000"; d="scan'208";a="17332967" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 02 Dec 2011 06:28:45 +0000 Received: from sjc-vpn3-314.cisco.com (sjc-vpn3-314.cisco.com [10.21.65.58]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB26SjMV020000; Fri, 2 Dec 2011 06:28:45 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: Date: Thu, 1 Dec 2011 22:28:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2C685270-7EEE-484C-BAD0-EF4752E53020@cisco.com> References: To: Terry Manderson X-Mailer: Apple Mail (2.1251.1) Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 06:30:54 -0000 > LISP supports the separation of the IPv4 and IPv6 address space > following a network-based map-and-encapsulate scheme (RFC 1955). In > LISP, both identifiers and locators are IP addresses. In LISP, > identifiers are composed of two parts: a "global" portion that = uniquely > identifies a particular site and a "local" portion that identifies an > interface within a site. The "local" portion may be subdivided to > identify a particular network within the site. For a given identifier, > LISP maps the "global" portion of the identifier into a set of = locators > that can be used by de-capsulation devices to reach the identified > interface; as a consequence a host would typically change identifiers > when it moves from one site to another or whenever it moves from one > subnet to another within an site. Typically, the same IP address will > not be used as an identifier > and locator in LISP. This entire paragraph is so misleading and it is not documented in any = LISP specification that an identifier is composed of two parts. Also, in the LISP architecture, an EID or RLOC can be other than an IPv4 = or IPv6 address. And an EID does not need to change when a host moves from one site to = another. So, more to the point, why is this definition in the charter? Dino From terry.manderson@icann.org Thu Dec 1 22:55:58 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD241F0C6C for ; Thu, 1 Dec 2011 22:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEMWCYJatfAZ for ; Thu, 1 Dec 2011 22:55:57 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id DAF331F0C55 for ; Thu, 1 Dec 2011 22:55:57 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 1 Dec 2011 22:55:57 -0800 From: Terry Manderson To: Dino Farinacci Date: Thu, 1 Dec 2011 22:55:54 -0800 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acywu7S9OixTiEtKQ0+HqTHqzfo8qwAA7qbP Message-ID: In-Reply-To: <2C685270-7EEE-484C-BAD0-EF4752E53020@cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 06:55:58 -0000 Inherited hangover from the last charter... It can go I think. The awareness of what LISP is, and is not, is substantially different now than before - so I am happy to trim this sectio= n out. Cheers Terry On 2/12/11 4:28 PM, "Dino Farinacci" wrote: >> LISP supports the separation of the IPv4 and IPv6 address space >> following a network-based map-and-encapsulate scheme (RFC 1955). In >> LISP, both identifiers and locators are IP addresses. In LISP, >> identifiers are composed of two parts: a "global" portion that uniquely >> identifies a particular site and a "local" portion that identifies an >> interface within a site. The "local" portion may be subdivided to >> identify a particular network within the site. For a given identifier, >> LISP maps the "global" portion of the identifier into a set of locators >> that can be used by de-capsulation devices to reach the identified >> interface; as a consequence a host would typically change identifiers >> when it moves from one site to another or whenever it moves from one >> subnet to another within an site. Typically, the same IP address will >> not be used as an identifier >> and locator in LISP. >=20 > This entire paragraph is so misleading and it is not documented in any LI= SP > specification that an identifier is composed of two parts. >=20 > Also, in the LISP architecture, an EID or RLOC can be other than an IPv4 = or > IPv6 address. >=20 > And an EID does not need to change when a host moves from one site to ano= ther. >=20 > So, more to the point, why is this definition in the charter? >=20 > Dino >=20 From yakov@juniper.net Fri Dec 2 07:57:12 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DE811E8083 for ; Fri, 2 Dec 2011 07:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hN-semRtHFRp for ; Fri, 2 Dec 2011 07:57:11 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE7A11E808B for ; Fri, 2 Dec 2011 07:57:11 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTtj1NZNh6SGj8O+qxcTokzIBY0z19OYP@postini.com; Fri, 02 Dec 2011 07:57:11 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 2 Dec 2011 07:54:33 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id pB2FsPe97919; Fri, 2 Dec 2011 07:54:32 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201112021554.pB2FsPe97919@magenta.juniper.net> To: Terry Manderson In-Reply-To: References: X-MH-In-Reply-To: Terry Manderson message dated "Thu, 01 Dec 2011 17:26:22 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <93180.1322841265.1@juniper.net> Date: Fri, 2 Dec 2011 07:54:25 -0800 From: Yakov Rekhter Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 15:57:12 -0000 Terry, > After a receiving the suggestions from Yakov and John, emailing some ADs, > the draft charter is as follows: > > Please review, and highlight any areas missed. I'd like to close this off by > next Friday (9th Dec), and pass to our AD. > > The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) > rekindled interest in scalable routing and addressing architectures for > the Internet. Among the many issues driving this renewed interest are > concerns about the scalability of the routing system and the impending > exhaustion of the IPv4 address space. Since the IAB workshop, several > proposals have emerged which attempt to address the concerns expressed > there and elsewhere. In general, these proposals are based on the > "locator/identifier separation". > > The basic idea behind the separation is that the Internet architecture > combines two functions, routing locators, (where you are attached to the > network) and identifiers (who you are) in one number space: The IP > address. Proponents of the separation architecture postulate that > splitting these functions apart will yield several advantages, including > improved scalability for the routing system. The separation aims to > decouple locators and identifiers, thus allowing for efficient > aggregation of the routing locator space and providing persistent > identifiers in the identifier space. > > LISP supports the separation of the IPv4 and IPv6 address space > following a network-based map-and-encapsulate scheme (RFC 1955). In > LISP, both identifiers and locators are IP addresses. In LISP, > identifiers are composed of two parts: a "global" portion that uniquely > identifies a particular site and a "local" portion that identifies an > interface within a site. The "local" portion may be subdivided to > identify a particular network within the site. For a given identifier, > LISP maps the "global" portion of the identifier into a set of locators > that can be used by de-capsulation devices to reach the identified > interface; as a consequence a host would typically change identifiers > when it moves from one site to another or whenever it moves from one > subnet to another within an site. Typically, the same IP address will > not be used as an identifier > and locator in LISP. > > LISP requires no changes to end-systems or to most routers. LISP aims > for an incrementally deployable protocol. > > A number of approaches are being looked at in parallel in other > contexts. The IRTF RRG examined several proposals, some of which were > published as IRTF-track Experimental RFCs. > > The LISP WG is chartered to work on the LISP base protocol and any items > which directly impact LISP including any base protocol changes required to > enable VPN and mobile topologies (precise operational definitions of > these topologies should be left for IETF WGs focused on these technologies). With respect to chartering LISP WG to work on the LISP "base protocol changes required to enable VPN", if these changes have to do with enabling L2 VPNs, then such work should be done in L2VPN WG. If these changes have to do with enabling L3 VPN, then such work should be done in L3VPN WG. In both of these cases the outcome of this work could be reviewed by the LISP WG. The same should apply to work on enaling "mobile topoligies". With this in mind I propose to replace the above sentence with the following: The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP and are related to using LISP for improving Internet routing scalability. Yakov. > The working group will encourage and support interoperable LISP > implementations as well as defining requirements for alternate mapping > systems. The Working Group will also develop security profiles for LISP > and the various LISP mapping systems. > > It is expected that the results of specifying, implementing, and testing > LISP will be fed to the general efforts at the IETF and IRTF (e.g., the > Routing Research Group) that attempts to understand which type of a > solution is optimal. The LISP WG is NOT chartered to develop the final > or standard solution for solving the routing scalability problem. Its > specifications are Experimental and labeled with accurate disclaimers > about their limitations and not fully understood implications for > Internet traffic. In addition, as these issues are understood, the > working group will analyze and document the implications of LISP on > Internet traffic, applications, routers, and security. This analysis > will explain what role LISP can play in scalable routing. The analysis > should also look at scalability and levels of state required for > encapsulation, decapsulation, liveness, and so on as well as the > manageability and operability of LISP. > > > Goals and Milestones > > > Jun 2012 Forward draft-ietf-lisp-mib to the IESG > > Jun 2012 Forward draft-ietf-lisp-sec to the IESG > Jun 2012 Forward to the IESG an operational document which should > include cache management and ETR synchronization > techniques (draft-ietf-lisp-deployment). > Dec 2013 Publish an example cache management specification. > Dec 2013 Forward to the IESG an evaluation of the security threat to > cache maintenance (draft-ietf-lisp-threats) > Dec 2013 Forward to the IESG a document addressing the areas which > require further experimentation. > Jun 2014 Evaluate the applicability and coverage for LISP from a > reuse of SIDR technology. > Jun 2014 Summarize results of specifying, implementing, and testing > LISP and forward to IESG and/or IRTF. > Jun 2014 Analyze and document the implications of LISP deployments in > Internet topologies and forward to IESG for publication. > Dec 2014 Re-charter or close > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From marshall.eubanks@gmail.com Fri Dec 2 08:38:33 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0209A21F8B39 for ; Fri, 2 Dec 2011 08:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FY8La0AN61YN for ; Fri, 2 Dec 2011 08:38:32 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F94521F8B31 for ; Fri, 2 Dec 2011 08:38:32 -0800 (PST) Received: by ggnp4 with SMTP id p4so3759578ggn.31 for ; Fri, 02 Dec 2011 08:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RTOzUR494pQ1HXxQem16cBH3JVUOrQlNu78tH8RuTQc=; b=le+OHjBzKoVBgOnZJAQ/CQQQG1Ni6wzSyxpkKKNRyJs8ZLb/LM+n4dwN5rKmYFDrdG HNHfVIRgi3k3sOL42AhHnXgu0/kqtg2IZu4Mk3DK2EjRQLIV0JSX+Flrp/YGXJasQN9u DcwmdXs3vG+o7WV4t1/sYNKspEdmkuu66PzwE= MIME-Version: 1.0 Received: by 10.182.222.106 with SMTP id ql10mr2477061obc.53.1322843911666; Fri, 02 Dec 2011 08:38:31 -0800 (PST) Received: by 10.182.227.67 with HTTP; Fri, 2 Dec 2011 08:38:31 -0800 (PST) In-Reply-To: References: <1C585A9B-2883-487C-8ACF-0A0B4F29EAE5@juniper.net> Date: Fri, 2 Dec 2011 11:38:31 -0500 Message-ID: From: Marshall Eubanks To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 16:38:33 -0000 Is there (or could there be) a link outside web page that could contain auxiliary material, such as research papers, that may be produced as the work progresses ? Regards Marshall On Thu, Dec 1, 2011 at 8:26 PM, Terry Manderson wrote: > After a receiving the suggestions from Yakov and John, emailing some ADs, > the draft charter is as follows: > > Please review, and highlight any areas missed. I'd like to close this off= by > next Friday (9th Dec), and pass to our AD. > > The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) > rekindled interest in scalable routing and addressing architectures for > the Internet. Among the many issues driving this renewed interest are > concerns about the scalability of the routing system and the impending > exhaustion of the IPv4 address space. Since the IAB workshop, several > proposals have emerged which attempt to address the concerns expressed > there and elsewhere. In general, these proposals are based on the > "locator/identifier separation". > > The basic idea behind the separation is that the Internet architecture > combines two functions, routing locators, (where you are attached to the > network) and identifiers (who you are) in one number space: The IP > address. Proponents of the separation architecture postulate that > splitting these functions apart will yield several advantages, including > improved scalability for the routing system. The separation aims to > decouple locators and identifiers, thus allowing for efficient > aggregation of the routing locator space and providing persistent > identifiers in the identifier space. > > LISP supports the separation of the IPv4 and IPv6 address space > following a network-based map-and-encapsulate scheme (RFC 1955). In > LISP, both identifiers and locators are IP addresses. In LISP, > identifiers are composed of two parts: a "global" portion that uniquely > identifies a particular site and a "local" portion that identifies an > interface within a site. The "local" portion may be subdivided to > identify a particular network within the site. For a given identifier, > LISP maps the "global" portion of the identifier into a set of locators > that can be used by de-capsulation devices to reach the identified > interface; as a consequence a host would typically change identifiers > when it moves from one site to another or whenever it moves from one > subnet to another within an site. Typically, the same IP address will > not be used as an identifier > and locator in LISP. > > LISP requires no changes to end-systems or to most routers. LISP aims > for an incrementally deployable protocol. > > A number of approaches are being looked at in parallel in other > contexts. The IRTF RRG examined several proposals, some of which were > published as IRTF-track Experimental RFCs. > > The LISP WG is chartered to work on the LISP base protocol and any items > which directly impact LISP including any base protocol changes required t= o > enable VPN and mobile topologies (precise operational definitions of > these topologies should be left for IETF WGs focused on these technologie= s). > The working group will encourage and support interoperable LISP > implementations as well as defining requirements for alternate mapping > systems. The Working Group will also develop security profiles for LISP > and the various LISP mapping systems. > > It is expected that the results of specifying, implementing, and testing > LISP will be fed to the general efforts at the IETF and IRTF (e.g., the > Routing Research Group) that attempts to understand which type of a > solution is optimal. The LISP WG is NOT chartered to develop the final > or standard solution for solving the routing scalability problem. Its > specifications are Experimental and labeled with accurate disclaimers > about their limitations and not fully understood implications for > Internet traffic. In addition, as these issues are understood, the > working group will analyze and document the implications of LISP on > Internet traffic, applications, routers, and security. This analysis > will explain what role LISP can play in scalable routing. The analysis > should also look at scalability and levels of state required for > encapsulation, decapsulation, liveness, and so on as well as the > manageability and operability of LISP. > > > Goals and Milestones > > > Jun 2012 =A0 =A0Forward draft-ietf-lisp-mib to the IESG > > Jun 2012 =A0 =A0Forward draft-ietf-lisp-sec to the IESG > Jun 2012 =A0 =A0Forward to the IESG an operational document which should > =A0 =A0 =A0 =A0 =A0 =A0include cache management and ETR synchronization > =A0 =A0 =A0 =A0 =A0 =A0techniques (draft-ietf-lisp-deployment). > Dec 2013 =A0 =A0Publish an example cache management specification. > Dec 2013 =A0 =A0Forward to the IESG an evaluation of the security threat = to > =A0 =A0 =A0 =A0 =A0 =A0cache maintenance (draft-ietf-lisp-threats) > Dec 2013 =A0 =A0Forward to the IESG a document addressing the areas which > =A0 =A0 =A0 =A0 =A0 =A0require further experimentation. > Jun 2014 =A0 =A0Evaluate the applicability and coverage for LISP from a > =A0 =A0 =A0 =A0 =A0 =A0reuse of SIDR technology. > Jun 2014 =A0 =A0Summarize results of specifying, implementing, and testin= g > =A0 =A0 =A0 =A0 =A0 =A0LISP and forward to IESG and/or IRTF. > Jun 2014 =A0 =A0Analyze and document the implications of LISP deployments= in > =A0 =A0 =A0 =A0 =A0 =A0Internet topologies and forward to IESG for public= ation. > Dec 2014 =A0 =A0Re-charter or close > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From acabello@ac.upc.edu Sat Dec 3 07:46:16 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B81E21F8F5F for ; Sat, 3 Dec 2011 07:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bmuq5ukPG94G for ; Sat, 3 Dec 2011 07:46:15 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id 90E8421F8E98 for ; Sat, 3 Dec 2011 07:46:13 -0800 (PST) Received: from [192.168.2.104] (unknown [89.129.4.194]) by gw.ac.upc.edu (Postfix) with ESMTP id DBB382D000D for ; Sat, 3 Dec 2011 16:46:10 +0100 (CET) Message-Id: <153512F0-A3A8-4358-975C-C604244D83B7@ac.upc.edu> From: Albert Cabellos To: lisp@ietf.org In-Reply-To: <201112021554.pB2FsPe97919@magenta.juniper.net> Content-Type: multipart/alternative; boundary=Apple-Mail-1-1022586196 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 3 Dec 2011 16:46:09 +0100 References: <201112021554.pB2FsPe97919@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 15:46:16 -0000 --Apple-Mail-1-1022586196 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable In my humble opinion we should discuss what is the charter of this WG, =20= if someone in another WG uses/extends LISP for VPN or mobility is his/=20= her choice. This should not prevent that this WG could also work on =20 such applications, if there are enough volunteers. Further, and as Terry points out, LISP is experimental and hence, any =20= L2/L3 VPN extensions will (most likely) end up being also experimental. Given that I support the initial wording: =93The LISP WG is chartered to work on the LISP base protocol and any =20= item which directly impact LISP including any base protocol changes =20 required to enable VPN and mobile topologies (precise operational =20 definitions of these topologies should be left for IETF WGs focused on =20= these technologies).=94 Albert On 02/12/2011, at 16:54, Yakov Rekhter wrote: > Terry, > >> After a receiving the suggestions from Yakov and John, emailing =20 >> some ADs, >> the draft charter is as follows: >> >> Please review, and highlight any areas missed. I'd like to close =20 >> this off by >> next Friday (9th Dec), and pass to our AD. >> >> The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) >> rekindled interest in scalable routing and addressing architectures =20= >> for >> the Internet. Among the many issues driving this renewed interest are >> concerns about the scalability of the routing system and the =20 >> impending >> exhaustion of the IPv4 address space. Since the IAB workshop, several >> proposals have emerged which attempt to address the concerns =20 >> expressed >> there and elsewhere. In general, these proposals are based on the >> "locator/identifier separation". >> >> The basic idea behind the separation is that the Internet =20 >> architecture >> combines two functions, routing locators, (where you are attached =20 >> to the >> network) and identifiers (who you are) in one number space: The IP >> address. Proponents of the separation architecture postulate that >> splitting these functions apart will yield several advantages, =20 >> including >> improved scalability for the routing system. The separation aims to >> decouple locators and identifiers, thus allowing for efficient >> aggregation of the routing locator space and providing persistent >> identifiers in the identifier space. >> >> LISP supports the separation of the IPv4 and IPv6 address space >> following a network-based map-and-encapsulate scheme (RFC 1955). In >> LISP, both identifiers and locators are IP addresses. In LISP, >> identifiers are composed of two parts: a "global" portion that =20 >> uniquely >> identifies a particular site and a "local" portion that identifies an >> interface within a site. The "local" portion may be subdivided to >> identify a particular network within the site. For a given =20 >> identifier, >> LISP maps the "global" portion of the identifier into a set of =20 >> locators >> that can be used by de-capsulation devices to reach the identified >> interface; as a consequence a host would typically change identifiers >> when it moves from one site to another or whenever it moves from one >> subnet to another within an site. Typically, the same IP address will >> not be used as an identifier >> and locator in LISP. >> >> LISP requires no changes to end-systems or to most routers. LISP aims >> for an incrementally deployable protocol. >> >> A number of approaches are being looked at in parallel in other >> contexts. The IRTF RRG examined several proposals, some of which were >> published as IRTF-track Experimental RFCs. >> >> The LISP WG is chartered to work on the LISP base protocol and any =20= >> items >> which directly impact LISP including any base protocol changes =20 >> required to >> enable VPN and mobile topologies (precise operational definitions of >> these topologies should be left for IETF WGs focused on these =20 >> technologies). > > With respect to chartering LISP WG to work on the LISP "base protocol > changes required to enable VPN", if these changes have to do with > enabling L2 VPNs, then such work should be done in L2VPN WG. If > these changes have to do with enabling L3 VPN, then such work should > be done in L3VPN WG. In both of these cases the outcome of this work > could be reviewed by the LISP WG. > > The same should apply to work on enaling "mobile topoligies". > > With this in mind I propose to replace the above sentence with the > following: > > The LISP WG is chartered to work on the LISP base protocol and any =20= > items > which directly impact LISP and are related to using LISP for =20 > improving > Internet routing scalability. > > Yakov. > >> The working group will encourage and support interoperable LISP >> implementations as well as defining requirements for alternate =20 >> mapping >> systems. The Working Group will also develop security profiles for =20= >> LISP >> and the various LISP mapping systems. >> >> It is expected that the results of specifying, implementing, and =20 >> testing >> LISP will be fed to the general efforts at the IETF and IRTF (e.g., =20= >> the >> Routing Research Group) that attempts to understand which type of a >> solution is optimal. The LISP WG is NOT chartered to develop the =20 >> final >> or standard solution for solving the routing scalability problem. Its >> specifications are Experimental and labeled with accurate disclaimers >> about their limitations and not fully understood implications for >> Internet traffic. In addition, as these issues are understood, the >> working group will analyze and document the implications of LISP on >> Internet traffic, applications, routers, and security. This analysis >> will explain what role LISP can play in scalable routing. The =20 >> analysis >> should also look at scalability and levels of state required for >> encapsulation, decapsulation, liveness, and so on as well as the >> manageability and operability of LISP. >> >> >> Goals and Milestones >> >> >> Jun 2012 Forward draft-ietf-lisp-mib to the IESG >> >> Jun 2012 Forward draft-ietf-lisp-sec to the IESG >> Jun 2012 Forward to the IESG an operational document which should >> include cache management and ETR synchronization >> techniques (draft-ietf-lisp-deployment). >> Dec 2013 Publish an example cache management specification. >> Dec 2013 Forward to the IESG an evaluation of the security =20 >> threat to >> cache maintenance (draft-ietf-lisp-threats) >> Dec 2013 Forward to the IESG a document addressing the areas which >> require further experimentation. >> Jun 2014 Evaluate the applicability and coverage for LISP from a >> reuse of SIDR technology. >> Jun 2014 Summarize results of specifying, implementing, and =20 >> testing >> LISP and forward to IESG and/or IRTF. >> Jun 2014 Analyze and document the implications of LISP =20 >> deployments in >> Internet topologies and forward to IESG for publication. >> Dec 2014 Re-charter or close >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-1-1022586196 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

In my = humble opinion we should discuss what is the charter of this WG, if = someone in another WG uses/extends LISP for VPN or mobility is his/her = choice.  This should not prevent that this WG = could also work on such applications, if there are enough = volunteers. 

Further, and as Terry points = out, LISP is experimental and hence, any L2/L3 VPN extensions will (most = likely) end up being also experimental.

Given = that I support the initial wording:

which directly impact LISP including any base = protocol changes required to enable VPN and mobile topologies = (precise operational definitions of these = topologies should be left for IETF WGs focused on these = technologies).=94 

Albert

On 02/12/2011, at 16:54, Yakov = Rekhter wrote:

Terry,

After a = receiving the suggestions from Yakov and John, emailing some = ADs,
the draft charter is as = follows:

Please review, = and highlight any areas missed. I'd like to close this off = by
next Friday (9th Dec), and = pass to our AD.

The IAB's = October 2006 Routing and Addressing Workshop (RFC = 4984)
rekindled interest in = scalable routing and addressing architectures = for
the Internet. Among the = many issues driving this renewed interest = are
concerns about the = scalability of the routing system and the = impending
exhaustion of the = IPv4 address space. Since the IAB workshop, = several
proposals have emerged = which attempt to address the concerns = expressed
there and elsewhere. = In general, these proposals are based on the
"locator/identifier = separation".

The basic idea = behind the separation is that the Internet = architecture
combines two = functions, routing locators, (where you are attached to = the
network) and identifiers = (who you are) in one number space: The IP
address. Proponents of the separation architecture = postulate that
splitting these = functions apart will yield several advantages, = including
improved scalability = for the routing system. The separation aims = to
decouple locators and = identifiers, thus allowing for efficient
aggregation of the routing locator space and providing = persistent
identifiers in the = identifier space.

LISP supports = the separation of the IPv4 and IPv6 address = space
following a = network-based map-and-encapsulate scheme (RFC 1955). = In
LISP, both identifiers and = locators are IP addresses. In LISP,
identifiers are composed of two parts: a "global" portion = that uniquely
identifies a = particular site and a "local" portion that identifies = an
interface within a site. = The "local" portion may be subdivided to
identify a particular network within the site. For a given = identifier,
LISP maps the = "global" portion of the identifier into a set of = locators
that can be used by = de-capsulation devices to reach the = identified
interface; as a = consequence a host would typically change = identifiers
when it moves from = one site to another or whenever it moves from = one
subnet to another within = an site. Typically, the same IP address will
not be used as an identifier
and locator in LISP.

LISP requires = no changes to end-systems or to most routers. LISP = aims
for an incrementally = deployable protocol.

A number of = approaches are being looked at in parallel in = other
contexts. The IRTF RRG = examined several proposals, some of which = were
published as IRTF-track = Experimental RFCs.

The LISP WG is = chartered to work on the LISP base protocol and any = items
which directly impact = LISP including any base protocol changes required = to
enable VPN and mobile = topologies (precise operational definitions = of
these topologies should be = left for IETF WGs focused on these = technologies).

With respect to chartering LISP WG to = work on the LISP "base protocol
changes required to enable VPN", if = these changes have to do with
enabling L2 VPNs, then such work should = be done in L2VPN WG. If
these changes have to do with enabling L3 = VPN, then such work should
be done in L3VPN WG. In both of these = cases the outcome of this work
could be reviewed by the LISP = WG.

The same should apply to work on enaling "mobile = topoligies".

With this in mind I propose to replace the above = sentence with the
following:

 The LISP WG is chartered = to work on the LISP base protocol and any items
 which directly = impact LISP and are related to using LISP for improving
=  Internet routing scalability.

Yakov.

The working group will encourage and support interoperable = LISP
implementations as well = as defining requirements for alternate = mapping
systems. The Working = Group will also develop security profiles for = LISP
and the various LISP = mapping systems.

It is expected = that the results of specifying, implementing, and = testing
LISP will be fed to = the general efforts at the IETF and IRTF (e.g., = the
Routing Research Group) = that attempts to understand which type of a
solution is optimal. The LISP WG is NOT chartered to = develop the final
or standard = solution for solving the routing scalability problem. = Its
specifications are = Experimental and labeled with accurate = disclaimers
about their = limitations and not fully understood implications = for
Internet traffic. In = addition, as these issues are understood, = the
working group will analyze = and document the implications of LISP on
Internet traffic, applications, routers, and security. = This analysis
will explain = what role LISP can play in scalable routing. The = analysis
should also look at = scalability and levels of state required for
encapsulation, decapsulation, liveness, and so on as well = as the
manageability and = operability of LISP.


Goals and = Milestones


Jun 2012 =    Forward draft-ietf-lisp-mib to the = IESG

Jun 2012 =    Forward draft-ietf-lisp-sec to the = IESG
Jun 2012 =    Forward to the IESG an operational document which = should
=            include = cache management and ETR synchronization
=            techniqu= es (draft-ietf-lisp-deployment).
Dec 2013    Publish an example cache = management specification.
Dec = 2013    Forward to the IESG an evaluation of the security = threat to
=            cache = maintenance (draft-ietf-lisp-threats)
Dec 2013    Forward to the IESG a document = addressing the areas which
=            require = further experimentation.
Jun = 2014    Evaluate the applicability and coverage for LISP = from a
=            reuse = of SIDR technology.
Jun 2014 =    Summarize results of specifying, implementing, and = testing
=            LISP = and forward to IESG and/or IRTF.
Jun 2014    Analyze and document the = implications of LISP deployments in
=            Internet= topologies and forward to IESG for = publication.
Dec 2014 =    Re-charter or close

_______________________________________________
lisp mailing = list
lisp@ietf.org
https://www.ietf.org/m= ailman/listinfo/lisp
_________________________________= ______________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/lisp

= --Apple-Mail-1-1022586196-- From terry.manderson@icann.org Sun Dec 4 16:13:53 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CC921F8B27 for ; Sun, 4 Dec 2011 16:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.179 X-Spam-Level: X-Spam-Status: No, score=-106.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zga66EG2TXhq for ; Sun, 4 Dec 2011 16:13:52 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED3B21F8B2A for ; Sun, 4 Dec 2011 16:13:52 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Sun, 4 Dec 2011 16:13:48 -0800 From: Terry Manderson To: Yakov Rekhter Date: Sun, 4 Dec 2011 16:13:44 -0800 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: AcyxCw5NzlZfKQuDSXi8yZBG7/p6FQB17Gr6 Message-ID: In-Reply-To: <201112021554.pB2FsPe97919@magenta.juniper.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 00:13:53 -0000 Yakov, On 3/12/11 1:54 AM, "Yakov Rekhter" wrote: >>=20 >> The LISP WG is chartered to work on the LISP base protocol and any items >> which directly impact LISP including any base protocol changes required = to >> enable VPN and mobile topologies (precise operational definitions of >> these topologies should be left for IETF WGs focused on these technologi= es). >=20 > With respect to chartering LISP WG to work on the LISP "base protocol > changes required to enable VPN", if these changes have to do with > enabling L2 VPNs, then such work should be done in L2VPN WG. If > these changes have to do with enabling L3 VPN, then such work should > be done in L3VPN WG. In both of these cases the outcome of this work > could be reviewed by the LISP WG. >=20 I understand your point, however that doesn't seem to align with current IETF practice. I am perfectly comfortable to see the definition of operational aspects and any other work done which doesn't change the base spec handled by other work groups that specialize in such areas (VPN or mobility). This is what I discussed with the ADs. If a change is required i= n the LISP fields, packet structure, mapping system or other substrate define= d here to enable those WGs to take up such work items - then those changes should occur here. This modus operandi is the same as having IDR fix the AS0 definition, or allow BGP to carry larger payloads, for BGPSEC instead of having SIDR do it - and potentially getting it wrong. > The same should apply to work on enaling "mobile topoligies". >=20 > With this in mind I propose to replace the above sentence with the > following: >=20 > The LISP WG is chartered to work on the LISP base protocol and any item= s > which directly impact LISP and are related to using LISP for improving > Internet routing scalability. >=20 How about: The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP protocol structures or are related to using LISP for improving Internet routing scalability. Cheers Terry From yakov@juniper.net Mon Dec 5 11:32:58 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE64721F8C76 for ; Mon, 5 Dec 2011 11:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nU2BZeBNI2Ob for ; Mon, 5 Dec 2011 11:32:58 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2FE21F8BD5 for ; Mon, 5 Dec 2011 11:32:58 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTt0cVaAV+deyE5qYSQLqiXCmO/u5+daL@postini.com; Mon, 05 Dec 2011 11:32:58 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 5 Dec 2011 11:30:51 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id pB5JUoS09377; Mon, 5 Dec 2011 11:30:50 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201112051930.pB5JUoS09377@magenta.juniper.net> To: Terry Manderson In-Reply-To: References: X-MH-In-Reply-To: Terry Manderson message dated "Sun, 04 Dec 2011 16:13:44 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32224.1323113450.1@juniper.net> Date: Mon, 5 Dec 2011 11:30:50 -0800 From: Yakov Rekhter Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:32:59 -0000 Terry, > Yakov, > > On 3/12/11 1:54 AM, "Yakov Rekhter" wrote: > > >> > >> The LISP WG is chartered to work on the LISP base protocol and any items > >> which directly impact LISP including any base protocol changes required to > >> enable VPN and mobile topologies (precise operational definitions of > >> these topologies should be left for IETF WGs focused on these technologies ). > > > > With respect to chartering LISP WG to work on the LISP "base protocol > > changes required to enable VPN", if these changes have to do with > > enabling L2 VPNs, then such work should be done in L2VPN WG. If > > these changes have to do with enabling L3 VPN, then such work should > > be done in L3VPN WG. In both of these cases the outcome of this work > > could be reviewed by the LISP WG. > > > > I understand your point, however that doesn't seem to align with current > IETF practice. I am perfectly comfortable to see the definition of > operational aspects and any other work done which doesn't change the base > spec handled by other work groups that specialize in such areas (VPN or > mobility). This is what I discussed with the ADs. If a change is required in > the LISP fields, packet structure, mapping system or other substrate defined > here to enable those WGs to take up such work items - then those changes > should occur here. Ok. > This modus operandi is the same as having IDR fix the AS0 definition, or > allow BGP to carry larger payloads, for BGPSEC instead of having SIDR do it > - and potentially getting it wrong. > > > The same should apply to work on enaling "mobile topoligies". > > > > With this in mind I propose to replace the above sentence with the > > following: > > > > The LISP WG is chartered to work on the LISP base protocol and any items > > which directly impact LISP and are related to using LISP for improving > > Internet routing scalability. > > > > How about: > > The LISP WG is chartered to work on the LISP base protocol and any items > which directly impact LISP protocol structures or are related to using LISP > for improving Internet routing scalability. > How about: The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP protocol structures and are related to using LISP for improving Internet routing scalability. In addition, if work done by some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. The second paragraph is to reflect the point you made above, namely: I am perfectly comfortable to see the definition of operational aspects and any other work done which doesn't change the base spec handled by other work groups that specialize in such areas (VPN or mobility). This is what I discussed with the ADs. If a change is required in the LISP fields, packet structure, mapping system or other substrate defined here to enable those WGs to take up such work items - then those changes should occur here. Yakov. From terry.manderson@icann.org Mon Dec 5 15:47:39 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD3B21F8BB7 for ; Mon, 5 Dec 2011 15:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1AJ324Nh+wU for ; Mon, 5 Dec 2011 15:47:39 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD5B21F8BB5 for ; Mon, 5 Dec 2011 15:47:39 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 5 Dec 2011 15:47:39 -0800 From: Terry Manderson To: Yakov Rekhter Date: Mon, 5 Dec 2011 15:47:32 -0800 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: AcyzhLHYDDzFUoZHTAS3I4cPpolXiwAI4+M6 Message-ID: In-Reply-To: <201112051930.pB5JUoS09377@magenta.juniper.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 23:47:39 -0000 Yakov, On 6/12/11 5:30 AM, "Yakov Rekhter" wrote: > How about: >=20 > The LISP WG is chartered to work on the LISP base protocol and any > items which directly impact LISP protocol structures and are related > to using LISP for improving Internet routing scalability. > =20 > In addition, if work done by some other IETF WG requires changes > in the LISP base protocol or any items which directly impact LISP > protocol structures, then the LISP WG is chartered to work on such > changes. >=20 > The second paragraph is to reflect the point you made above, namely: >=20 Fine with me. The current draft now stands as: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP protocol structures and are related to using LISP for improving Internet routing scalability. =20 In addition, if work done by some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for LISP and the various LISP mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on as well as the manageability and operability of LISP. Goals and Milestones Jun 2012 Forward draft-ietf-lisp-mib to the IESG Jun 2012 Forward draft-ietf-lisp-sec to the IESG Jun 2012 Forward to the IESG an operational document which should include cache management and ETR synchronization techniques (draft-ietf-lisp-deployment). Dec 2013 Publish an example cache management specification. Dec 2013 Forward to the IESG an evaluation of the security threat to cache maintenance (draft-ietf-lisp-threats) Dec 2013 Forward to the IESG a document addressing the areas which require further experimentation. Jun 2014 Evaluate the applicability and coverage for LISP from a reuse of SIDR technology. Jun 2014 Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. Jun 2014 Analyze and document the implications of LISP deployments in Internet topologies and forward to IESG for publication. Dec 2014 Re-charter or close From terry.manderson@icann.org Mon Dec 5 15:57:15 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22661F0C7E for ; Mon, 5 Dec 2011 15:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.17 X-Spam-Level: X-Spam-Status: No, score=-106.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAeUOFgTq1cI for ; Mon, 5 Dec 2011 15:57:14 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 063BF1F0C4A for ; Mon, 5 Dec 2011 15:57:14 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 5 Dec 2011 15:57:14 -0800 From: Terry Manderson To: Albert Cabellos , "lisp@ietf.org" Date: Mon, 5 Dec 2011 15:57:11 -0800 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acyx0sA+aszKSWoBQBOipFcJVR9gmgB1tpHF Message-ID: In-Reply-To: <153512F0-A3A8-4358-975C-C604244D83B7@ac.upc.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 23:57:15 -0000 Obviously the discussion has been on-going. I have posted a latest draft. I think that draft sets a fair balance between LISP, and esuring LISP is interoperable when/if other technologies are added to it, and the other iet= f work groups that have expertise in such areas. Something that I am interested in getting the WG's opinion on is the school of thought that since the IAB routing workshop (RFC 4984) the growth of the routing system has been near predicable and linear in trend. I'm not siding with any particular viewpoint yet, except to highlight that at some stage the IAB could revise its stance if it finds itself in agreement with that observation. This may have impact on the LISP charter. Cheers Terry On 4/12/11 1:46 AM, "Albert Cabellos" wrote: > In my humble opinion we should discuss what is the charter of this WG, if > someone in another WG uses/extends LISP for VPN or mobility is his/her ch= oice. > This should not prevent that this WG could also work on such applications= , if > there are enough volunteers. > Further, and as Terry points out, LISP is experimental and hence, any L2/= L3 > VPN extensions will (most likely) end up being also experimental. > Given that I support the initial wording: > =B3The LISP WG is chartered to work on the LISP base protocol and any ite= m which > directly impact LISP including any base protocol changes required to enab= le > VPN and mobile topologies (precise operational definitions of these topol= ogies > should be left for IETF WGs focused on these technologies).=B2 > Albert >=20 > On 02/12/2011, at 16:54, Yakov Rekhter wrote: >=20 >> Terry, >>=20 >>> After a receiving the suggestions from Yakov and John, emailing some AD= s, >>> the draft charter is as follows: >>>=20 >>> Please review, and highlight any areas missed. I'd like to close this o= ff by >>> next Friday (9th Dec), and pass to our AD. >>>=20 >>> The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) >>> rekindled interest in scalable routing and addressing architectures for >>> the Internet. Among the many issues driving this renewed interest are >>> concerns about the scalability of the routing system and the impending >>> exhaustion of the IPv4 address space. Since the IAB workshop, several >>> proposals have emerged which attempt to address the concerns expressed >>> there and elsewhere. In general, these proposals are based on the >>> "locator/identifier separation". >>>=20 >>> The basic idea behind the separation is that the Internet architecture >>> combines two functions, routing locators, (where you are attached to th= e >>> network) and identifiers (who you are) in one number space: The IP >>> address. Proponents of the separation architecture postulate that >>> splitting these functions apart will yield several advantages, includin= g >>> improved scalability for the routing system. The separation aims to >>> decouple locators and identifiers, thus allowing for efficient >>> aggregation of the routing locator space and providing persistent >>> identifiers in the identifier space. >>>=20 >>> LISP supports the separation of the IPv4 and IPv6 address space >>> following a network-based map-and-encapsulate scheme (RFC 1955). In >>> LISP, both identifiers and locators are IP addresses. In LISP, >>> identifiers are composed of two parts: a "global" portion that uniquely >>> identifies a particular site and a "local" portion that identifies an >>> interface within a site. The "local" portion may be subdivided to >>> identify a particular network within the site. For a given identifier, >>> LISP maps the "global" portion of the identifier into a set of locators >>> that can be used by de-capsulation devices to reach the identified >>> interface; as a consequence a host would typically change identifiers >>> when it moves from one site to another or whenever it moves from one >>> subnet to another within an site. Typically, the same IP address will >>> not be used as an identifier >>> and locator in LISP. >>>=20 >>> LISP requires no changes to end-systems or to most routers. LISP aims >>> for an incrementally deployable protocol. >>>=20 >>> A number of approaches are being looked at in parallel in other >>> contexts. The IRTF RRG examined several proposals, some of which were >>> published as IRTF-track Experimental RFCs. >>>=20 >>> The LISP WG is chartered to work on the LISP base protocol and any item= s >>> which directly impact LISP including any base protocol changes required= to >>> enable VPN and mobile topologies (precise operational definitions of >>> these topologies should be left for IETF WGs focused on these technolog= ies). >>=20 >> With respect to chartering LISP WG to work on the LISP "base protocol >> changes required to enable VPN", if these changes have to do with >> enabling L2 VPNs, then such work should be done in L2VPN WG. If >> these changes have to do with enabling L3 VPN, then such work should >> be done in L3VPN WG. In both of these cases the outcome of this work >> could be reviewed by the LISP WG. >>=20 >> The same should apply to work on enaling "mobile topoligies". >>=20 >> With this in mind I propose to replace the above sentence with the >> following: >>=20 >> The LISP WG is chartered to work on the LISP base protocol and any ite= ms >> which directly impact LISP and are related to using LISP for improving >> Internet routing scalability. >>=20 >> Yakov. >>=20 >>> The working group will encourage and support interoperable LISP >>> implementations as well as defining requirements for alternate mapping >>> systems. The Working Group will also develop security profiles for LISP >>> and the various LISP mapping systems. >>>=20 >>> It is expected that the results of specifying, implementing, and testin= g >>> LISP will be fed to the general efforts at the IETF and IRTF (e.g., the >>> Routing Research Group) that attempts to understand which type of a >>> solution is optimal. The LISP WG is NOT chartered to develop the final >>> or standard solution for solving the routing scalability problem. Its >>> specifications are Experimental and labeled with accurate disclaimers >>> about their limitations and not fully understood implications for >>> Internet traffic. In addition, as these issues are understood, the >>> working group will analyze and document the implications of LISP on >>> Internet traffic, applications, routers, and security. This analysis >>> will explain what role LISP can play in scalable routing. The analysis >>> should also look at scalability and levels of state required for >>> encapsulation, decapsulation, liveness, and so on as well as the >>> manageability and operability of LISP. >>>=20 >>>=20 >>> Goals and Milestones >>>=20 >>>=20 >>> Jun 2012 Forward draft-ietf-lisp-mib to the IESG >>>=20 >>> Jun 2012 Forward draft-ietf-lisp-sec to the IESG >>> Jun 2012 Forward to the IESG an operational document which should >>> include cache management and ETR synchronization >>> techniques (draft-ietf-lisp-deployment). >>> Dec 2013 Publish an example cache management specification. >>> Dec 2013 Forward to the IESG an evaluation of the security threat to >>> cache maintenance (draft-ietf-lisp-threats) >>> Dec 2013 Forward to the IESG a document addressing the areas which >>> require further experimentation. >>> Jun 2014 Evaluate the applicability and coverage for LISP from a >>> reuse of SIDR technology. >>> Jun 2014 Summarize results of specifying, implementing, and testing >>> LISP and forward to IESG and/or IRTF. >>> Jun 2014 Analyze and document the implications of LISP deployments i= n >>> Internet topologies and forward to IESG for publication. >>> Dec 2014 Re-charter or close >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From terry.manderson@icann.org Mon Dec 5 16:04:59 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E735111E80AD for ; Mon, 5 Dec 2011 16:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGnD9-ZGlo16 for ; Mon, 5 Dec 2011 16:04:59 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3A71311E80AB for ; Mon, 5 Dec 2011 16:04:59 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 5 Dec 2011 16:04:59 -0800 From: Terry Manderson To: Marshall Eubanks Date: Mon, 5 Dec 2011 16:04:56 -0800 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: AcyxEOChjW7fEoNPRVmlbZ7Lp5RdPQCmc8LA Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 00:05:00 -0000 Hi Marshal, Previous charter discussions suggested that it wasn't necessary to include an outside webpage for 'further' reading, I tend to agree as outside pages (thus not tools based) tend to date really quickly if not actively maintained. That said, if there is a page that does cover _all_ [1] that auxiliary material in one place I'd be happy to look, review, and reconsider by reopening the WG discussion. [1] implementations, research papers, experimental work, additional works etc. Terry On 3/12/11 2:38 AM, "Marshall Eubanks" wrote: > Is there (or could there be) a link outside web page that could > contain auxiliary material, such as research papers, > that may be produced as the work progresses ? >=20 > Regards > Marshall >=20 > On Thu, Dec 1, 2011 at 8:26 PM, Terry Manderson > wrote: >> After a receiving the suggestions from Yakov and John, emailing some ADs= , >> the draft charter is as follows: >>=20 >> Please review, and highlight any areas missed. I'd like to close this of= f by >> next Friday (9th Dec), and pass to our AD. >>=20 >> The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) >> rekindled interest in scalable routing and addressing architectures for >> the Internet. Among the many issues driving this renewed interest are >> concerns about the scalability of the routing system and the impending >> exhaustion of the IPv4 address space. Since the IAB workshop, several >> proposals have emerged which attempt to address the concerns expressed >> there and elsewhere. In general, these proposals are based on the >> "locator/identifier separation". >>=20 >> The basic idea behind the separation is that the Internet architecture >> combines two functions, routing locators, (where you are attached to the >> network) and identifiers (who you are) in one number space: The IP >> address. Proponents of the separation architecture postulate that >> splitting these functions apart will yield several advantages, including >> improved scalability for the routing system. The separation aims to >> decouple locators and identifiers, thus allowing for efficient >> aggregation of the routing locator space and providing persistent >> identifiers in the identifier space. >>=20 >> LISP supports the separation of the IPv4 and IPv6 address space >> following a network-based map-and-encapsulate scheme (RFC 1955). In >> LISP, both identifiers and locators are IP addresses. In LISP, >> identifiers are composed of two parts: a "global" portion that uniquely >> identifies a particular site and a "local" portion that identifies an >> interface within a site. The "local" portion may be subdivided to >> identify a particular network within the site. For a given identifier, >> LISP maps the "global" portion of the identifier into a set of locators >> that can be used by de-capsulation devices to reach the identified >> interface; as a consequence a host would typically change identifiers >> when it moves from one site to another or whenever it moves from one >> subnet to another within an site. Typically, the same IP address will >> not be used as an identifier >> and locator in LISP. >>=20 >> LISP requires no changes to end-systems or to most routers. LISP aims >> for an incrementally deployable protocol. >>=20 >> A number of approaches are being looked at in parallel in other >> contexts. The IRTF RRG examined several proposals, some of which were >> published as IRTF-track Experimental RFCs. >>=20 >> The LISP WG is chartered to work on the LISP base protocol and any items >> which directly impact LISP including any base protocol changes required = to >> enable VPN and mobile topologies (precise operational definitions of >> these topologies should be left for IETF WGs focused on these technologi= es). >> The working group will encourage and support interoperable LISP >> implementations as well as defining requirements for alternate mapping >> systems. The Working Group will also develop security profiles for LISP >> and the various LISP mapping systems. >>=20 >> It is expected that the results of specifying, implementing, and testing >> LISP will be fed to the general efforts at the IETF and IRTF (e.g., the >> Routing Research Group) that attempts to understand which type of a >> solution is optimal. The LISP WG is NOT chartered to develop the final >> or standard solution for solving the routing scalability problem. Its >> specifications are Experimental and labeled with accurate disclaimers >> about their limitations and not fully understood implications for >> Internet traffic. In addition, as these issues are understood, the >> working group will analyze and document the implications of LISP on >> Internet traffic, applications, routers, and security. This analysis >> will explain what role LISP can play in scalable routing. The analysis >> should also look at scalability and levels of state required for >> encapsulation, decapsulation, liveness, and so on as well as the >> manageability and operability of LISP. >>=20 >>=20 >> Goals and Milestones >>=20 >>=20 >> Jun 2012 =A0 =A0Forward draft-ietf-lisp-mib to the IESG >>=20 >> Jun 2012 =A0 =A0Forward draft-ietf-lisp-sec to the IESG >> Jun 2012 =A0 =A0Forward to the IESG an operational document which should >> =A0 =A0 =A0 =A0 =A0 =A0include cache management and ETR synchronization >> =A0 =A0 =A0 =A0 =A0 =A0techniques (draft-ietf-lisp-deployment). >> Dec 2013 =A0 =A0Publish an example cache management specification. >> Dec 2013 =A0 =A0Forward to the IESG an evaluation of the security threat= to >> =A0 =A0 =A0 =A0 =A0 =A0cache maintenance (draft-ietf-lisp-threats) >> Dec 2013 =A0 =A0Forward to the IESG a document addressing the areas whic= h >> =A0 =A0 =A0 =A0 =A0 =A0require further experimentation. >> Jun 2014 =A0 =A0Evaluate the applicability and coverage for LISP from a >> =A0 =A0 =A0 =A0 =A0 =A0reuse of SIDR technology. >> Jun 2014 =A0 =A0Summarize results of specifying, implementing, and testi= ng >> =A0 =A0 =A0 =A0 =A0 =A0LISP and forward to IESG and/or IRTF. >> Jun 2014 =A0 =A0Analyze and document the implications of LISP deployment= s in >> =A0 =A0 =A0 =A0 =A0 =A0Internet topologies and forward to IESG for publi= cation. >> Dec 2014 =A0 =A0Re-charter or close >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From internet-drafts@ietf.org Tue Dec 6 12:21:13 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319AE1F0C67; Tue, 6 Dec 2011 12:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfp6vojkOFIL; Tue, 6 Dec 2011 12:21:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31FE1F0C50; Tue, 6 Dec 2011 12:21:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111206202112.9021.891.idtracker@ietfa.amsl.com> Date: Tue, 06 Dec 2011 12:21:12 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-alt-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:21:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Alternative Topology (LISP+ALT) Author(s) : Vince Fuller Dino Farinacci Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-alt-10.txt Pages : 30 Date : 2011-12-06 This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-alt-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-alt-10.txt From internet-drafts@ietf.org Tue Dec 6 12:35:35 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F9721F8C21; Tue, 6 Dec 2011 12:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-LXdWI8CBJ4; Tue, 6 Dec 2011 12:35:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D3E21F8669; Tue, 6 Dec 2011 12:35:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111206203534.14430.6714.idtracker@ietfa.amsl.com> Date: Tue, 06 Dec 2011 12:35:34 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ms-13.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:35:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map Server Interface Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-13.txt Pages : 19 Date : 2011-12-06 This draft describes the Maping Service for the Locator Identifier Separation Protocol (LISP), implemented by two new types of LISP- speaking devices, the LISP Map Resolver and LISP Map Server, that provides a simplified "front end" to for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map Resolvers and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers, are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-ms-13.txt From vaf@cisco.com Tue Dec 6 12:48:09 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6C01F0C35 for ; Tue, 6 Dec 2011 12:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.973 X-Spam-Level: X-Spam-Status: No, score=-3.973 tagged_above=-999 required=5 tests=[AWL=-2.266, BAYES_00=-2.599, FAKE_REPLY_C=2.012, FF_IHOPE_YOU_SINK=2.166, HTML_COMMENT_SAVED_URL=0.114, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKUUL0flt925 for ; Tue, 6 Dec 2011 12:48:05 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id BB59A1F0C71 for ; Tue, 6 Dec 2011 12:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=152748; q=dns/txt; s=iport; t=1323204485; x=1324414085; h=date:from:to:subject:message-id:mime-version; bh=u6OhLZ6nm2AXV8zws/8+JI/b+zxL+1p6Aa8UpIMTJnA=; b=ZJowiQZPXNsnPmtFszrN+mW1WFX2MSWOsplY+mcUuWFFVb2e+wEYupbR XXiHyd4RYTrClduoTLASMnd7b7j8ELlEYK8HfFoK3mvG/h5+rotBvjJgB s7cggW7Za7CGomXYfCBviQkLHTkB6pzitLbsVrXqns17mmwR+mkbyRBNV E=; X-Files: rfcdiff-alt-09-to-10.html : 144960 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQXADF+3k6rRDoJ/2dsb2JhbAA5BAaXYZF1gQiBBYFyAQEBBQEBDwEFAgESOgQCAQQiEQECAQIOARIBIRMFHQYfAgkLBweHbZVogSYBnlCHewuCSWMEiC6FYoMAg1WSQhw X-IronPort-AV: E=Sophos;i="4.71,308,1320624000"; d="html'217?scan'217,208,217";a="18093276" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 06 Dec 2011 20:48:04 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB6Km3WD011907 for ; Tue, 6 Dec 2011 20:48:03 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 22A871ADCA3B; Tue, 6 Dec 2011 12:48:03 -0800 (PST) Date: Tue, 6 Dec 2011 12:48:03 -0800 From: Vince Fuller To: lisp@ietf.org Message-ID: <20111206204802.GA34495@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Re: [lisp] I-D Action: draft-ietf-lisp-alt-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:48:09 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This version includes a number of minor changes resulting from the IESG review. rfcdiff results attached. --Vince ----- Forwarded message from internet-drafts@ietf.org ----- Date: Tue, 06 Dec 2011 12:21:12 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-alt-10.txt X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwBAFh43k4MFjoekmdsb2JhbABDql0iAQEBAQkLCwcSJ4F0AQEEAQEPAScGAQEECh4LAQIDAQIGAkAICAMBI0kFBBmHbZcIAYtyhBwBjjkHiBqDGIgyjDcBkkE X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol Errors-To: lisp-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Alternative Topology (LISP+ALT) Author(s) : Vince Fuller Dino Farinacci Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-alt-10.txt Pages : 30 Date : 2011-12-06 This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-alt-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-alt-10.txt _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ----- End forwarded message ----- --lrZ03NoBR/3+SXJZ Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="rfcdiff-alt-09-to-10.html" Content-Transfer-Encoding: quoted-printable wdiff draft-ietf-lisp-alt-09.txt draft-ietf-lisp-alt-= 10.txt 
Network Working Group                                          V. Fuller
Internet-Draft                                              D. Farinacci
Intended status: Experimental                                   D. Meyer
Expires: March 23, June 8, 2012                             =
              D. Lewis
                                                                   Cisco
                                                      September 20,
                                                        December 6, 2011

                  LISP Alternative Topology (LISP+ALT)
                       draft-ietf-lisp-alt-09.t=
xt
                       draft-ietf-lisp-alt-10=
.txt

Abstract

   This document describes a simple distributed index system to be used
   by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router
   (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)
   which holds the mapping information for a particular Endpoint
   Identifier (EID).  The MR can then query that ETR to obtain the
   actual mapping information, which consists of a list of Routing
   Locators (RLOCs) for the EID.  Termed the Alternative Logical
   Topology (ALT), the index is built as an overlay network on the
   public Internet using the Border Gateway Protocol (BGP) and the
   Generic Routing Encapsulation (GRE).  Using =
these proven protocols,
   the ALT can be built and deployed relatively quickly without any
   changes to the existing routing infrastructure.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 23,=
 June 8, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   3.  The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Routeability of EIDs . . . . . . . . . . . . . . . . . . .  9
       3.1.1.  Mechanisms for an ETR to originate EID-prefixes  . . . 10
       3.1.2.  Mechanisms for an ITR to forward to EID-prefixes . . . 10
       3.1.3.  Map Server Model preferred . . . . . . . . . . . . . . 10
     3.2.  Connectivity to non-LISP sites . . . . . . . . . . . . . . 10
     3.3.  Caveats on the use of Data Probes  . . . . . . . . . . . . 11
   4.  LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  ITR traffic handling . . . . . . . . . . . . . . . . . . . 13
     4.2.  EID Assignment - Hierarchy and Topology  . . . . . . . . . 13 14<=
/font>
     4.3.  Use of GRE and BGP between LISP+ALT Routers  . . . . . . . 15
   5.  EID-prefix Propagation and Map-Request Forwarding  . . . . . . 16
     5.1.  Changes to ITR behavior with LISP+ALT  . . . . . . . . . . 16
     5.2.  Changes to ETR behavior with LISP+ALT  . . . . . . . . . . 17
     5.3.  ALT Datagram forwarding falure . . . . . . . . . . . . . . 17
   6.  BGP configuration and protocol considerations  . . . . . . . . 19
     6.1.  Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 19
     6.2.  Sub-Address Family Identifier (SAFI) for LISP+ALT  . . . . 19
   7.  EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 20
     7.1.  Stability of the ALT . . . . . . . . . . . . . . . . . . . 20
     7.2.  Traffic engineering using LISP . . . . . . . . . . . . . . 20
     7.3.  Edge aggregation and dampening . . . . . . . . . . . . . . 21
     7.4.  EID assignment flexibility vs. ALT scaling . . . . . . . . 21
   8.  Connecting sites to the ALT network  . . . . . . . . . . . . . 23
     8.1.  ETRs originating information into the ALT  . . . . . . . . 23
     8.2.  ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 23
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
     10.1. Apparent LISP+ALT Vulnerabilities  . . . . . . . . . . . . 26
     10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 27
     10.3. Use of new IETF standard BGP Security mechanisms . . . . . 27
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     12.2. Informative References . . . . . . . . . . . . . . . . . . 29

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30

1.  Introduction

   This document describes the LISP+ALT system, used by a [LISP] ITR or
   MR to find the ETR that holds the RLOC mapping information for a
   particular EID.  The ALT network is built using the Border Gateway
   Protocol (BGP, [RFC4271]), the BGP multi-protocol extension
   [RFC4760], and the Generic Routing Encapsulation (GRE, [RFC2784]) to
   construct an overlay network of devices (ALT Routers) which operate
   on EID-prefixes and use EIDs as forwarding destinations.

   ALT Routers advertise hierarchically-delegated segments of the EID
   namespace (i.e., prefixes) toward the rest of the ALT; they also
   forward traffic destined for an EID covered by one of those prefixes
   toward the network element that is authoritative for that EID and is
   the origin of the BGP advertisement for that EID-prefix.  An Ingress
   Tunnel Router (ITR) uses this overlay to send a LISP Map-Request
   (defined in [LISP]) to the Egress Tunnel Router (ETR) that holds the
   EID-to-RLOC mapping for a matching EID-prefix.  In most cases, an ITR
   does not connect directly to the overlay network but instead sends
   Map-Requests via a Map-Resolver (described in [LISP-MS]) which does.
   Likewise, in most cases, an ETR does not connect directly to the
   overlay network but instead registers its EID-prefixes with a Map-
   Server that advertises those EID-prefixes on to the ALT and forwards
   Map-Requests for them to the ETR.

   It is important to note that the ALT does not distribute actual EID-
   to-RLOC mappings.  What it does provide is a forwarding path from an
   ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which
   holds that mapping.  The ITR/MR uses this path to send an ALT
   Datagram (see Section 3) to an ETR which then responds with a Map-
   Reply containing the needed mapping information.

   One design goal for LISP+ALT is to use existing technology wherever
   possible.  To this end, the ALT is intended to be built using off-
   the-shelf routers which already implement the required protocols (BGP
   and GRE); little, if any, LISP-specific modifications should be
   needed for such devices to be deployed on the ALT (see Section 7 for
   aggregation requirements).  Note, though, that organizational and
   operational considerations suggest that ALT Routers be both logically
   and physically separate from the "native" Internet packet transport
   system; deploying this overlay on those routers which are already
   participating in the global routing system and actively forwarding
   Internet traffic is not recommended.

   This specification is experimental, and there are areas where further
   experience is needed to understand the best implementation strategy,
   operational model, and effects on Internet operations.  These areas
   include:

   o  application effects of on-demand route map discovery

   o  tradeoff in connection setup time vs. ALT design and performance
      when using a Map Request instead of carring initial user data in a
      Data Probe

   o  best practical ways to build ALT hierarchies

   o  effects of route leakage from ALT to the current Internet,
      particularly for LISP-to-non-LISP interworking

   o  effects of exceptional situations, such as denial-of-service
      attacks

   Experimentation, measurements, and deployment experience on these
   aspects is appreciated.  While these issues are conceptually well-
   understood (e.g. an ALT lookup causes potential delay for the first
   packet destined to a given network), the real-world operational
   effects are much less clear.

   The remainder of this document is organized as follows: Section 2
   provides the definitions of terms used in this document.  Section 3
   outlines the LISP ALT model, where EID prefixes are routed across an
   overlay network.  Section 4 provides a basic overview of the LISP
   Alternate Topology architecture, and Section 5 describes how the ALT
   uses BGP to propagate Endpoint Identifier reachability over the
   overlay network and Section 6 describes other considerations for
   using BGP on the ALT.  Section 7 describes the construction of the
   ALT aggregation hierarchy, and Section 8 discusses how LISP+ALT
   elements are connected to form the overlay network.

2.  Definition of Terms

   This section provides high-level definitions of LISP concepts and
   components involved with and affected by LISP+ALT.

    Alternative Logical Topology (ALT):  The virtual overlay network
      made up of tunnels between LISP+ALT Routers.  The Border Gateway
      Protocol (BGP) runs between ALT Routers and is used to carry
      reachability information for EID-prefixes.  The ALT provides a way
      to forward Map-Requests (and, if supported, Data Probes) toward
      the ETR that "owns" an EID-prefix.  As a tunneled overlay, its
      performance is expected to be quite limited so use of it to
      forward high-bandwidth flows of Data Probes is strongly
      discouraged (see Section 3.3 for additional discussion).

    Legacy Internet:  The portion of the Intern=
et which does not run
      LISP and does not participate in LISP+ALT.

    ALT Router:  The devices which run on the ALT.  The ALT is a static
      network built using tunnels between ALT Routers.  These routers
      are deployed in a roughly-hierarchical mesh in which routers at
      each level in the topology are responsible for aggregating EID-
      prefixes learned from those logically "below" them and advertising
      summary prefixes to those logically "above" them.  Prefix learning
      and propagation between ALT Routers is done using BGP.  An ALT
      Router at the lowest level, or "edge" of the ALT, learns EID-
      prefixes from its "client" ETRs.  See Section 3.1 for a
      description of how EID-prefixes are learned at the "edge" of the
      ALT.  See also Section 6 for details on how BGP is configured
      between the different network elements.  When an ALT Router
      receives an ALT Datagram, it looks up the destination EID in its
      forwarding table (composed of EID prefix routes it learned from
      neighboring ALT Routers) and forwards it to the logical next-hop
      on the overlay network.

    Endpoint ID (EID):  A 32-bit (for IPv4) or 128-bit (for ipv6) value
      used to identify the ultimate source or destination for a LISP-
      encapsulated packet.  See [LISP] for details.

    EID-prefix:  A set of EIDs delegated in a power-of-two block.  EID-
      prefixes are routed on the ALT (not on the global Internet) and
      are expected to be assigned in a hierarchical manner such that
      they can be aggregated by ALT Routers.  Such a block is
      characterized by a prefix and a length.  Note that while the ALT
      routing system considers an EID-prefix to be an opaque block of
      EIDs, an end site may put site-local, topologically-relevant
      structure (subnetting) into an EID-prefix for intra-site routing.

    Aggregated EID-prefixes:  A set of individual EID-prefixes that have
      been aggregated in the [RFC4632] sense.

    Map Server (MS):   An edge ALT Router that provides a registration
      function for non-ALT-connected ETRs, originates EID-prefixes into
      the ALT on behalf of those ETRs, and forwards Map-Requests to
      them.  See [LISP-MS] for details.

    Map Resolver (MR):   An edge ALT Router that accepts an Encapsulated
      Map-Request from a non-ALT-connected ITR, decapsulates it, and
      forwards it on to the ALT toward the ETR which owns the requested
      EID-prefix.  See [LISP-MS] for details.

    Ingress Tunnel Router (ITR):   A router which sends LISP Map-
      Requests or encapsulates IP datagrams with LISP headers, as
      defined in [LISP].  In this document, the term refers to any
      device implementing ITR functionality, including a Proxy-ITR (see
      [LISP-IW]).  Under some circumstances, a LISP Map Resolver may
      also originate Map-Requests (see [LISP-MS]).

    Egress Tunnel Router (ETR):   A router which sends LISP Map-Replies
      in response to LISP Map-Requests and decapsulates LISP-
      encapsulated IP datagrams for delivery to end systems, as defined
      in [LISP].  In this document, the term refers to any device
      implementing ETR functionality, including a Proxy-ETR (see
      [LISP-IW]).  Under some circumstances, a LISP Map Server may also
      respond to Map-Requests (see [LISP-MS]).

    Routing Locator (RLOC):  A routable IP address for a LISP tunnel
      router (ITR or ETR).  Interchangeably referred to as a "locator"
      in this document.  An RLOC is also the output of an EID-to-RLOC
      mapping lookup; an EID-prefix maps to one or more RLOCs.
      Typically, RLOCs are numbered from topologically-aggregatable
      blocks that are assigned to a site at each point where it attaches
      to the global Internet; where the topology is defined by the
      connectivity of provider networks, RLOCs can be thought of as
      Provider Aggregatable (PA) addresses.  Routing for RLOCs is not
      carried on the ALT.

    EID-to-RLOC Mapping:  A binding between an EID-prefix and the set of
      RLOCs that can be used to reach it; sometimes referred to simply
      as a "mapping".

    EID-prefix Reachability:  An EID-prefix is said to be "reachable" if
      at least one of its locators is reachable.  That is, an EID-prefix
      is reachable if the ETR that is authoritative for a given EID-to-
      RLOC mapping is reachable.

    Default Mapping:  A Default Mapping is a mapping entry for EID-
      prefix 0.0.0.0/0 (0::/0 <=
strong>(::/0 for ipv6).  It maps to a=
 locator-set used
      for all EIDs in the Internet.  If there is a more specific EID-
      prefix in the mapping cache it overrides the Default Mapping
      entry.  The Default Mapping can be learned by configuration or
      from a Map-Reply message.

    ALT Default Route:  An EID-prefix value of 0.0.0.0/0 (or 0::/0 ::/0 for
      ipv6) which may be learned from the ALT or statically configured
      on an edge ALT Router.  The ALT-Default Route defines a forwarding
      path for a packet to be sent into the ALT on a router which does
      not have a full ALT forwarding database.

3.  The LISP+ALT model

   The LISP+ALT model uses the same basic query/response protocol that
   is documented in [LISP].  In particular, LISP+ALT provides two types
   of packet that an ITR can originate to obtain EID-to-RLOC mappings:

   Map-Request:  A Map-Request message is sent into the ALT to request
      an EID-to-RLOC mapping.  The ETR which owns the mapping will
      respond to the ITR with a Map-Reply message.  Since the ALT only
      forwards on EID destinations, the destination address of the Map-
      Request sent on the ALT must be an EID.

   Data Probe:  Alternatively, an ITR may encapsulate and send the first
      data packet destined for an EID with no known RLOCs into the ALT
      as a Data Probe.  This might be done to minimize packet loss and
      to probe for the mapping.  As above, the authoritative ETR for the
      EID-prefix will respond to the ITR with a Map-Reply message when
      it receives the data packet over the ALT.  As a side-effect, the
      encapsulated data packet is delivered to the end-system at the ETR
      site.  Note that the Data Probe's inner IP destination address,
      which is an EID, is copied to the outer IP destination address so
      that the resulting packet can be routed over the ALT.  See
      Section 3.3 for caveats on the usability of Data Probes.

   The term "ALT Datagram" is short-hand for a Map-Request or Data Probe
   to be sent into or forwarded on the ALT.  Note that such packets use
   an RLOC as the outer header source IP address and an EID as the outer
   header destination IP address.

   Detailed descriptions of the LISP packet types referenced by this
   document may be found in [LISP].

3.1.  Routeability of EIDs

   A LISP EID has the same syntax as IP address and can be used,
   unaltered, as the source or destination of an IP datagram.  In
   general, though, EIDs are not routable on the public Internet; LISP+
   ALT provides a separate, virtual network, known as the LISP
   Alternative Logical Topology (ALT) on which a datagram using an EID
   as an IP destination address may be transmitted.  This network is
   built as an overlay on the public Internet using tunnels to
   interconnect ALT Routers.  BGP runs over these tunnels to propagate
   path information needed to forward ALT Datagrams.  Importantly, while
   the ETRs are the source(s) of the unaggregated EID-prefixes, LISP+ALT
   uses existing BGP mechanisms to aggregate this information.

3.1.1.  Mechanisms for an ETR to originate EID-prefixes

   There are three ways that an ETR may originate its mappings into the
   ALT:

   1.  By registration with a Map Server as documented in [LISP-MS].
       This is the common case and is expected to be used by the
       majority of ETRs.

   2.  Using a "static route" on the ALT.  Where no Map-Server is
       available, an edge ALT Router may be configured with a "static
       EID-prefix route" pointing to an ETR.

   3.  Edge connection to the ALT.  If a site requires fine- grained
       control over how its EID-prefixes are advertised into the ALT, it
       may configure its ETR(s) with tunnel and BGP connections to edge
       ALT Routers.

3.1.2.  Mechanisms for an ITR to forward to EID-prefixes

   There are three ways that an ITR may send ALT Datagrams:

   1.  Through a Map Resolver as documented in [LISP-MS].  This is the
       common case and is expected to be used by the majority of ITRs.

   2.  Using a "default route".  Where a Map Resolver is not available,
       an ITR may be configured with a static ALT Default Route pointing
       to an edge ALT Router.

   3.  Edge connection to the ALT.  If a site requires fine-grained
       knowledge of what prefixes exist on the ALT, it may configure its
       ITR(s) with tunnel and BGP connections to edge ALT Routers.

3.1.3.  Map Server Model preferred

   The ALT-connected ITR and ETR cases are expected to be rare, as the
   Map Server/Map Resolver model is both simpler for an ITR/ETR operator
   to use, and provides a more general service interface to not only the
   ALT, but also to other mapping databases that may be developed in the
   future.

3.2.  Connectivity to non-LISP sites

   As stated above, EIDs used as IP addresses by LISP sites are not
   routable on the public Internet.  This implies that, absent a
   mechanism for communication between LISP and non-LISP sites,
   connectivity between them is not possible.  To resolve this problem,
   an "interworking" technology has been defined; see [LISP-IW] for
   details.

3.3.  Caveats on the use of Data Probes

   It is worth noting that there has been a great deal of discussion and
   controversy about whether Data Probes are a good idea.  On the one
   hand, using them offers a method of avoiding the "first packet drop"
   problem when an ITR does not have a mapping for a particular EID-
   prefix.  On the other hand, forwarding data packets on the ALT would
   require that it either be engineered to support relatively high
   traffic rates, which is not generally feasible for a tunneled
   network, or that it be carefully designed to aggressively rate-limit
   traffic to avoid congestion or DoS attacks.  There may also be issues
   caused by different latency or other performance characteristics
   between the ALT path taken by an initial Data Probe and the
   "Internet" path taken by subsequent packets on the same flow once a
   mapping is in place on an ITR.  For these reasons, the use of Data
   Probes is not recommended at this time; they should only be
   originated an ITR when explicitly configured to do so and such
   configuration should only be enabled when performing experiments
   intended to test the viability of using Data Probes.

4.  LISP+ALT: Overview

   LISP+ALT is a hybrid push/pull architecture.  Aggregated EID-prefixes
   are advertised among the ALT Routers and to those (rare) ITRs that
   are directly connected via a tunnel and BGP to the ALT.  Specific
   EID-to-RLOC mappings are requested by an ITR (and returned by an ETR)
   using LISP when it sends a request either via a Map Resolver or to an
   edge ALT Router.

   The basic idea embodied in LISP+ALT is to use BGP, running on a
   tunneled overlay network (the ALT), to establish reachability between
   ALT Routers.  The ALT BGP Route Information Base (RIB) is comprised
   of EID-prefixes and associated next hops.  ALT Routers interconnect
   using BGP and propagate EID-prefix updates among themselves.  EID-
   prefix information is learned from ETRs at the "edge" of the ALT
   either through the use of the Map Server interface (the commmon
   case), static configuration, or by BGP-speaking ETRs.

   An ITR uses

   Map Resolvers learns paths through<=
/strong> the ALT to learn the best path<=
/strike> Map Servers for forwarding an ALT
   Datagram destined to a particular EID-prefix. EID-
   prefixes.  An ITR will normally use a Map Resolver to se=
nd its ALT
   Datagrams on to the ALT but may, in unusual =
circumstances, cases (see
   Section 3.1.2), use a static ALT Default Route or connec=
t to the ALT
   using BGP.  Likewise, an ETR will normally=
 register its prefixes in
   the mapping database using a Map Server can sometimes (see
   Section 3.1.1) connect directly to the ALT using BGP.  See [LISP-MS]
   for details on Map Servers and Map Resolvers.

   Note that while this document specifies the use of Generic Routing
   Encapsulation (GRE) as a tunneling mechanism, there is no reason that
   parts of the ALT cannot be built using other tunneling technologies,
   particularly in cases where GRE does not meet security, management,
   or other operational requirements.  References to "GRE tunnel" in
   later sections of this document should therefore not be taken as
   prohibiting or precluding the use of other tunneling mechanisms.
   Note also that two ALT Routers that are directly adjacent (with no
   layer-3 router hops between them) need not use a tunnel between them;
   in this case, BGP may be configured across the interfaces that
   connect to their common subnet and that subnet is then considered to
   be part of the ALT topology.  Use of techniques such as "eBGP
   multihop" to connect ALT Routers that do not share a tunnel or common
   subnet is not recommended as the non-ALT Routers in between the ALT
   Routers in such a configuration may not have information necessary to
   forward ALT Datagrams destined to EID-prefixes exchanged across that
   BGP session.

   In summary, LISP+ALT uses BGP to build paths through ALT Routers so
   that an ALT Datagram sent into the ALT can be forwarded to the ETR
   that holds the EID-to-RLOC mapping for that EID-prefix.  This
   reachability is carried as IPv4 or ipv6 NLRI without modification
   (since an EID-prefix has the same syntax as IPv4 or ipv6 address
   prefix).  ALT Routers establish BGP sessions with one another,
   forming the ALT.  An ALT Router at the "edge" of the topology learns
   EID-prefixes originated by authoritative ETRs.  Learning may be
   though the Map Server interface, by static configuration, or via BGP
   with the ETRs.  An ALT Router may also be configured to aggregate
   EID-prefixes received from ETRs or from other LISP+ALT Routers that
   are topologically "downstream" from it.

4.1.  ITR traffic handling

   When an ITR receives a packet originated by an end system within its
   site (i.e. a host for which the ITR is the exit path out of the site)
   and the destination EID for that packet is not known in the ITR's
   mapping cache, the ITR creates either a Map-Request for the
   destination EID or the original packet encapsulated as a Data Probe
   (see Section 3.3 for caveats on the usability of Data Probes).  The
   result, known as an ALT Datagram, is then sent to an ALT Router (see
   also [LISP-MS] for non-ALT-connected ITRs, noting that Data Probes
   cannot be sent to a Map-Resolver).  This "first hop" ALT Router uses
   EID-prefix routing information learned from other ALT Routers via BGP
   to guide the packet to the ETR which "owns" the prefix.  Upon receipt
   by the ETR, normal LISP processing occurs: the ETR responds to the
   ITR with a LISP Map-Reply that lists the RLOCs (and, thus, the ETRs
   to use) for the EID-prefix.  For Data Probes, the ETR also
   decapsulates the packet and transmits it toward its destination.

   Upon receipt of the Map-Reply, the ITR installs the RLOC information
   for a given prefix into a local mapping database.  With these mapping
   entries stored, additional packets destined to the given EID-prefix
   are routed directly to an RLOC without use of the ALT, until either
   the entry's TTL has expired, or the ITR can otherwise find no
   reachable ETR.  Note that a current mapping may exist that contains
   no reachable RLOCs; this is known as a Negative Cache Entry and it
   indicates that packets destined to the EID-prefix are to be dropped.

   Full details on Map-Request/Map-Reply processing may be found in
   [LISP].

   Traffic routed on to the ALT consists solely of ALT Datagrams, i.e.
   Map-Requests and Data Probes (if supported).  Given the relatively
   low performance expected of a tunneled topology, ALT Routers (and Map
   Resolvers) should aggressively rate-limit the ingress of ALT
   Datagrams from ITRs and, if possible, should be configured to not
   accept packets that are not ALT Datagrams.

4.2.  EID Assignment - Hierarchy and Topology

   EID-prefixes are expected to be allocated to=


   The ALT database is organized in a LISP site by Internet
   Registries. herarchical ma=
nner with EID-
   prefixs aggregated on power-of-2 block boundaries.  Wher=
e a LISP site
   has multiple allocations which EID-prefixes that are alig=
ned on a power-of-2 apower-of-2 block
   boundary, they should be aggregated into a single EID-prefix for
   advertisement.  The ALT network is built in a roughly hierarchical,
   partial mesh which is intended to allow aggregation where clearly-defined clearly-
   defined hierarchical boundaries exist.  Building such a =
structure
   should minimize the number of EID-prefixes carried by LISP+ALT nodes
   near the top of the hierarchy.

   Routes on the ALT do not need to respond to changes in policy,
   subscription, or underlying physical connectivity, so the topology
   can remain relatively static and aggregation can be sustained.
   Because routing on the ALT uses BGP, the same rules apply for
   generating aggregates; in particular, a ALT Router should only be
   configured to generate an aggregate if it is configured with BGP
   sessions to all of the originators of components (more-specific
   prefixes) of that aggregate.  Not all of the components of need to be
   present for the aggregate to be originated (some may be holes in the
   covering prefix and some may be down) but the aggregating router must
   be configured to learn the state of all of the components.

   Under what circumstances the ALT Router actually generates the
   aggregate is a matter of local policy: in some cases, it will be
   statically configured to do so at all times with a "static discard"
   route.  In other cases, it may be configured to only generate the
   aggregate prefix if at least one of the components of the aggregate
   is learned via BGP.

   An ALT Router must not generate an aggregate that includes a non-
   LISP-speaking hole unless it can be configured to return a Negative
   Map-Reply with action=3D"Natively-Forward" (see [LISP]) if it receives
   an ALT Datagram that matches that hole.  If it receives an ALT
   Datagram that matches a LISP-speaking hole that is currently not
   reachable, it should return a Negative Map-Reply with action=3D"drop".
   Negative Map-Replies should be returned with a short TTL, as
   specified in [LISP-MS].  Note that an off-the-shelf, non-LISP-
   speaking router configured as an aggregating ALT Router cannot send
   Negative Map-Replies, so such a router must never originate an
   aggregate that includes a non-LISP-speaking hole.

   This implies that two ALT Routers that share an overlapping set of
   prefixes must exchange those prefixes if either is to generate and
   export a covering aggregate for those prefixes.  It also implies that
   an ETR which connects to the ALT using BGP must maintain BGP sessions
   with all of the ALT Routers that are configured to originate an
   aggregate which covers that prefix and that each of those ALT Routers
   must be explicitly configured to know the set of EID-prefixes that
   make up any aggregate that it originates.  See also [LISP-MS] for an
   example of other ways that prefix origin consistency and aggregation
   can be maintained.

   As an example, consider ETRs that are originating EID-prefixes for
   10.1.0.0/24, 10.1.64.0/24, 10.1.128.0/24, and 10.1.192.0/24.  An ALT
   Router should only be configured to generate an aggregate for
   10.1.0.0/16 if it has BGP sessions configured with all of these ETRs,
   in other words, only if it has sufficient knowledge about the state
   of those prefixes to summarize them.  If the Router originating
   10.1.0.0/16 receives an ALT Datagram destined for 10.1.77.88, a non-
   LISP destination covered by the aggregate, it returns a Negative Map-
   Reply with action "Natively-Forward".  If it receives an ALT Datagram
   destined for 10.1.128.199 but the configured LISP prefix
   10.1.128.0/24 is unreachable, it returns a Negative Map-Reply with
   action "drop".

   Note: much is currently uncertain about the best way to build the ALT
   network; as testing and prototype deployment proceeds, a guide to how
   to best build the ALT network will be developed.

4.3.  Use of GRE and BGP between LISP+ALT Routers

   The ALT network is built using GRE tunnels between ALT Routers.  BGP
   sessions are configured over those tunnels, with each ALT Router
   acting as a separate AS "hop" in a Path Vector for BGP.  For the
   purposes of LISP+ALT, the AS-path is used solely as a shortest-path
   determination and loop-avoidance mechanism.  Because all next-hops
   are on tunnel interfaces, no IGP is required to resolve those next-
   hops to exit interfaces.

   LISP+ALT's use of GRE and BGP facilities deployment and operation of
   LISP because no new protocols need to be defined, implemented, or
   used on the overlay topology; existing BGP/GRE tools and operational
   expertise are also re-used.  Tunnel address assignment is also easy:
   since the addresses on an ALT tunnel are only used by the pair of
   routers connected to the tunnel, the only requirement of the IP
   addresses used to establish that tunnel is that the attached routers
   be reachable by each other; any addressing plan, including private
   addressing, can therefore be used for ALT tunnels.

5.  EID-prefix Propagation and Map-Request Forwarding

   As described in Section 8.2, an ITR sends an ALT Datagram to a given
   EID-to-RLOC mapping.  The ALT provides the infrastructure that allows
   these requests to reach the authoritative ETR.

   Note that under normal circumstances Map-Replies are not sent over
   the ALT; an ETR sends a Map-Reply to one of the ITR RLOCs learned
   from the original Map-Request.  See sections 6.1.2 and 6.2 of [LISP]
   for more information on the use of the Map-Request ITR RLOC field.
   Keep in mind that the ITR RLOC field supports mulitple RLOCs in
   multiple address families, so a Map-Reply sent in response to a Map-
   Request is not necessarily sent to back to the Map-Request RLOC
   source.

   There may be scenarios, perhaps to encourage caching of EID-to-RLOC
   mappings by ALT Routers, where Map-Replies could be sent over the ALT
   or where a "first-hop" ALT Router might modify the originating RLOC
   on a Map-Request received from an ITR to force the Map-Reply to be
   returned to the "first-hop" ALT Router.  These cases will not be
   supported by initial LISP+ALT implementations but may be subject to
   future experimentation.

   ALT Routers propagate path information via BGP ([RFC4271]) that is
   used by ITRs to send ALT Datagrams toward the appropriate ETR for
   each EID-prefix.  BGP is run on the inter-ALT Router links, and
   possibly between an edge ("last hop") ALT Router and an ETR or
   between an edge ("first hop") ALT Router and an ITR.  The ALT BGP RIB
   consists of aggregated EID-prefixes and their next hops toward the
   authoritative ETR for that EID-prefix.

5.1.  Changes to ITR behavior with LISP+ALT

   As previously described, an ITR will usually use the Map Resolver
   interface and will send its Map Requests to a Map Resolver.  When an
   ITR instead connects via tunnels and BGP to the ALT, it sends ALT
   Datagrams to one of its "upstream" ALT Routers; these are sent only
   to obtain new EID-to-RLOC mappings - RLOC probe and cache TTL refresh
   Map-Requests are not sent on the ALT.  As in basic LISP, it should
   use one of its RLOCs as the source address of these queries; it
   should not use a tunnel interface as the source address as doing so
   will cause replies to be forwarded over the tunneled topology and may
   be problematic if the tunnel interface address is not routed
   throughout the ALT.  If the ITR is running BGP with the LISP+ALT
   router(s), it selects the appropriate ALT Router based on the BGP
   information received.  If it is not running BGP, it uses a
   statically-configued ALT Default Route to select an ALT Router.

5.2.  Changes to ETR behavior with LISP+ALT

   As previously described, an ETR will usually use the Map Server
   interface (see [LISP-MS]) and will register its EID-prefixes with its
   configured Map Servers.  When an ETR instead connects using BGP to
   one or more ALT Routers, it announces its EID-prefix(es) to those ALT
   Routers.

   As documented in [LISP], when an ETR generates a Map-Reply message to
   return to a querying ITR, it sets the outer header IP destination
   address to one of the requesting ITR's RLOCs so that the Map-Reply
   will be sent on the underlying Internet topology, not on the ALT;
   this avoids any latency penalty (or "stretch") that might be incurred
   by sending the Map-Reply via the ALT, reduces load on the ALT, and
   ensures that the Map-Reply can be routed even if the original ITR
   does not have an ALT-routed EID.  For details on how an ETR selects
   which ITR RLOC to use, see section 6.1.5 of [LISP].

5.3.  ALT Datagram forwarding falure

   Intermediate ALT Routers, forward ALT Datagrams using normal, hop-by-
   hop routing on the ALT overlay network.  Should an ALT router not be
   able to forward an ALT Datagram, whether due to an unreachable next-
   hop, TTL exceeded, or other problem, it has several choices:

   o  If the ALT Router understands the LISP protocol, as is the case
      for a Map Resolver or Map Server, it may respond to a forwarding
      failure by returning a negative Map-Reply, as described in
      Section 4.2 and [LISP-MS].

   o  If the ALT Router does not understand LISP, it may attempt to
      return an ICMP message to the source IP address of the packet that
      cannot be forwarded.  Since the source address is an RLOC, an ALT
      Router would send this ICMP message using "native" Internet
      connectivity, not via the ALT overlay.

   o  A non-LISP-capable ALT Router may also choose to silently drop the
      non-forwardable ALT Datagram.

   [LISP] and [LISP-MS] define how the source of an ALT Datagram should
   handle each of these cases.  The last case, where an ALT Datagram is
   silently discarded, will generally result in several retransmissions
   by the source, followed by treating the destination as unreachable
   via LISP when no Map-Reply is received.  If a problem on the ALT is
   severe enough to prevent ALT Datagrams from being delivered to a
   specific EID, this is probably the only sensible way to handle this
   case.

   Note that the use of GRE tunnels should prevent MTU problems from
   ever occurring on the ALT; an ALT Datagram that exceeds an
   intermediate MTU will be fragmented at that point and will be
   reassembled by the target of the GRE tunnel.

6.  BGP configuration and protocol considerations

6.1.  Autonomous System Numbers (ASNs) in LISP+ALT

   The primary use of BGP today is to define the global Internet routing
   topology in terms of its participants, known as Autonomous Systems.
   LISP+ALT specifies the use of BGP to create a global overlay network
   (the ALT) for finding EID-to-RLOC mappings.  While related to the
   global routing database, the ALT serves a very different purpose and
   is organized into a very different hierarchy.  Because LISP+ALT does
   use BGP, however, it uses ASNs in the paths that are propagated among
   ALT Routers.  To avoid confusion, LISP+ALT should use newly-assigned
   AS numbers that are unrelated to the ASNs used by the global routing
   system.  Exactly how this new space will be assigned and managed will
   be determined during the deployment of LISP+ALT.

   Note that the ALT Routers that make up the "core" of the ALT will not
   be associated with any existing core-Internet ASN because the ALT
   topology is completely separate from, and independent of, the global
   Internet routing system.

6.2.  Sub-Address Family Identifier (SAFI) for LISP+ALT

   As defined by this document, LISP+ALT may be implemented using BGP
   without modification.  Given the fundamental operational difference
   between propagating global Internet routing information (the current
   dominant use of BGP) and creating an overlay network for finding EID-
   to-RLOC mappings (the use of BGP proposed by this document), it may
   be desirable to assign a new SAFI [RFC4760] to prevent operational
   confusion and difficulties, including the inadvertent leaking of
   information from one domain to the other.  Use of a separate SAFI
   would make it easier to debug many operational problems but would
   come at a significant cost: unmodified, off-the-shelf routers which
   do not understand the new SAFI could not be used to build any part of
   the ALT network.  At present, this document does not request the
   assignment of a new SAFI; additional experimentation may suggest the
   need for one in the future.

7.  EID-prefix Aggregation

   The ALT BGP peering topology should be arranged in a tree-like
   fashion (with some meshiness), with redundancy to deal with node and
   link failures.  A basic assumption is that as long as the routers are
   up and running, the underlying Internet will provide alternative
   routes to maintain BGP connectivity among ALT Routers.

   Note that, as mentioned in Section 4.2, the use of BGP by LISP+ALT
   requires that information only be aggregated where all active more-
   specific prefixes of a generated aggregate prefix are known.  This is
   no different than the way that BGP route aggregation works in the
   existing global routing system: a service provider only generates an
   aggregate route if it is configured to learn to all prefixes that
   make up that aggregate.

7.1.  Stability of the ALT

   It is worth noting that LISP+ALT does not directly propagate EID-to-
   RLOC mappings.  What it does is provide a mechanism for an ITR to
   commonicate with the ETR that holds the mapping for a particular EID-
   prefix.  This distinction is important when considering the stability
   of BGP on the ALT network as compared to the global routing system.
   It also has implications for how site-specific EID-prefix information
   may be used by LISP but not propagated by LISP+ALT (see Section 7.2
   below).

   RLOC prefixes are not propagated through the ALT so their
   reachability is not determined through use of LISP+ALT.  Instead,
   reachability of RLOCs is learned through the LISP ITR-ETR exchange.
   This means that link failures or other service disruptions that may
   cause the reachability of an RLOC to change are not known to the ALT.
   Changes to the presence of an EID-prefix on the ALT occur much less
   frequently: only at subscription time or in the event of a failure of
   the ALT infrastructure itself.  This means that "flapping" (frequent
   BGP updates and withdrawals due to prefix state changes) is not
   likely and mapping information cannot become "stale" due to slow
   propagation through the ALT BGP mesh.

7.2.  Traffic engineering using LISP

   Since an ITR learns an EID-to-RLOC mapping directly from the ETR that
   owns it, it is possible to perform site-to-site traffic engineering
   by setting the preference and/or weight fields, and by including
   more-specific EID-to-RLOC information in Map-Reply messages.

   This is a powerful mechanism that can conceivably replace the
   traditional practice of routing prefix deaggregation for traffic
   engineering purposes.  Rather than propagating more-specific
   information into the global routing system for local- or regional-
   optimization of traffic flows, such more-specific information can be
   exchanged, through LISP (not LISP+ALT), on an as-needed basis between
   only those ITRs/ETRs (and, thus, site pairs) that need it.  Such an
   exchange of "more-specifics" between sites facilitates traffic
   engineering, by allowing richer and more fine-grained policies to be
   applied without advertising additional prefixes into either the ALT
   or the global routing system.

   Note that these new traffic engineering capabilities are an attribute
   of LISP and are not specific to LISP+ALT; discussion is included here
   because the BGP-based global routing system has traditionally used
   propagation of more-specific routes as a crude form of traffic
   engineering.

7.3.  Edge aggregation and dampening

   Normal BGP best common practices apply to the ALT network.  In
   particular, first-hop ALT Routers will aggregate EID prefixes and
   dampen changes to them in the face of excessive updates.  Since EID-
   prefix assignments are not expected to change as frequently as global
   routing BGP prefix reachability, such dampening should be very rare,
   and might be worthy of logging as an exceptional event.  It is again
   worth noting that the ALT carries only EID-prefixes, used to a
   construct BGP path to each ETR (or Map-Server) that originates each
   prefix; the ALT does not carry reachability about RLOCs.  In
   addition, EID-prefix information may be aggregated as the topology
   and address assignment hierarchy allow.  Since the topology is all
   tunneled and can be modified as needed, reasonably good aggregation
   should be possible.  In addition, since most ETRs are expected to
   connect to the ALT using the Map Server interface, Map Servers will
   implement a natural "edge" for the ALT where dampening and
   aggregation can be applied.  For these reasons, the set of prefix
   information on the ALT can be expected to be both better aggregated
   and considerably less volatile than the actual EID-to-RLOC mappings.

7.4.  EID assignment flexibility vs. ALT scaling

   There are major open questions regarding how the ALT will be deployed
   and what organization(s) will operate it.  In a simple, non-
   distributed world, centralized administration of EID prefix
   assignment and ALT network design would facilitate a well- aggregated
   ALT routing system.  Business and other realities will likely result
   in a more complex, distributed system involving multiple levels of
   prefix delegation, multiple operators of parts of the ALT
   infrastructure, and a combination of competition and cooperation
   among the participants.  In addition, re-use of existing IP address
   assignments, both "PI" provider-independent ("PI") and "PA", provider-assigned
   ("PA"), to avoid renumbering when sites transition to LI=
SP will
   further complicate the processes of building and operating the ALT.

   A number of conflicting considerations need to be kept in mind when
   designing and building the ALT.  Among them are:

   1.  Target ALT routing state size and level of aggregation.  As
       described in Section 7.1, the ALT should not suffer from some of
       the performance constraints or stability issues as the Internet
       global routing system, so some reasonable level of deaggregation
       and increased number of EID prefixes beyond what might be
       considered ideal should be acceptable.  That said, measures, such
       as tunnel rehoming to preserve aggregation when sites move from
       one mapping provider to another and implementing aggregation at
       multiple levels in the hierarchy to collapse de-aggregation at
       lower levels, should be taken to reduce unnecessary explosion of
       ALT routing state.

   2.  Number of operators of parts of the ALT and how they will be
       organized (hierarchical delegation vs. shared administration).
       This will determine not only how EID prefixes are assigned but
       also how tunnels are configured and how EID prefixes can be
       aggregated between different parts of the ALT.

   3.  Number of connections between different parts of the ALT.  Trade-
       offs will need to be made among resilience, performance, and
       placement of aggregation boundaries.

   4.  EID prefix portability between competing operators of the ALT
       infrastructure.  A significant benefit for an end-site to adopt
       LISP is the availability of EID space that is not tied to a
       specific connectivity provider; it is important to ensure that an
       end site doesn't trade lock-in to a connectivity provider for
       lock-in to a provider of its EID assignment, ALT connectivity, or
       Map Server facilities.

   This is, by no means, an exhaustive list.

   While resolving these issues is beyond the scope of this document,
   the authors recommend that existing distributed resource structures,
   such as the IANA/Regional Internet Registries and the ICANN/Domain
   Registrar, be carefully considered when designing and deploying the
   ALT infrastructure.

8.  Connecting sites to the ALT network

8.1.  ETRs originating information into the ALT

   EID-prefix information is originated into the ALT by three different
   mechanisms:

   Map Server:  In most cases, a site will configure its ETR(s) to
      register with one or more Map Servers (see [LISP-MS]), and does
      not participate directly in the ALT.

   BGP:  For a site requiring complex control over their EID-prefix
      origination into the ALT, an ETR may connect to the LISP+ALT
      overlay network by running BGP to one or more ALT Router(s) over
      tunnel(s).  The ETR advertises reachability for its EID-prefixes
      over these BGP connection(s).  The edge ALT Router(s) that
      receive(s) these prefixes then propagate(s) them into the ALT.
      Here the ETR is simply an BGP peer of ALT Router(s) at the edge of
      the ALT.  Where possible, an ALT Router that receives EID-prefixes
      from an ETR via BGP should aggregate that information.

   Configuration:  One or more ALT Router(s) may be configured to
      originate an EID-prefix on behalf of the non-BGP-speaking ETR that
      is authoritative for a prefix.  As in the case above, the ETR is
      connected to ALT Router(s) using GRE tunnel(s) but rather than BGP
      being used, the ALT Router(s) are configured with what are in
      effect "static routes" for the EID-prefixes "owned" by the ETR.
      The GRE tunnel is used to route Map-Requests to the ETR.

   Note:  in all cases, an ETR may register to multiple Map Servers or
      connect to multiple ALT Routers for the following reasons:

      *  redundancy, so that a particular ETR is still reachable even if
         one path or tunnel is unavailable.

      *  to connect to different parts of the ALT hierarchy if the ETR
         "owns" multiple EID-to-RLOC mappings for EID-prefixes that
         cannot be aggregated by the same ALT Router (i.e. are not
         topologically "close" to each other in the ALT).

8.2.  ITRs Using the ALT

   In the common configuration, an ITR does not need to know anything
   about the ALT, since it sends Map-Requests to one of its configured
   Map-Resolvers (see [LISP-MS]).  There are two exceptional cases:

   Static default:  If a Map Resolver is not available but an ITR is
      adjacent to an ALT Router (either over a common subnet or through
      the use of a tunnel), it can use an ALT Default Route route to
      cause all ALT Datagrams to be sent that ALT Router.  This case is
      expected to be rare.

   Connection to ALT:  A site with complex Internet connectivity needs
      may need more fine-grained distinction between traffic to LISP-
      capable and non-LISP-capable sites.  Such a site may configure
      each of its ITRs to connect directly to the ALT, using a tunnel
      and BGP connection.  In this case, the ITR will receive EID-prefix
      routes from its BGP connection to the ALT Router and will LISP-
      encapsulate and send ALT Datagrams through the tunnel to the ALT
      Router.  Traffic to other destinations may be forwarded (without
      LISP encapsulation) to non-LISP next-hop routers that the ITR
      knows.

      In general, an ITR that connects to the ALT does so only to to ALT
      Routers at the "edge" of the ALT (typically two for redundancy).
      There may, though, be situations where an ITR would connect to
      other ALT Routers to receive additional, shorter path information
      about a portion of the ALT of interest to it.  This can be
      accomplished by establishing GRE tunnels between the ITR and the
      set of ALT Routers with the additional information.  This is a
      purely local policy issue between the ITR and the ALT Routers in
      question.

   As described in [LISP-MS], Map-Resolvers do not accept or forward
   Data Probes; in the rare scenario that an ITR does support and
   originate Data Probes, it must do so using one of the exceptional
   configurations described above.  Note that the use of Data Probes is
   discouraged at this time (see Section 3.3).

9.  IANA Considerations

   This document makes no request of the IANA.

10.  Security Considerations

   LISP+ALT shares many of the security characteristics of BGP.  Its
   security mechanisms are comprised of existing technologies in wide
   operational use today, so securing the ALT should be mostly a matter
   of applying the same technology that is used to secure the BGP-based
   global routing system (see Section 10.3 below).

10.1.  Apparent LISP+ALT Vulnerabilities

   This section briefly lists the known potential vulnerabilities of
   LISP+ALT.

   Mapping Integrity:  Can  Potential for an attacker to insert bogus
      mappings to black-
      hole black-hole<=
/strong> (create Denial-of-Service, or DoS attack)
      or intercept LISP data-plane packets? packets.

   ALT Router Availability:  Can an attacker DoS the ALT Routers
      connected to a given ETR?  If a site's ETR cannot advertise its
      EID-to-RLOC mappings, the site is essentially unavailable.

   ITR Mapping/Resources:  Can an attacker force an ITR or ALT Router to
      drop legitimate mapping requests by flooding it with random
      destinations for which it will generate large numbers of Map-
      Requests and fill its mapping cache?  Further study is required to
      see the impact of admission control on the overlay network.

   EID Map-Request Exploits for Reconnaissance:  Can an attacker learn
      about a LISP site's TE policy by sending legitimate mapping
      requests and then observing the RLOC mapping replies?  Is this
      information useful in attacking or subverting peer relationships?
      Note that any public LISP mapping database will have similar data-
      plane reconnaissance issue.

   Scaling of ALT Router Resources:  Paths through the ALT may be of
      lesser bandwidth than more "direct" paths; this may make them more
      prone to high-volume denial-of-service attacks.  For this reason,
      all components of the ALT (ETRs and ALT Routers) should be
      prepared to rate-limit traffic (ALT Datagrams) that could be
      received across the ALT.

   UDP Map-Reply from ETR:  Since Map-Replies are sent directly from the
      ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable to various
      types of DoS attacks (this is a general property of LISP, not an
      LISP+ALT vulnerability).

   More-specific prefix leakage:  Because EID-prefixes on the ALT are
      expected to be fairly well-aggregated and EID-prefixes propagated
      out to the global Internet (see [LISP-IW]=
 [LISP-IW]) m=
uch more so,
      accidental leaking or malicious advertisement of an EID-prefix
      into the global routing system could cause traffic redirection
      away from a LISP site.  This is not really a new problem, though,
      and its solution can only be achieved by much more strict prefix
      filtering and authentication on the global routing system.
      Section Section 10.3 describes an exist=
ingapproach to solving this
      problem.

10.2.  Survey of LISP+ALT Security Mechanisms

   Explicit peering:  The devices themselves can both prioritize
      incoming packets, as well as potentially do key checks in hardware
      to protect the control plane.

   Use of TCP to connect elements:  This makes it difficult for third
      parties to inject packets.

   Use of HMAC Protected to protect BGP/TCP Connections: conn=
ections:  HMAC [RFC5925] is used
      to verify
      message the integrity and =
authenticity, authenticity of=
 TCP connections used
      to exchange BGP messages, making it nearly impossible=
 for third
      party devices to either insert or modify messages.

   Message Sequence Numbers sequence numbers and Nonce Values nonce values in Messages: messages:  This a=
llows
      an ITR to verify that the Map-Reply from an ETR is in response to
      a Map-Request originated by that ITR (this is a general property
      of LISP; LISP+ALT does not change this behavior).

10.3.  Use of new IETF standard BGP Security mechanisms

   LISP+ALT's use of BGP allows the ALT<=
/strike> it to take advantage=
 of BGP security
   features designed for existing Internet BGP use.  Should the
   Internet community converge on the work currently being done in  This means that
   LISP+ALT can and should use technology developed for adding security
   to BGP (in the IETF SIDR working group or should either S-BGP [I-D.murphy-bgp-secr]
   or soBGP [I-D.white-sobgparchitecture] be implemented and widely-
   deployed, LISP+ALT can readily use these mechanisms elsewhere) to provide
   authentication of EID-prefix origination and EID-to-RLOC mappings.

11.  Acknowledgments

   The authors would like to specially thank J. Noel Chiappa who was a
   key contributer to the design of the LISP-CONS mapping database (many
   ideas from which made their way into LISP+ALT) and who has continued
   to provide invaluable insight as the LISP effort has evolved.  Others
   who have provided valuable contributions include John Zwiebel, Hannu
   Flinck, Amit Jain, John Scudder, Scott Brim, and Jari Arkko.

12.  References

12.1.  Normative References

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-15.txt (work in progress), July 2011.

   [LISP-MS]  Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-12.txt (work in progress),
              September
              October 2011.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

12.2.  Informative References

   [I-D.murphy-bgp-secr]
              Murphy, S., "BGP Security Analysis",
              draft-murphy-bgp-secr-04 (work in progress),
              November 2001.

   [I-D.white-sobgparchitecture]
              White, R., "Architecture and Deployment Considerations for
              Secure Origin BGP (soBGP)",
              draft-white-sobgparchitecture-00 (work in progress),
              May 2004.

   [LISP-IW]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and ipv6",
              draft-ietf-lisp-interworking-02.txt (work in progress),
              March 2011.

   [RFC5925]  Touch, J., Mankin, A., and R. B=
onica, "The TCP
              Authentication Option", RFC 5925, June 2010.

Authors' Addresses

   Vince Fuller
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dino Farinacci
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   Dave Meyer
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dmm@cisco.com

   Darrel Lewis
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: darlewis@cisco.com
--lrZ03NoBR/3+SXJZ-- From vaf@cisco.com Tue Dec 6 12:55:44 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF20811E8080 for ; Tue, 6 Dec 2011 12:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.207 X-Spam-Level: X-Spam-Status: No, score=-5.207 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FAKE_REPLY_C=2.012, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5rxJ9mpElQd for ; Tue, 6 Dec 2011 12:55:44 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4108A11E8073 for ; Tue, 6 Dec 2011 12:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=2959; q=dns/txt; s=iport; t=1323204944; x=1324414544; h=date:from:to:subject:message-id:mime-version; bh=sTWglBTMctxNDv39r0X3CFpWmlVdTWmzzxroqakjZ4o=; b=jKF1tnvQYRy60woI15gpx55OjSEsCm1EugeDedVn6z7VuxfieuYluLfp zXsEdkC+ZIULjCb+ZS0XDkLdMBUgCOyDwW3w/W4jPhtp6ZVMiosPWg8my pfXJ/dNySj1hKZiY0VvAcrxiln1bZ+I+XylTuaRz5NIMOLeo6kHKuW0Xe 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANeA3k6rRDoI/2dsb2JhbABDql6BBYFyAQEBBQEBDwEnNCYRAwECDzQTBRoJIQkZh22VaoEmAZ5RiBqCNWMEiC6MN4pph1k X-IronPort-AV: E=Sophos;i="4.71,308,1320624000"; d="scan'208";a="18071425" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 06 Dec 2011 20:55:44 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB6Kti03008156 for ; Tue, 6 Dec 2011 20:55:44 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 5B3E61ADCB90; Tue, 6 Dec 2011 12:55:43 -0800 (PST) Date: Tue, 6 Dec 2011 12:55:43 -0800 From: Vince Fuller To: lisp@ietf.org Message-ID: <20111206205543.GB34495@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Re: [lisp] I-D Action: draft-ietf-lisp-ms-13.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:55:45 -0000 This version includes only one minor change: correct the name of the HMAC version used in section 7. --Vince ----- Forwarded message from internet-drafts@ietf.org ----- Date: Tue, 06 Dec 2011 12:35:34 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: lisp@ietf.org Subject: I-D Action: draft-ietf-lisp-ms-13.txt X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQBAHR73k4MFjoekmdsb2JhbABDql4iAQEBAQkLCxkngXQBBQEBDwEnBgEBBAoeCwECAwECBgJACAgDASNJBQQZh22XBgGLcoQcAY44B4gagxiIMow3AYpoh1k X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only Errors-To: i-d-announce-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Map Server Interface Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-13.txt Pages : 19 Date : 2011-12-06 This draft describes the Maping Service for the Locator Identifier Separation Protocol (LISP), implemented by two new types of LISP- speaking devices, the LISP Map Resolver and LISP Map Server, that provides a simplified "front end" to for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map Resolvers and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers, are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-ms-13.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- From internet-drafts@ietf.org Tue Dec 6 20:45:47 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC92D21F8C1A; Tue, 6 Dec 2011 20:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUTydanmnGyh; Tue, 6 Dec 2011 20:45:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4DE21F848D; Tue, 6 Dec 2011 20:45:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111207044547.24648.49341.idtracker@ietfa.amsl.com> Date: Tue, 06 Dec 2011 20:45:47 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-17.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 04:45:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-17.txt Pages : 94 Date : 2011-12-06 This draft describes a network layer based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-17.txt From markus@moeller.plus.com Sat Dec 10 05:21:12 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C2F21F8B5D for ; Sat, 10 Dec 2011 05:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_LEO_LINE03a=0.408] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VlrcnW9mbFd for ; Sat, 10 Dec 2011 05:21:10 -0800 (PST) Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) by ietfa.amsl.com (Postfix) with ESMTP id AF24321F8B5C for ; Sat, 10 Dec 2011 05:21:09 -0800 (PST) Received: from VAIOLaptop ([81.174.172.105]) by avasout01 with smtp id 7RLm1i0052Gnz1d01RM5Mc; Sat, 10 Dec 2011 13:21:06 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=IcoFqBWa c=1 sm=1 a=Cgy7cPM/+uUNK5d9KfAcsw==:17 a=OOlNlwVvYbEA:10 a=6eoFkrnuAAAA:8 a=7TFWg8dcAAAA:8 a=X7tn7OxAAAAA:8 a=Blct8ZPWAAAA:8 a=SCo1hh1FAAAA:8 a=pIzQlVK5AAAA:8 a=0Bzu9jTXAAAA:8 a=aYuDfMPzAAAA:8 a=R1r5O7FUxP9GkOweynoA:9 a=_GQN8jFvuRrPRLwIM24A:7 a=wPNLvfGTeEIA:10 a=X8DO95fqYWamJ8VS:21 a=G5wFZvthY8Pwp7g3:21 a=N9fwMUHEAY5I3dO6nBsA:9 a=V5dfdmdj41FZyo4-dfMA:7 a=6jSb7URpHV0A:10 a=iYyD4qEmTlkA:10 a=MpAYZWLQQ9cA:10 a=9W-_wCCyc4QA:10 a=1gPTMFIu9VkA:10 a=Cgy7cPM/+uUNK5d9KfAcsw==:117 Message-ID: <14C67F00997342E48A803652F6FEE7AB@VAIOLaptop> From: "Markus Moeller" To: Date: Sat, 10 Dec 2011 13:20:38 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_075A_01CCB73E.85413400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 X-Mailman-Approved-At: Sat, 10 Dec 2011 18:19:48 -0800 Cc: lisp-support@cisco.com Subject: [lisp] Can not reach IPv6 site via LISP network X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 13:29:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_075A_01CCB73E.85413400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I try to connect to a website on the ipv network and my ISP tells me = it is a problem with the LISP prefix. I was asked to rais it with the = WG. Thank you Markus Can not reach server on ipv6 network Markus Moeller on Friday, 09 December 2011 19:59:04 Here are the traceroute details for the not working site: C:\My Program Files\Windows Resource Kits\Tools>tracert www.ipv6-db.com Tracing route to www.ipv6-db.com [2610:d0:2113:3::3] over a maximum of 30 hops: 1 31 ms 28 ms 29 ms gw-1326.lon-02.gb.sixxs.net [2a01:348:6:52d::1] 2 28 ms 28 ms 29 ms ge-0-0-5-20.cs0.thw.uk.goscomb.net = [2a01:348:0:4:0:3:0:1] 3 30 ms 31 ms 29 ms xe-0-0-0.rt0.the.uk.goscomb.net [2a01:348::27:0:1] 4 28 ms 31 ms 30 ms lonap.he.net [2001:7f8:17::1b1b:1] 5 97 ms 100 ms 96 ms 10gigabitethernet7-4.core1.nyc4.he.net = [2001:470:0:3e::1] 6 120 ms 116 ms 124 ms 10gigabitethernet8-3.core1.chi1.he.net = [2001:470:0:1c6::2] 7 189 ms 190 ms 187 ms 2001:470:1:34::2 8 187 ms 188 ms 191 ms iana.r1.ord1.isc.org [2001:500:71:6::1] 9 189 ms 207 ms 204 ms int-0-0-1-8.r1.pao1.isc.org [2001:4f8:0:1::4a:1] 10 190 ms 191 ms 191 ms int-0-1-0-0.r1.sql1.isc.org [2001:4f8:1b:1::8:2] 11 187 ms * 187 ms lisp-r1.sql1.isc.org [2001:4f8:3:d::60] 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. Jeroen Massar SixXS on Friday, 09 December 2011 20:15:39 > Tracing route to www.ipv6-db.com [2610:d0:2113:3::3] That is a LISP prefix, there is some kind of magical routing involved = there and it is all quite experimental. See Cisco's LISP and the LISP beta site site for more details. Please contact the site operator or the LISP WG to resolve this. There = is nothing much we can do about this. BTW I cant reach the lisp website over ipv4 either: C:\My Program Files\Windows Resource Kits\Tools>tracert www.lisp4.net Tracing route to noc.eid.lisp4.net [153.16.10.11] over a maximum of 30 hops: 1 1 ms 3 ms 5 ms homerouter.windows.home [192.168.1.1] 2 29 ms 30 ms 29 ms lo0-central3.thn-ag2.plus.net = [195.166.128.231] 3 82 ms 212 ms 205 ms gi1-11-231.thn-gw1.plus.net = [84.92.6.208] 4 29 ms 29 ms 28 ms po4.thn-gw2.plus.net [212.159.1.135] 5 29 ms 29 ms 28 ms 195.66.225.24 6 49 ms 75 ms 49 ms dk-ore.nordu.net [109.105.97.30] 7 52 ms 58 ms 55 ms dk-uni.nordu.net [109.105.97.14] 8 59 ms 60 ms 60 ms stolav-gw2.uninett.no [109.105.102.26] 9 63 ms 64 ms 143 ms oslo-gw.uninett.no [128.39.255.85] 10 80 ms 71 ms 70 ms trd-gw1.uninett.no [128.39.255.110] 11 71 ms 71 ms 70 ms trd-gw7.uninett.no [128.39.255.214] 12 71 ms 71 ms 71 ms uninett-pxtr.rloc.lisp4.net = [158.38.1.92] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. ------=_NextPart_000_075A_01CCB73E.85413400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
  I = try to=20 connect to a website on the ipv network and my ISP tells me it is a = problem with=20 the LISP prefix. I was asked to rais it with the WG.
Thank = you
Can not = reach=20 server on ipv6 network
Markus Moeller=20 on Friday, 09 December 2011 19:59:04
Here = are the=20 traceroute details for the not working site:
C:\My Program = Files\Windows=20 Resource Kits\Tools>tracert www.ipv6-db.com

Tracing route to=20 www.ipv6-db.com [2610:d0:2113:3::3]
over a maximum of 30 = hops:

1 31 ms=20 28 ms 29 ms gw-1326.lon-02.gb.sixxs.net [2a01:348:6:52d::1]
2 28 ms = 28 ms 29=20 ms ge-0-0-5-20.cs0.thw.uk.goscomb.net [2a01:348:0:4:0:3:0:1]
3 30 ms = 31 ms 29=20 ms xe-0-0-0.rt0.the.uk.goscomb.net [2a01:348::27:0:1]
4 28 ms 31 ms = 30 ms=20 lonap.he.net [2001:7f8:17::1b1b:1]
5 97 ms 100 ms 96 ms=20 10gigabitethernet7-4.core1.nyc4.he.net [2001:470:0:3e::1]
6 120 ms = 116 ms 124=20 ms 10gigabitethernet8-3.core1.chi1.he.net [2001:470:0:1c6::2]
7 189 = ms 190 ms=20 187 ms 2001:470:1:34::2
8 187 ms 188 ms 191 ms iana.r1.ord1.isc.org=20 [2001:500:71:6::1]
9 189 ms 207 ms 204 ms int-0-0-1-8.r1.pao1.isc.org = [2001:4f8:0:1::4a:1]
10 190 ms 191 ms 191 ms = int-0-1-0-0.r1.sql1.isc.org=20 [2001:4f8:1b:1::8:2]
11 187 ms * 187 ms lisp-r1.sql1.isc.org=20 [2001:4f8:3:d::60]
12 * * * Request timed out.
13 * * * Request = timed=20 out.
14 * * * Request timed out.
15 * * * Request timed out.
16 = * * *=20 Request timed out.
17 * * * Request timed out.
18 * * * Request = timed=20 out.
19 * * * Request timed out.
20 * * * Request timed out.
21 = * * *=20 Request timed out.
22 * * * Request timed out.
23 * * * Request = timed=20 out.
24 * * * Request timed out.
25 * * * Request timed out.
26 = * * *=20 Request timed out.
27 * * * Request timed out.
28 * * * Request = timed=20 out.
29 * * * Request timed out.
30 * * * Request timed = out.

Trace=20 complete.


 Jeroen Massar SixXS on Friday, 09 = December 2011=20 20:15:39
> = Tracing=20 route to www.ipv6-db.com [2610:d0:2113:3::3]

That is a LISP = prefix, there=20 is some kind of magical routing involved there and it is all quite=20 experimental.

See Cisco's LISP and the LISP=20 beta site site for more details.

Please contact the site = operator or=20 the LISP WG to resolve this. There is nothing much we can do about = this.
 
 
 
BTW I = cant reach=20 the lisp website over ipv4 either:
 
 
C:\My = Program=20 Files\Windows Resource Kits\Tools>tracert www.lisp4.net
 
Tracing = route to=20 noc.eid.lisp4.net [153.16.10.11]
over a maximum of 30 hops:
 
 =20 1     1 ms     3=20 ms     5 ms  homerouter.windows.home=20 [192.168.1.1]
  2    29 ms    30=20 ms    29 ms  lo0-central3.thn-ag2.plus.net=20 [195.166.128.231]
  3    82 ms   212=20 ms   205 ms  gi1-11-231.thn-gw1.plus.net = [84.92.6.208]
 =20 4    29 ms    29 ms    28 = ms =20 po4.thn-gw2.plus.net [212.159.1.135]
  5    29=20 ms    29 ms    28 ms  = 195.66.225.24
 =20 6    49 ms    75 ms    49 = ms =20 dk-ore.nordu.net [109.105.97.30]
  7    52=20 ms    58 ms    55 ms  = dk-uni.nordu.net=20 [109.105.97.14]
  8    59 ms    60 = ms    60 ms  stolav-gw2.uninett.no=20 [109.105.102.26]
  9    63 ms    = 64=20 ms   143 ms  oslo-gw.uninett.no=20 [128.39.255.85]
 10    80 ms    71 = ms    70 ms  trd-gw1.uninett.no=20 [128.39.255.110]
 11    71 ms    = 71=20 ms    70 ms  trd-gw7.uninett.no=20 [128.39.255.214]
 12    71 ms    = 71=20 ms    71 ms  uninett-pxtr.rloc.lisp4.net=20 [158.38.1.92]
 13    =20 *       =20 *        *     = Request=20 timed out.
 14    =20 *       =20 *        *     = Request=20 timed out.
 15    =20 *       =20 *        *     = Request=20 timed out.
 16    =20 *       =20 *        *     = Request=20 timed out.
 17    =20 *       =20 *        *     = Request=20 timed out.
 18    =20 *       =20 *        *     = Request=20 timed out.
 19    =20 *       =20 *        *     = Request=20 timed out.
 20    =20 *       =20 *        *     = Request=20 timed out.
 21    =20 *       =20 *        *     = Request=20 timed out.
 22    =20 *       =20 *        *     = Request=20 timed out.
 23    =20 *       =20 *        *     = Request=20 timed out.
 24    =20 *       =20 *        *     = Request=20 timed out.
 25    =20 *       =20 *        *     = Request=20 timed out.
 26    =20 *       =20 *        *     = Request=20 timed out.
 27    =20 *       =20 *        *     = Request=20 timed out.
 28    =20 *       =20 *        *     = Request=20 timed out.
 29    =20 *       =20 *        *     = Request=20 timed out.
 30    =20 *       =20 *        *     = Request=20 timed out.
 
Trace=20 complete.
------=_NextPart_000_075A_01CCB73E.85413400-- From ljakab@ac.upc.edu Sun Dec 11 02:44:06 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E2B21F84B5 for ; Sun, 11 Dec 2011 02:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR+puphEYxKP for ; Sun, 11 Dec 2011 02:44:04 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADB921F84B8 for ; Sun, 11 Dec 2011 02:44:03 -0800 (PST) Received: from [192.168.0.192] (unknown [89.7.81.17]) by gw.ac.upc.edu (Postfix) with ESMTP id 29B7B2D0001; Sun, 11 Dec 2011 11:43:58 +0100 (CET) Message-ID: <4EE4896A.6060402@ac.upc.edu> Date: Sun, 11 Dec 2011 11:43:54 +0100 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Markus Moeller References: <14C67F00997342E48A803652F6FEE7AB@VAIOLaptop> In-Reply-To: <14C67F00997342E48A803652F6FEE7AB@VAIOLaptop> OpenPGP: id=90710D74; url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc X-OpenPGP-Fingerprint: 5EBC 8566 7524 D711 F210 9D80 954C 0DEF 9071 0D74 X-Philosophy: "Simplicity is the ultimate sophistication." --Leonardo da Vinci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp-support@cisco.com, lisp@ietf.org Subject: Re: [lisp] Can not reach IPv6 site via LISP network X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 10:44:07 -0000 Hi Markus, The LISP WG mailing list is dedicated to the LISP standardization effort, so these kind of questions are better directed to the people operating the LISP beta network. Here are a few things you can try when debugging LISP related issues: * Check if the LISP mapping system knows about the destination you want to reach. You can use the open source 'lig' utility from one of your hosts not behind a firewall/NAT, or simply this LISP looking glass: http://lispmon.net/lig.cgi * Check the status page of all LISP sites http://www.lisp4.net/lisp-site/ If you try the first step, you will see: # lig -m intouch-ams-mr-ms-1.rloc.lisp4.net www.ipv6-db.com Send map-request to intouch-ams-mr-ms-1.rloc.lisp4.net for www.ipv6-db.com ... Received map-reply from 85.184.2.42 with rtt 0.05900 secs Mapping entry for EID '2610:d0:2113:3::3': 2610:d0:2113::/48, via map-reply, record ttl: 1, not auth, not mobile Negative cache entry, action: forward-native The negative cache entry hints at one of two things: the destination is either not a LISP site, or if it is, it is currently not registering to the LISP mapping system. If you check the second step, and you seach that page for the prefix 2610:d0:2113, you will find it on the list, so it is a LISP site. However, the third column shows that is not active at the moment. You should probably contact the people managing the LISP routers for that prefix, but I think that contact info is not public, the LISP beta network operators can put you in contact. Regards, -Lori On 12/10/11 14:20, Markus Moeller wrote: > Hi, > > I try to connect to a website on the ipv network and my ISP tells me > it is a problem with the LISP prefix. I was asked to rais it with the WG. > > Thank you > Markus > > > > *Can not reach server on ipv6 network* > [gb] Markus Moeller on Friday, 09 December 2011 19:59:04 > Here are the traceroute details for the not working site: > C:\My Program Files\Windows Resource Kits\Tools>tracert www.ipv6-db.com > > Tracing route to www.ipv6-db.com [2610:d0:2113:3::3] > over a maximum of 30 hops: > > 1 31 ms 28 ms 29 ms gw-1326.lon-02.gb.sixxs.net [2a01:348:6:52d::1] > 2 28 ms 28 ms 29 ms ge-0-0-5-20.cs0.thw.uk.goscomb.net > [2a01:348:0:4:0:3:0:1] > 3 30 ms 31 ms 29 ms xe-0-0-0.rt0.the.uk.goscomb.net [2a01:348::27:0:1] > 4 28 ms 31 ms 30 ms lonap.he.net [2001:7f8:17::1b1b:1] > 5 97 ms 100 ms 96 ms 10gigabitethernet7-4.core1.nyc4.he.net > [2001:470:0:3e::1] > 6 120 ms 116 ms 124 ms 10gigabitethernet8-3.core1.chi1.he.net > [2001:470:0:1c6::2] > 7 189 ms 190 ms 187 ms 2001:470:1:34::2 > 8 187 ms 188 ms 191 ms iana.r1.ord1.isc.org [2001:500:71:6::1] > 9 189 ms 207 ms 204 ms int-0-0-1-8.r1.pao1.isc.org [2001:4f8:0:1::4a:1] > 10 190 ms 191 ms 191 ms int-0-1-0-0.r1.sql1.isc.org [2001:4f8:1b:1::8:2] > 11 187 ms * 187 ms lisp-r1.sql1.isc.org [2001:4f8:3:d::60] > 12 * * * Request timed out. > 13 * * * Request timed out. > 14 * * * Request timed out. > 15 * * * Request timed out. > 16 * * * Request timed out. > 17 * * * Request timed out. > 18 * * * Request timed out. > 19 * * * Request timed out. > 20 * * * Request timed out. > 21 * * * Request timed out. > 22 * * * Request timed out. > 23 * * * Request timed out. > 24 * * * Request timed out. > 25 * * * Request timed out. > 26 * * * Request timed out. > 27 * * * Request timed out. > 28 * * * Request timed out. > 29 * * * Request timed out. > 30 * * * Request timed out. > > Trace complete. > > > Jeroen Massar SixXS on Friday, 09 December 2011 20:15:39 > > Tracing route to www.ipv6-db.com [2610:d0:2113:3::3] > > That is a LISP prefix, there is some kind of magical routing involved > there and it is all quite experimental. > > See Cisco's LISP and the LISP beta site site for more details. > > Please contact the site operator or the LISP WG to resolve this. There > is nothing much we can do about this. > > > > BTW I cant reach the lisp website over ipv4 either: > > > C:\My Program Files\Windows Resource Kits\Tools>tracert www.lisp4.net > > > Tracing route to noc.eid.lisp4.net [153.16.10.11] > over a maximum of 30 hops: > > 1 1 ms 3 ms 5 ms homerouter.windows.home [192.168.1.1] > 2 29 ms 30 ms 29 ms lo0-central3.thn-ag2.plus.net > [195.166.128.231] > 3 82 ms 212 ms 205 ms gi1-11-231.thn-gw1.plus.net [84.92.6.208] > 4 29 ms 29 ms 28 ms po4.thn-gw2.plus.net [212.159.1.135] > 5 29 ms 29 ms 28 ms 195.66.225.24 > 6 49 ms 75 ms 49 ms dk-ore.nordu.net [109.105.97.30] > 7 52 ms 58 ms 55 ms dk-uni.nordu.net [109.105.97.14] > 8 59 ms 60 ms 60 ms stolav-gw2.uninett.no [109.105.102.26] > 9 63 ms 64 ms 143 ms oslo-gw.uninett.no [128.39.255.85] > 10 80 ms 71 ms 70 ms trd-gw1.uninett.no [128.39.255.110] > 11 71 ms 71 ms 70 ms trd-gw7.uninett.no [128.39.255.214] > 12 71 ms 71 ms 71 ms uninett-pxtr.rloc.lisp4.net [158.38.1.92] > 13 * * * Request timed out. > 14 * * * Request timed out. > 15 * * * Request timed out. > 16 * * * Request timed out. > 17 * * * Request timed out. > 18 * * * Request timed out. > 19 * * * Request timed out. > 20 * * * Request timed out. > 21 * * * Request timed out. > 22 * * * Request timed out. > 23 * * * Request timed out. > 24 * * * Request timed out. > 25 * * * Request timed out. > 26 * * * Request timed out. > 27 * * * Request timed out. > 28 * * * Request timed out. > 29 * * * Request timed out. > 30 * * * Request timed out. > > Trace complete. > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ljakab@ac.upc.edu Sun Dec 11 05:53:14 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5919621F8A7B for ; Sun, 11 Dec 2011 05:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFKu0e6uPf0c for ; Sun, 11 Dec 2011 05:53:13 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3C921F8AD8 for ; Sun, 11 Dec 2011 05:53:12 -0800 (PST) Received: from [192.168.0.192] (unknown [89.7.81.17]) by gw.ac.upc.edu (Postfix) with ESMTP id F15DB6B0249; Sun, 11 Dec 2011 14:53:10 +0100 (CET) Message-ID: <4EE4B5C6.801@ac.upc.edu> Date: Sun, 11 Dec 2011 14:53:10 +0100 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Markus PlusNet References: <14C67F00997342E48A803652F6FEE7AB@VAIOLaptop> <4EE4896A.6060402@ac.upc.edu> <9B3831AC4C0D4A239C29AD194CC9B7D2@VAIOLaptop> In-Reply-To: <9B3831AC4C0D4A239C29AD194CC9B7D2@VAIOLaptop> OpenPGP: id=90710D74; url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc X-OpenPGP-Fingerprint: 5EBC 8566 7524 D711 F210 9D80 954C 0DEF 9071 0D74 X-Philosophy: "Simplicity is the ultimate sophistication." --Leonardo da Vinci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp-support@cisco.com, lisp@ietf.org Subject: Re: [lisp] Can not reach IPv6 site via LISP network X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 13:53:14 -0000 Hi Markus, On 12/11/11 14:27, Markus PlusNet wrote: > Hi Lori, > > Apologies if I sent it to the wrong list. > > When you say "However, the third column shows that is not active at > the moment". What is not active ? LISP introduces an additional component, called the mapping system, which maps the identifier 2610:d0:2113:3::3 to a routing locator. This mapping fails currently. See this IP Journal article for an overview of how LISP works, or check the latest drafts for details: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-1/111_lisp.html > If I check www.ipv6-db.com at > http://ipv6-test.com/validate.php the site is responding as > > Checking for AAAA DNS record2610:d0:2113:3::3 This only means that the DNS lookup for www.ipv6-db.com works. > Checking for IPv6 web serverApache/2.2.10 (Linux/SUSE) This is strange, I assume it might be related to caching results on the ipv6-test.com web site? I certainly cannot telnet to port 80 of www.ipv6-db.com. Regards, -Lori > > Thank you > Markus > > ----- Original Message ----- From: "Lori Jakab" > To: "Markus Moeller" > Cc: ; > Sent: Sunday, December 11, 2011 10:43 AM > Subject: Re: [lisp] Can not reach IPv6 site via LISP network > > >> Hi Markus, >> >> The LISP WG mailing list is dedicated to the LISP standardization >> effort, so these kind of questions are better directed to the people >> operating the LISP beta network. >> >> Here are a few things you can try when debugging LISP related issues: >> >> * Check if the LISP mapping system knows about the destination you >> want to reach. You can use the open source 'lig' utility from one of >> your hosts not behind a firewall/NAT, or simply this LISP looking >> glass: http://lispmon.net/lig.cgi >> * Check the status page of all LISP sites >> http://www.lisp4.net/lisp-site/ >> >> If you try the first step, you will see: >> # lig -m intouch-ams-mr-ms-1.rloc.lisp4.net www.ipv6-db.com >> Send map-request to intouch-ams-mr-ms-1.rloc.lisp4.net for >> www.ipv6-db.com ... >> Received map-reply from 85.184.2.42 with rtt 0.05900 secs >> >> Mapping entry for EID '2610:d0:2113:3::3': >> 2610:d0:2113::/48, via map-reply, record ttl: 1, not auth, not mobile >> Negative cache entry, action: forward-native >> >> The negative cache entry hints at one of two things: the destination is >> either not a LISP site, or if it is, it is currently not registering to >> the LISP mapping system. >> >> If you check the second step, and you seach that page for the prefix >> 2610:d0:2113, you will find it on the list, so it is a LISP site. >> However, the third column shows that is not active at the moment. You >> should probably contact the people managing the LISP routers for that >> prefix, but I think that contact info is not public, the LISP beta >> network operators can put you in contact. >> >> Regards, >> -Lori >> >> On 12/10/11 14:20, Markus Moeller wrote: >>> Hi, >>> >>> I try to connect to a website on the ipv network and my ISP tells me >>> it is a problem with the LISP prefix. I was asked to rais it with >>> the WG. >>> >>> Thank you >>> Markus >>> >>> >>> >>> *Can not reach server on ipv6 network* >>> [gb] Markus Moeller on Friday, 09 December 2011 19:59:04 >>> Here are the traceroute details for the not working site: >>> C:\My Program Files\Windows Resource Kits\Tools>tracert www.ipv6-db.com >>> >>> Tracing route to www.ipv6-db.com [2610:d0:2113:3::3] >>> over a maximum of 30 hops: >>> >>> 1 31 ms 28 ms 29 ms gw-1326.lon-02.gb.sixxs.net [2a01:348:6:52d::1] >>> 2 28 ms 28 ms 29 ms ge-0-0-5-20.cs0.thw.uk.goscomb.net >>> [2a01:348:0:4:0:3:0:1] >>> 3 30 ms 31 ms 29 ms xe-0-0-0.rt0.the.uk.goscomb.net [2a01:348::27:0:1] >>> 4 28 ms 31 ms 30 ms lonap.he.net [2001:7f8:17::1b1b:1] >>> 5 97 ms 100 ms 96 ms 10gigabitethernet7-4.core1.nyc4.he.net >>> [2001:470:0:3e::1] >>> 6 120 ms 116 ms 124 ms 10gigabitethernet8-3.core1.chi1.he.net >>> [2001:470:0:1c6::2] >>> 7 189 ms 190 ms 187 ms 2001:470:1:34::2 >>> 8 187 ms 188 ms 191 ms iana.r1.ord1.isc.org [2001:500:71:6::1] >>> 9 189 ms 207 ms 204 ms int-0-0-1-8.r1.pao1.isc.org [2001:4f8:0:1::4a:1] >>> 10 190 ms 191 ms 191 ms int-0-1-0-0.r1.sql1.isc.org >>> [2001:4f8:1b:1::8:2] >>> 11 187 ms * 187 ms lisp-r1.sql1.isc.org [2001:4f8:3:d::60] >>> 12 * * * Request timed out. >>> 13 * * * Request timed out. >>> 14 * * * Request timed out. >>> 15 * * * Request timed out. >>> 16 * * * Request timed out. >>> 17 * * * Request timed out. >>> 18 * * * Request timed out. >>> 19 * * * Request timed out. >>> 20 * * * Request timed out. >>> 21 * * * Request timed out. >>> 22 * * * Request timed out. >>> 23 * * * Request timed out. >>> 24 * * * Request timed out. >>> 25 * * * Request timed out. >>> 26 * * * Request timed out. >>> 27 * * * Request timed out. >>> 28 * * * Request timed out. >>> 29 * * * Request timed out. >>> 30 * * * Request timed out. >>> >>> Trace complete. >>> >>> >>> Jeroen Massar SixXS on Friday, 09 December 2011 20:15:39 >>> > Tracing route to www.ipv6-db.com [2610:d0:2113:3::3] >>> >>> That is a LISP prefix, there is some kind of magical routing involved >>> there and it is all quite experimental. >>> >>> See Cisco's LISP and the LISP beta site site for more details. >>> >>> Please contact the site operator or the LISP WG to resolve this. There >>> is nothing much we can do about this. >>> >>> >>> >>> BTW I cant reach the lisp website over ipv4 either: >>> >>> >>> C:\My Program Files\Windows Resource Kits\Tools>tracert www.lisp4.net >>> >>> >>> Tracing route to noc.eid.lisp4.net [153.16.10.11] >>> over a maximum of 30 hops: >>> >>> 1 1 ms 3 ms 5 ms homerouter.windows.home [192.168.1.1] >>> 2 29 ms 30 ms 29 ms lo0-central3.thn-ag2.plus.net >>> [195.166.128.231] >>> 3 82 ms 212 ms 205 ms gi1-11-231.thn-gw1.plus.net >>> [84.92.6.208] >>> 4 29 ms 29 ms 28 ms po4.thn-gw2.plus.net [212.159.1.135] >>> 5 29 ms 29 ms 28 ms 195.66.225.24 >>> 6 49 ms 75 ms 49 ms dk-ore.nordu.net [109.105.97.30] >>> 7 52 ms 58 ms 55 ms dk-uni.nordu.net [109.105.97.14] >>> 8 59 ms 60 ms 60 ms stolav-gw2.uninett.no [109.105.102.26] >>> 9 63 ms 64 ms 143 ms oslo-gw.uninett.no [128.39.255.85] >>> 10 80 ms 71 ms 70 ms trd-gw1.uninett.no [128.39.255.110] >>> 11 71 ms 71 ms 70 ms trd-gw7.uninett.no [128.39.255.214] >>> 12 71 ms 71 ms 71 ms uninett-pxtr.rloc.lisp4.net >>> [158.38.1.92] >>> 13 * * * Request timed out. >>> 14 * * * Request timed out. >>> 15 * * * Request timed out. >>> 16 * * * Request timed out. >>> 17 * * * Request timed out. >>> 18 * * * Request timed out. >>> 19 * * * Request timed out. >>> 20 * * * Request timed out. >>> 21 * * * Request timed out. >>> 22 * * * Request timed out. >>> 23 * * * Request timed out. >>> 24 * * * Request timed out. >>> 25 * * * Request timed out. >>> 26 * * * Request timed out. >>> 27 * * * Request timed out. >>> 28 * * * Request timed out. >>> 29 * * * Request timed out. >>> 30 * * * Request timed out. >>> >>> Trace complete. >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> > > From internet-drafts@ietf.org Thu Dec 15 11:37:29 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B62211E8095; Thu, 15 Dec 2011 11:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukpiBPvX7Iux; Thu, 15 Dec 2011 11:37:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE8C21F846A; Thu, 15 Dec 2011 11:37:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111215193729.29597.45999.idtracker@ietfa.amsl.com> Date: Thu, 15 Dec 2011 11:37:29 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-18.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 19:37:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-18.txt Pages : 95 Date : 2011-12-15 This draft describes a network layer based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-18.txt From internet-drafts@ietf.org Fri Dec 16 17:49:24 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7536A1F0C57; Fri, 16 Dec 2011 17:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dULbQhbIqTeK; Fri, 16 Dec 2011 17:49:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4D81F0C4D; Fri, 16 Dec 2011 17:49:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111217014923.10471.14920.idtracker@ietfa.amsl.com> Date: Fri, 16 Dec 2011 17:49:23 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ms-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 01:49:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map Server Interface Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-14.txt Pages : 16 Date : 2011-12-16 This draft describes the Maping Service for the Locator Identifier Separation Protocol (LISP), implemented by two new types of LISP- speaking devices, the LISP Map Resolver and LISP Map Server, that provides a simplified "front end" to for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map Resolvers and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers, are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-ms-14.txt From vaf@cisco.com Fri Dec 16 17:59:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501921F0C4D for ; Fri, 16 Dec 2011 17:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.907 X-Spam-Level: X-Spam-Status: No, score=-4.907 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HTML_COMMENT_SAVED_URL=0.114, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD280RHxKCOG for ; Fri, 16 Dec 2011 17:59:48 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E3BE91F0C3B for ; Fri, 16 Dec 2011 17:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=125818; q=dns/txt; s=iport; t=1324087188; x=1325296788; h=date:from:to:subject:message-id:mime-version; bh=CLKwQz2vEDIHulBQiCRs4uWhulHkkWyKkOcgNY00mAQ=; b=DSzCPZD2ca13+dHMvY7ajE16vzG0rNVzu7xOzcyLmRtz9PSfqbOKneIF dtCq9d7IMqRF+3seQBvZgJNhXvgKeDY+UJ0BdlZubX6b/HFa3CfFRplGs UUpvCoY8xkEzaGmD+zc7wtGu4zvsstpcT3q2ZCg4gO2rriXCQu03Q5Bs4 c=; X-Files: rfcdiff-ms-13-to-14.html : 117677 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAtAEL3606rRDoJ/2dsb2JhbABEmE2RcIEZgQWBcgEBAQUBAQ8BBwESGiAFAggeEQECAQIPEgEhEwUaAwYhCRmHYJgRgSYBkDmNcoshYwSINIVohlmKcIde X-IronPort-AV: E=Sophos;i="4.71,366,1320624000"; d="html'217?scan'217,208,217";a="21225054" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 17 Dec 2011 01:59:46 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBH1xjh4031117 for ; Sat, 17 Dec 2011 01:59:45 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 1DC111B5F5DB; Fri, 16 Dec 2011 17:59:45 -0800 (PST) Date: Fri, 16 Dec 2011 17:59:44 -0800 From: Vince Fuller To: lisp@ietf.org Message-ID: <20111217015944.GA32834@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Re: [lisp] I-D Action: draft-ietf-lisp-ms-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 01:59:50 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This includes two significant changes made: - removal of partial, detailed description of Map Resolver caching - removal of detailed description of "S-Bit"/LISP-SEC processing The removed text described incomplete, future work that either caused an unresolvable "normative reference" (to LISP-SEC) or did not, in the opinion of one reviewing IESG member, provide sufficient detail about possible implementation and operational issues. The intent of eliminating these sections remove IESG process "DISCUSS" blockages and facilitate publication as an EXPERIMENTAL RFC. rfcdiff output is attached. --Vince ----- Forwarded message from internet-drafts@ietf.org ----- Date: Fri, 16 Dec 2011 17:49:23 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: lisp@ietf.org Subject: I-D Action: draft-ietf-lisp-ms-14.txt X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAP7z604MFjoemWdsb2JhbABEq1YiAQEBAQEICwsHFCWBdAEFAQEPAScGAQEECh4LAQIDAQIGAkAICAMBI0kFBBmHYJk4AYtxhB0BjhQHiGqDGog4jEEBim+HXg X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only Errors-To: i-d-announce-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Map Server Interface Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-14.txt Pages : 16 Date : 2011-12-16 This draft describes the Maping Service for the Locator Identifier Separation Protocol (LISP), implemented by two new types of LISP- speaking devices, the LISP Map Resolver and LISP Map Server, that provides a simplified "front end" to for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map Resolvers and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers, are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-ms-14.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- --6TrnltStXW4iwmi0 Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="rfcdiff-ms-13-to-14.html" Content-Transfer-Encoding: quoted-printable wdiff draft-ietf-lisp-ms-13.txt draft-ietf-lisp-ms-14= .txt 
Network Working Group                                          V. Fuller
Internet-Draft                                              D. Farinacci
Intended status: Experimental                              cisco Systems
Expires: June 8, 18, 2012                                 De=
cember 6, 16, 2011

                       LISP Map Server Interface
                       draft-ietf-lisp-ms-13.tx=
t
                       draft-ietf-lisp-ms-14.=
txt

Abstract

   This draft describes the Maping Service for the Locator Identifier
   Separation Protocol (LISP), implemented by two new types of LISP-
   speaking devices, the LISP Map Resolver and LISP Map Server, that
   provides a simplified "front end" to for one or more Endpoint ID to
   Routing Locator mapping databases.

   By using this service interface and communicating with Map Resolvers
   and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel
   Routers, are not dependent on the details of mapping database
   systems, which facilitates experimentation with different database
   designs.  Since these devices implement the "edge" of the LISP
   infrastructure, connect directly to LISP-capable Internet end sites,
   and comprise the bulk of LISP-speaking devices, reducing their
   implementation and operational complexity should also reduce the
   overall cost and effort of deploying LISP.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 8, 18, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  4
   3.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Interactions With Other LISP Components  . . . . . . . . . . .  7  6<=
/font>
     4.1.  ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . .  7  6<=
/font>
     4.2.  EID Prefix Configuration and ETR Registration  . . . . . .  8  7<=
/font>
     4.3.  Map Server Processing  . . . . . . . . . . . . . . . . . .  9  8<=
/font>
     4.4.  Map Resolver Processing  . . . . . . . . . . . . . . . . . 10  9<=
/font>
       4.4.1.  Anycast Map Resolver Operation . . . . . . . . . . . . 12 10<=
/font>
   5.  Open Issues and Considerations . . . . . . . . . . . . . . . . 13 11<=
/font>
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14 12<=
/font>
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15 13<=
/font>
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 14<=
/font>
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16 14<=
/font>
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16 14<=
/font>
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 18 15<=
/font>
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 16<=
/font>

1.  Introduction

   [LISP], the Locator Identifier Separation Protocol, specifies an
   architecture and mechanism for replacing the addresses currently used
   by IP with two separate name spaces: Endpoint IDs (EIDs), used within
   sites, and Routing Locators (RLOCs), used on the transit networks
   that make up the Internet infrastructure.  To achieve this
   separation, LISP defines protocol mechanisms for mapping from EIDs to
   RLOCs.  In addition, LISP assumes the existence of a database to
   store and propagate those mappings globally.  Several such databases
   have been proposed, among them: LISP-CONS [CONS], LISP-NERD, [NERD]
   and LISP+ALT [ALT].

   The LISP Mapping Service defines two new types of LISP-speaking
   devices: the Map Resolver, which accepts Map-Requests from an Ingress
   Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a
   mapping database, and the Map Server, which learns authoritative EID-
   to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes
   them in a database.

   Conceptually, LISP Map Servers share some of the same basic
   configuration and maintenance properties as Domain Name System (DNS)
   [RFC1035] servers; likewise, Map Resolvers are conceptually similar
   to DNS caching resolvers.  With this in mind, this specification
   borrows familiar terminology (resolver and server) from the DNS
   specifications.

   Note that while this document assumes a LISP+ALT database mapping
   infrastructure to illustrate certain aspects of Map Server and Map
   Resolver operation, the Mapping Service interface can (and likely
   will) be used by ITRs and ETRs to access other mapping database
   systems as the LISP infrastructure evolves.

2.  Definition of Terms

   Map Server:   a network infrastructure component which learns of EID-
      prefix mapping entries from an ETR, via the registration mechanism
      described below, or some other authoritative source if one exists.
      A Map Server publishes these EID-prefixes in a mapping database.

   Map Resolver:   a network infrastructure component which accepts LISP
      Encapsulated Map-Requests, typically from an ITR, determines
      whether or not the destination IP address is part of the EID
      namespace; if it is not, a Negative Map-Reply is returned.
      Otherwise, the Map Resolver finds the appropriate EID-to-RLOC
      mapping by consulting a mapping database system.

   Encapsulated Map-Request:   a LISP Map-Request carried within an
      Encapsulated Control Message, which has an additional LISP header
      prepended.  Sent to UDP destination port 4342.  The "outer"
      addresses are globally-routeable IP addresses, also known as
      RLOCs.  Used by an ITR when sending to a Map Resolver and by a Map
      Server when forwarding a Map-Request to an ETR.

   Negative Map-Reply:   a LISP Map-Reply that contains an empty
      locator-set.  Returned in response to a Map-Request if the
      destination EID does not exist in the mapping database.
      Typically, this means that the "EID" being requested is an IP
      address connected to a non-LISP site.

   Map-Register message:   a LISP message sent by an ETR to a Map Server
      to register its associated EID-prefixes.  In addition to the set
      of EID-prefixes to register, the message includes one or more
      RLOCs to be be used by the Map Server when forwarding Map-Requests
      (re-formatted as Encapsulated Map-Requests) received through the
      database mapping system.  An ETR may request that the Map Server
      answer Map-Requests on its behalf by setting the "proxy-map-reply"
      flag (P-bit) in the message.

   Map-Notify message:   a LISP message sent by a Map Server to an ETR
      to confirm that a Map-Register has been received and processed.
      An ETR requests that a Map-Notify be returned by setting the
      "want-map-notify" or "M" bit in the Map-Register message.  Unlike
      a Map-Reply, a Map-Notify uses UDP port 4342 for both source and
      destination.

   For definitions of other terms, notably Map-Request, Map-Reply,
   Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please
   consult the LISP specification [LISP].

3.  Basic Overview

   A Map Server is a device which publishes EID-prefixes in a LISP
   mapping database on behalf of a set of ETRs.  When it receives a Map
   Request (typically from an ITR) it consults the mapping database to
   find an ETR that can answer with the set of RLOCs for an EID-prefix.
   To publish its EID-prefixes, an ETR periodically sends Map-Register
   messages to the Map Server.  A Map-Register message contains a list
   of EID-prefixes plus a set of RLOCs that can be used to reach the ETR
   when a Map Server needs to forward a Map-Request to it.

   When LISP+ALT is used as the mapping database, a Map Server connects
   to ALT network and acts as a "last-hop" ALT router.  Intermediate ALT
   routers forward Map-Requests to the Map Server that advertises a
   particular EID-prefix and the Map Server forwards them to the owning
   ETR, which responds with Map-Reply messages.

   A Map Resolver receives Encapsulated Map-Requests from its client
   ITRs and uses a mapping database system to find the appropriate ETR
   to answer those requests.  On a LISP+ALT network, a Map Resolver acts
   as a "first-hop" ALT router.  It has GRE tunnels configured to other
   ALT routers and uses BGP to learn paths to ETRs for different
   prefixes in the LISP+ALT database.  The Map Resolver uses this path
   information to forward Map-Requests over the ALT to the correct ETRs.
   During initial deployment,

   Note that while it is conceivable that a Map Resolver could cache
   responses to improve performance, issues surrounding cache management
   will need to be resolved for doing so to be reliable and practical.
   As initially deployed, Map Resolvers will operate only i=
n a non-
   caching mode, where it simply de-capsulates<=
/font> de-decapsulating and forwards the forwarding Encapsulated Map-Requests that it receives from ITRs.

   In future deployments, a Map Resolver may operate in a caching mode,
   where it saves information about outstanding Map-Requests, originates
   new Map-Requests to the correct ETR(s), accepts and caches the Map-
   Replies, and finally forwards the Map-Replies to the original
   Requests received from ITR=
s.
   One significant issue with use  Any specification of cach=
ing in a Map Resolver
   functionality is <=
font color=3D"red">that
   it hides the original ITR source of a Map-Request, which prevents an
   ETR from tailoring its responses to that source; this reduces the
   inbound traffic- engineering capability left for the site=
 owning the ETR.
   In addition, caching in a Map Resolver exacerbates problems
   associated with old mappings being cached; an outdated, cached
   mapping in an ITR affects only that ITR and traffic originated by its
   site while an outdated, cached mapping in a Map Resolver could cause
   a problem with a wider scope.  More experience with caching Map
   Resolvers on the LISP pilot network will be needed to determine
   whether their use can be recommended. future work.

   Note that a single device can implement the functions of both a Map
   Server and a Map Resolver and, in many cases, the functions will be
   co-located in that way.

   Detailed descriptions of the LISP packet types referenced by this
   document may be found in [LISP].

4.  Interactions With Other LISP Components

4.1.  ITR EID-to-RLOC Mapping Resolution

   An ITR is configured with one or more Map Resolver addresses.  These
   addresses are "locators" (or RLOCs) and must be routeable on the
   underlying core network; they must not need to be resolved through
   LISP EID-to-RLOC mapping as that would introduce a circular
   dependency.  When using a Map Resolver, an ITR does not need to
   connect to any other database mapping system.  In particular, the ITR
   need not connect to the LISP+ALT infrastructure or implement the BGP
   and GRE protocols that it uses.

   An ITR sends an Encapsulated Map-Request to a configured Map Resolver
   when it needs an EID-to-RLOC mapping that is not found in its local
   map-cache.  Using the Map Resolver greatly reduces both the
   complexity of the ITR implementation and the costs associated with
   its operation.

   In response to an Encapsulated Map-Request, the ITR can expect one of
   the following:

   o  An immediate Negative Map-Reply (with action code of "forward-
      native", 15-minute TTL) from the Map Resolver if the Map Resolver
      can determine that the requested EID does not exist.  The ITR
      saves the EID-prefix returned in the Map-Reply in its cache,
      marking it as non-LISP-capable and knows not to attempt LISP
      encapsulation for destinations matching it.

   o  A Negative Map-Reply (with action code of "forward-native") from
      the Map Server that has an aggregate EID-covering the EID in the
      Map-Request but where the EID matches a "hole" in the aggregate.
      If the "hole" is for a LISP EID-prefix that is defined in the Map
      Server configuration but for which no ETRs are currently
      registered, a 1-minute TTL is returned.  If the "hole" is for an
      unassigned part of the aggregate, then it is not a LISP EID and a
      15-minute TTL is returned.  See Section 4.2 for discussion of
      aggregate EID-prefixes and details of Map Server EID-prefix
      matching.

   o  A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
      possibly from a Map Server answering on behalf of the ETR.  See
      (Section 4.4) for more details on Map Resolver message processing.

   Note that an ITR may be configured to both use a Map Resolver and to
   participate in a LISP+ALT logical network.  In such a situation, the
   ITR should send Map-Requests through the ALT network for any EID-
   prefix learned via ALT BGP.  Such a configuration is expected to be
   very rare, since there is little benefit to using a Map Resolver if
   an ITR is already using LISP+ALT.  There would be, for example, no
   need for such an ITR to send a Map-Request to a possibly non-existent
   EID (and rely on Negative Map-Replies) if it can consult the ALT
   database to verify that an EID-prefix is present before sending that
   Map-Request.

4.2.  EID Prefix Configuration and ETR Registration

   An ETR publishes its EID-prefixes on a Map Server by sending LISP
   Map-Register messages.  A Map-Register message includes
   authentication data, so prior to sending a Map-Register message, the
   ETR and Map Server must be configured with a shared secret or other
   relevant authentication information.  A Map Server's configuration
   must also include a list of the EID-prefixes for which each ETR is
   authoritative.  Upon receipt of a Map-Register from an ETR, a Map
   Server accepts only EID-prefixes that are configured for that ETR.
   Failure to implement such a check would leave the mapping system
   vulnerable to trivial EID-prefix hijacking attacks.  As developers
   and operators gain experience with the mapping system, additional,
   stronger security measures may be added to the registration process.

   In addition to the set of EID-prefixes defined for each ETR that may
   register, a Map Server is typically also configured with one or more
   aggregate prefixes that define the part of the EID numbering space
   assigned to it.  When LISP+ALT is the database in use, aggregate EID-
   prefixes are implemented as discard routes and advertised into ALT
   BGP.  The existance of aggregate EID-prefixes in a Map Server's
   database means that it may receive Map Requests for EID-prefixes that
   match an aggregate but do not match a registered prefix; Section 4.3
   describes how this is handled.

   Map-Register messages are sent periodically from an ETR to a Map
   Server with a suggested interval between messages of one minute.  A
   Map Server should time-out and remove an ETR's registration if it has
   not received a valid Map-Register message within the past three
   minutes.  When first contacting a Map Server after restart or changes
   to its EID-to-RLOC database mappings, an ETR may initially send Map-
   Register messages at an increased frequency, up to one every 20
   seconds.  This "quick registration" period is limited to five minutes
   in duration.

   An ETR may request that a Map Server explicitly acknowledge receipt
   and processing of a Map-Register message by setting the "want-map-
   notify" ("M" bit) flag.  A Map Server that receives a Map-Register
   with this flag set will respond with a Map-Notify message.  Typical
   use of this flag by an ETR would be to set it for Map-Register
   messages sent during the initial "quick registration" with a Map
   Server but then set it only occasionally during steady-state
   maintenance of its association with that Map Server.  Note that the
   Map-Notify message is sent to UDP destination port 4342, not to the
   source port specified in the original Map-Register message.

   Note that a one-minute minimum registration interval during
   maintenance of an ETR-MS association places a lower-bound on how
   quickly and how frequently a mapping database entry can be updated.
   This may have implications for what sorts of mobility can be
   supported directly by the mapping system; shorter registration
   intervals or other mechanisms might be needed to suopport faster
   mobility in some cases.  For a discussion on one way that faster
   mobility may be implemented for individual devices, please see
   [LISP-MN].

   An ETR may also request, by setting the "proxy-map-reply" flag
   (P-bit) in the Map-Register message, that a Map Server answer Map-
   Requests instead of forwarding them to the ETR.  See [LISP] for
   details on how the Map Server sets certain flags (such as those
   indicating whether the message is authoritative and how returned
   locators should be treated) when sending a Map-Reply on behalf of an
   ETR.  When an ETR requests proxy reply service, it should include all
   RLOCs for all ETRs for the EID-prefix being registered, along with
   the routable flag ("R-bit") setting for each RLOC.  The Map Server
   includes all of this information in Map Reply messages that it sends
   on behalf of the ETR.  This differs from a non-proxy registration
   since the latter need only provide one or more RLOCs for a Map Server
   to use for forwarding Map-Requests; the registration information is
   not used in Map-Replies so it being incomplete is not incorrect.

   An ETR which uses a Map Server to publish its EID-to-RLOC mappings
   does not need to participate further in the mapping database
   protocol(s).  When using a LISP+ALT mapping database, for example,
   this means that the ETR does not need to implement GRE or BGP, which
   greatly simplifies its configuration and reduces its cost of
   operation.

   Note that use of a Map Server does not preclude an ETR from also
   connecting to the mapping database (i.e. it could also connect to the
   LISP+ALT network) but doing so doesn't seem particularly useful as
   the whole purpose of using a Map Server is to avoid the complexity of
   the mapping database protocols.

4.3.  Map Server Processing

   Once a Map Server has EID-prefixes registered by its client ETRs, it
   can accept and process Map-Requests for them.

   In response to a Map-Request (received over the ALT if LISP+ALT is in
   use), the Map Server first checks to see if the destination EID
   matches a configured EID-prefix.  If there is no match, the Map
   Server returns a negative Map-Reply with action code "forward-native"
   and a 15-minute TTL.  This may occur if a Map Request is received for
   a configured aggreate EID-prefix for which no more-specific EID-
   prefix exists; it indicates the presence of a non-LISP "hole" in the
   agregate EID-prefix.

   Next, the Map Server checks to see if any ETRs have registered the
   matching EID-prefix.  If none are found, then the Map Server returns
   a negative Map-Reply with action code "forward-native" and a 1-minute
   TTL.

   If any of the registered ETRs for the EID-prefix have requested proxy
   reply service, then the Map Server answers the request instead of
   forwarding it.  It returns a Map-Reply with the EID-prefix, RLOCs,
   and other information learned through the registration process.

   If none of the ETRs have requested proxy reply service, then the Map
   Server re-encapsulates and forwards the resulting Encapsulated Map-
   Request to one of the registered ETRs.  It does not otherwise alter
   the Map-Request so any Map-Reply sent by the ETR is returned to the
   RLOC in the Map-Request, not to the Map Server.  Unless also acting
   as a Map Resolver, a Map Server should never receive Map-Replies; any
   such messages should be discarded without response, perhaps
   accompanied by logging of a diagnostic message if the rate of Map-
   Replies is suggestive of malicious traffic.

   A Map Server may also receive a Map-Request =
that is contained inside
   of an Encapsulated Control Message (an Encapsulated Map-Request) with
   the "Security" bit ("S-bit") set.  It processes the security
   parameters as described in [LISP-SEC] then handles the Map-Request as
   as described above.

   Note that a Map Server that is sending a Map-Reply on behalf of an
   ETR (performing proxy reply service) must perform security processing
   for that ETR as well; see [LISP-SEC] for details.

4.4.  Map Resolver Processing

   Upon receipt of an Encapsulated Map-Request, a Map Resolver de-
   capsulates the enclosed message then searches for the requested EID
   in its local database of mapping entries (statically configured,
   cached, configured<=
/strong> or
   learned from associated ETRs when if the Map Resolver is =
also
   acting as a Map Server). Serv=
er
   offering proxy reply service).  If it finds a matching e=
ntry, it
   returns a
   non-authoritative LISP Map-R=
eply with the known mapping.

   If the Map Resolver does not have the mapping entry and if it can
   determine that the EID is not in the mapping database (for example,
   if LISP+ALT is used, the Map Resolver will have an ALT forwarding
   table that covers the full EID space) it immediately returns a
   negative LISP Map-Reply, with action code "forward-native" and a 15-
   minute TTL.  To minimize the number of negative cache entries needed
   by an ITR, the Map Resolver should return the least-specific prefix
   which both matches the original query and does not match any EID-
   prefix known to exist in the LISP-capable infrastructure.

   If the Map Resolver does not have sufficient information to know
   whether the EID exists, it needs to forward the Map-Request to
   another device which has more information about the EID being
   requested.  This is done in one of two ways:

   1.  A non-caching Map Resolver simply  To do this, it forwards the unencapsulated Map=
-Request,
   with the original ITR RLOC as the source, to the mapping database
   system.  Using LISP+ALT, the Map Resolver is connected to the ALT
   network and sends the Map-Request to the next ALT hop learned from
   its ALT BGP neighbors.  The Map Resolver does not send any response
   to the ITR; since the source RLOC is that of the ITR, the ETR or Map
   Server which receives the Map-Request over the ALT and responds will
   do so directly to the ITR.

   2.  A caching Map Resolver queues informatio=
n from the Encapsulated
       Map-Request, including the ITR RLOC and the original Map-Request
       message nonce.  It then modifies the Map-Request to use its own
       RLOC, generates a "local nonce" (which is also saved in the
       request queue entry), and forwards the Map-Request as above.
       When the Map Resolver receives a Map-Reply, it looks in its
       request queue to match the reply nonce to a "local nonce" entry
       then de-queues the entry and uses the saved original nonce and
       ITR RLOC to re-write those fields in the Map-Reply before sending
       to the ITR.  The request queue entry is also deleted and the
       mapping entries from the Map-Reply are saved in the Map
       Resolver's cache.

   If a Map Resolver receives a Map-Request contained in an Encapsulated
   Control Message (an Encapsulated Map-Request) with the "security"
   option ("S-Bit") set, additional processing is required.  It extracts
   the enclosed Map-Request and uses the attached security paramaters to
   generate a new Encapsulated Control Message containing the original
   Map-Request and additional signature information used to protect both
   the Map-Request and the Map-Reply that will be generated by the
   destination ETR or Map Server.  The outgoing message will have the
   "S-bit" set, will use the requested EID as its outer header
   destination IP address plus Map Resolver RLOC as source IP address,
   and will include security parameters added by the Map Resolver.  See
   [LISP-SEC] for details of the checks that are performed and the
   security information that is added during the de-encapsulation and
   re-encapsulation process.

4.4.1.  Anycast Map Resolver Operation

   A Map Resolver can be set up to use "anycast", where the same address
   is assigned to multiple Map Resolvers and is propagated through IGP
   routing, to facilitate the use of a topologically-close Map Resolver
   each ITR.

   Note that Map Server associations with ETRs should not use anycast
   addresses as registrations need to be established between an ETR and
   a specific set of Map Servers, each identified by a specific
   registation association.

5.  Open Issues and Considerations

   There are a number of issues with the Map Server and Map Resolver
   design that are not yet completely understood.  Among these are:

   o  Constants, such as those used for Map-Register frequency,
      retransmission timeouts, retransmission limits, negative Map-Reply
      TTLs, et al are subject to further refinement as more experience
      with prototype deployment is gained.

   o  Feasibility, performance, and complexity =
trade-offs of
      implementing caching in Map Resolvers, as discussed in Section 3,
      Paragraph 4.

   o  Convergence time when an EID-to-RLOC mapping changes =
and
      mechanisms for detecting and refreshing or removing stale, cached
      information

   o  Deployability and complexity trade-offs of implementing stronger
      security measures in both EID-prefix registration and Map-Request/
      Map-Reply processing

   o  Requirements for additional state in the registration process
      between Map Servers and ETRs

   The authors expect that experimentation on the LISP pilot network
   will help answer open questions surrounding these and other issues.

6.  IANA Considerations

   This document makes no request of the IANA.

7.  Security Considerations

   The 2-way LISP header nonce exchange documented in [LISP] can be used
   to avoid ITR spoofing attacks.

   To publish an authoritative EID-to-RLOC mapping with a Map Server, an
   ETR includes authentication data that is a hash of the message using
   pair-wise shared key.  An implementation must support use of HMAC-
   SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128
   [RFC6234] (SHA-256 truncated to 128 bits).

   During experimental and prototype deployment, all authentication key
   configuration will be manual.  Should LISP and its components be
   considered for IETF standardization, further work will be required to
   follow the BCP 107 [RFC4107] recommendations on automated key
   management.

   As noted in Section 4.2, a Map Server should verify that all EID-
   prefixes registered by an ETR match configuration stored on the Map
   Server.

   [LISP-SEC] defines a proposed mechanism for providing origin
   authentication, integrity, anti-reply protection, and prevention of
   man-in-the-middle and "overclaiming" attacks on the Map-Request/Map-Reply Map-Request/
   Map-Reply exchange.  Work =
is ongoing on this and other proposals for
   resolving these open security issues

   While beyond the scope of securing an individual Map Server or Map
   Resolver, it should be noted that a BGP-based LISP+ALT network (if
   ALT is used as the mapping database infrastructure) can take
   advantage of technology being developed by t=
he IETF SIDR working
   group or either S-BGP [I-D.murphy-bgp-secr] or soBGP
   [I-D.white-sobgparchitecture] should they be developed and widely
   deployed. standards work o=
n adding security to BGP.

8.  References

8.1.  Normative References

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-10.txt (work in progress),
              October 2011.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-15.txt (work in progress), July 2011.

   [LISP-SEC]
              Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O.
              Bonaventure, "LISP-Security", draft-ietf-lisp-sec-00.txt
              (work in progress), July 2011.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC6234]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

8.2.  Informative References

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network Service for LISP",
              draft-meyer-lisp-cons-04.txt (work in progress),
              April 2008.

   [I-D.murphy-bgp-secr]
              Murphy, S., "BGP Security Analysis",
              draft-murphy-bgp-secr-04 (work in progress),
              November 2001.

   [I-D.white-sobgparchitecture]
              White, R., "Architecture and Deployment Considerations for
              Secure Origin BGP (soBGP)",
              draft-white-sobgparchitecture-00 (work in progress),
              May 2004.

   [LISP-MN]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Mobile Node Architecture", draft-meyer-lisp-mn-05.txt
              (work in progress), May 2011.

   [LISP-SEC]
              Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O.
              Bonaventure, "LISP-Security", draft-ietf-lisp-sec-00.txt
              (work in progress), July 2011.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-08.txt (work in progress),
              March 2010.

   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
              Key Management", BCP 107, RFC 4107, June 2005.

Appendix A.  Acknowledgments

   The authors would like to thank Greg Schudel, Darrel Lewis, John
   Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver,
   Fabio Maino, and members of the lisp@ietf.org mailing list for their
   feedback and helpful suggestions.

   Special thanks are due to Noel Chiappa for his extensive work on
   caching with LISP-CONS, some of which may be used by Map Resolvers.

Authors' Addresses

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dino   Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com