From internet-drafts@ietf.org Wed Aug 10 10:58: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 B304921F8A55; Wed, 10 Aug 2011 10:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 NHX4seqTig1P; Wed, 10 Aug 2011 10:58:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE4821F89B8; Wed, 10 Aug 2011 10:58:09 -0700 (PDT) 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.57 Message-ID: <20110810175809.5322.51660.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2011 10:58:09 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-lig-04.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, 10 Aug 2011 17:58:09 -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 Internet Groper (LIG) Author(s) : Dino Farinacci Dave Meyer Filename : draft-ietf-lisp-lig-04.txt Pages : 19 Date : 2011-08-10 A simple tool called the LISP Internet Groper or 'lig' can be us= ed to query the LISP mapping database. This draft describes how it works. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-lig-04.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-lig-04.txt From dino@cisco.com Wed Aug 10 10:58:43 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 40FD921F8A69 for ; Wed, 10 Aug 2011 10:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.391 X-Spam-Level: X-Spam-Status: No, score=-3.391 tagged_above=-999 required=5 tests=[AWL=-1.393, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 Hw7tL3UXbdo4 for ; Wed, 10 Aug 2011 10:58:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C25DA21F842E for ; Wed, 10 Aug 2011 10:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=57463; q=dns/txt; s=iport; t=1312999147; x=1314208747; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=LYw1eh1zJawsOgmysbQ9Uw3UV7AEF2ZzkXJdKJVYETQ=; b=HGZa5tm4OHW4Ldr9uhMJHcCxSU/UKz0kpdvAqKnxc1t9Gq9T30Fld/nH UB18u7eW1lIKh1VaBC42rTYFn6+4fckwI9aonN1rTmg0snT2DCAhZHKbm YPUdTnsAWrIO0LR+Ofr0pfEAYWlaKLxxhMbIbUMH4DQ84aNbr7dg33wEd Q=; X-Files: rfcdiff-lig-03-to-04.html, draft-ietf-lisp-lig-04.txt : 25201, 27149 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFABjGQk6rRDoI/2dsb2JhbABCgk2VV4cIAYgJd4FAAQEBAQIBEgEHE0YGBQsLEiYBDUkOBhMJEQiHTASgDgGeVoVnXwSHXYsshQqEaIcb X-IronPort-AV: E=Sophos;i="4.67,351,1309737600"; d="txt'?html'217?scan'217,208,217";a="11844214" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 10 Aug 2011 17:59:05 +0000 Received: from [10.21.72.156] ([10.21.72.156]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7AHwLIS031487; Wed, 10 Aug 2011 17:59:04 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/mixed; boundary="Apple-Mail=_F1D24CD1-0C4E-4A22-90B2-E59F7817BA89" From: Dino Farinacci In-Reply-To: <4E331727.8000503@piuha.net> Date: Wed, 10 Aug 2011 10:59:04 -0700 Message-Id: References: <4E331727.8000503@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org, draft-ietf-lisp-lig@tools.ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-lig 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, 10 Aug 2011 17:58:43 -0000 --Apple-Mail=_F1D24CD1-0C4E-4A22-90B2-E59F7817BA89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > Thanks for sending me a few documents to read :-) Thanks for the quick review Jari. Sorry for the delay. See responses = inline, a new draft attached with a diff file. I have submitted a new = revision. > I'm starting with an easy one. This document is ready to move forward, = I found no technical issues but I did find a few editorial issues. I = have sent the draft forward to an IETF last call. Great news. > Technical: >=20 > None >=20 > Editorial: >=20 > Section 1 gives the usual RFC 2119 terminology, but I don't actually = see why this draft would need to use these terms. This is an explanation = of a tool that is based on Lisp protocols defined in other documents, = right? Please delete section 1. Removed. > Also, please reformulate the definition of term "EID" so that it does = not use the RFC 2119 keywords; a definition seems like the wrong place = to use such keywords, and in case, the normative rules about the EIDs = should probably only exist in one of the Lisp documents. Done. >> ITR, ETR, PA addresses, xTR >=20 > These terms are not defined in this document. Please add them and = possibly other missing terms to the terminology section (or just expand = them on first use and refer to a document that defines them). Added. >> Sending Map-Requests to Map Resolvers provides a secure >> mechanism mechanism to obtain a Map-Reply containing the >> authoritative EID-to-RLOC mapping for a destination LISP site. >> =20 > s/mechanism mechanism/mechanism/ Fixed. >> an EMR is a Map-Request message >> which is encapsulated with another LISP header using UDP >> destination port number 4341 >=20 > Please refer to the Lisp header specification and the one that defines = port 4341. Done. >> The cisco LISP prototype implementation has support for lig for IPv4 >=20 > s/cisco/Cisco/g (I think) It is spelled correctly. ;-) >> titanium-simlo# lig self6 >> Send loopback map-request to 10.0.0.1 for 192:168:1:: ... >> Received map-reply from 10::1 with rtt 0.044372 secs >>=20 >> Map-cache entry for EID 192:168:1::: >> 192:168:1::/48, uptime: 00:00:01, expires: 23:59:58 >> via map-reply, self >> Locator Uptime State Priority/Weight Packets = In/Out >> 10.0.0.3 00:00:01 up 1/100 0/0 >> 10::1 00:00:01 up 2/0 0/0 >> =20 >=20 > What are the 192:168:1 etc addresses? Would it be better to use the = IPv6 example address space for these examples? Changed all references to IPv6 addresses to be in the prefix = 2001:DB8::/32. Thanks, Dino/Dave --Apple-Mail=_F1D24CD1-0C4E-4A22-90B2-E59F7817BA89 Content-Disposition: attachment; filename=rfcdiff-lig-03-to-04.html Content-Type: text/html; name="rfcdiff-lig-03-to-04.html" Content-Transfer-Encoding: 7bit rfcdiff
 
IETF Home
About Tools
Tools:
diffs spell
xml2rfc idnits
tracker src
News
Get Passwd
IETF-81:
Rooms
Agenda
Calendar
Documents
RFCs
Doc fetch:
Wikis:
IESG IRTF
IAOC RSOC
Chairs Edu
Tools BOFs Development
NomCom
Areas
WGs:
concluded…
6lowpan
6man
6renum
Abfab
Adslmib
Alto
Ancp
Appsawg
Armd
Atoca
Autoconf
Avtcore
Avtext
Behave*
Bfd
Bliss
Bmwg*
Ccamp*
Cdni
Clue
Codec
Conex
Core
Csi
Cuss
Dane
Dccp
Decade
Dhc
Dime
Dispatch
Dkim
Dnsext
Dnsop
Drinks
Eai
Ecrit
Eman*
Emu
Fecframe
Forces
Ftpext2
Geopriv
Grow
Hip
Hokey
Homenet
Httpbis
Hybi
Idr
Intarea
Ipfix
Ippm
Ipsecme
Iri
Isis
Isms
Karp
Kitten
Krb-wg
L2tpext
L2vpn
L3vpn
Ledbat
Lisp
Lwig
Manet
Marf*
Mboned
Mediactrl
Mext
Mif
Mip4
Mmusic
Mpls*
Mptcp
Msec*
Multimob
Nea
Netconf*
Netext
Netmod
Nfsv4
Ntp
Oauth
Opsawg*
Opsec
Ospf
P2psip*
Paws
Payload*
Pce
Pcn
Pcp
Pim
Pkix
Pmol
Pppext
Ppsp
Precis
Pwe3
Radext
Rmt
Roll
Rtcweb
Rtgwg
Salud
Savi
Sidr*
Sieve
Simple
Sipclf
Sipcore
Siprec
Soc
Softwire*
Speechsc
Speermint
Splices
Storm
Tcpm
Tictoc
Tls
Trill
Tsvwg*
Urnbis
V6ops*
Vcarddav
Vipr
Websec*
Xcon
Xmpp
Xrblock
Yam

* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Rfcdiff Tool
Version: 0.11
Author:

Rfcdiff Web Service

File 1 -   Upload file:  
or enter URL:  
 
File 2 -   Upload file:  
or enter URL:  
 
Output format: Side-by-side diff
Before-after diff
Changebars
Html wdiff
Html Wdiff Options:
Colour of old text:
Colour of new text:
Larger diff text:
Column width:

You can also use this web-service with an URL query-string of the form:

http://tools.ietf.org//rfcdiff?url1=http-url-to-doc-1&url2=http-url-to-doc-2

which makes it possible to send around links to diffs between document versions withouth actually generating the diff yourself, as long as the two document versions are available by http.

Example (yes, it is long - no way to get around that... - but you could use tinyurl.com to get a short alias to one of these):

http://tools.ietf.org/rfcdiff?
  url1=http://tools.ietf.org/id/draft-ietf-atompub-format-10.txt
  &url2=http://tools.ietf.org/id/draft-ietf-atompub-format-11.txt




Generated from PyHt script /rfcdiff Latest update: 24 May 2011 09:22 GMT -
--Apple-Mail=_F1D24CD1-0C4E-4A22-90B2-E59F7817BA89 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 --Apple-Mail=_F1D24CD1-0C4E-4A22-90B2-E59F7817BA89 Content-Disposition: attachment; filename=draft-ietf-lisp-lig-04.txt Content-Type: text/plain; name="draft-ietf-lisp-lig-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental cisco Systems Expires: February 11, 2012 August 10, 2011 LISP Internet Groper (LIG) draft-ietf-lisp-lig-04 Abstract A simple tool called the LISP Internet Groper or 'lig' can be used to query the LISP mapping database. This draft describes how it works. 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 February 11, 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. Farinacci & Meyer Expires February 11, 2012 [Page 1] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Implementation Details . . . . . . . . . . . . . . . . . . . . 9 4.1. LISP Router Implementation . . . . . . . . . . . . . . . . 9 4.2. Public Domain Host Implementation . . . . . . . . . . . . 10 5. Testing the ALT . . . . . . . . . . . . . . . . . . . . . . . 12 6. Future Enhancements . . . . . . . . . . . . . . . . . . . . . 13 7. Deployed Network Diagnostic Tools . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Farinacci & Meyer Expires February 11, 2012 [Page 2] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 1. Introduction LISP [LISP] 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, the Locator/ID Separation Protocol (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], with LISP+ALT being the system that is currently being implemented and deployed on the pilot LISP network. In conjunction with the various mapping systems, there exists a network based API called LISP Map-Server [LISP-MS]. Using Map Resolvers and Map Servers allows LISP sites to query and register into the database in a uniform way independent of the mapping system used. Sending Map-Requests to Map Resolvers provides a secure mechanism to obtain a Map-Reply containing the authoritative EID-to- RLOC mapping for a destination LISP site. The 'lig' is a manual management tool to query the mapping database. It can be run by all devices which implement LISP, including ITRs, ETRs, PTR, Map-Resolvers, Map-Servers, and LISP-ALT routers, as well as by a host system at either a LISP-capable or non-LISP-capable site. Farinacci & Meyer Expires February 11, 2012 [Page 3] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 2. Definition of Terms Map-Server: a network infrastructure component which learns EID-to- RLOC mapping entries from an authoritative source (typically, an ETR, though static configuration or another out-of-band mechanism may be used). A Map-Server advertises these mappings in the distributed mapping database. Map-Resolver: a network infrastructure component which accepts LISP Encapsulated Map-Requests, typically from an ITR, quickly determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is immediately returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting the distributed mapping database system. Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains an destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs must not be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing-out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings, it is dynamic, local to the ITR(s), and relatively small while the database is distributed, relatively static, and much more global in scope. Farinacci & Meyer Expires February 11, 2012 [Page 4] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 EID-to-RLOC Database: a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. Encapsulated Map-Request (EMR): an EMR is a Map-Request message which is encapsulated with another LISP header using UDP destination port number 4341. It is used so an ITR, PTR, or a system initiating a 'lig' command can get the Map-Request to a Map-Resolver by using locater addresses. When the Map-Request is decapsulated by the Map-Resolver it will be forwarded on the ALT network to the Map-Server that has injected the EID-prefix for a registered site. The Map-Server will then encapsulate the Map- Request in a LISP packet and send it to an an ETR at the site. The ETR will then return an authoritative reply to the system that initiated the request. See [LISP] for packet format details. Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally-routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID- to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. xTR: A xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router", meaning both ITR and ETR functionality is at the CE router. Farinacci & Meyer Expires February 11, 2012 [Page 5] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 Provider Assigned (PA) Addresses: PA addresses are an a address block assigned to a site by each service provider to which a site connects. Typically, each block is sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multi-homed site acquiring its own, globally- visible prefix. LISP uses only topologically-assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice. Farinacci & Meyer Expires February 11, 2012 [Page 6] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 3. Basic Overview When the lig command is run, a Map-Request is sent for a destination EID. When a Map-Reply is returned, the contents are displayed to the user. The information displayed includes: o The EID-prefix for the site the queried destination EID matches. o The locator address of the Map Replier. o The locator-set for the mapping entry which includes the locator address, up/down status, priority, and weight of each locator. o An round-trip-time estimate for the Map-Request/Map-Reply exchange. A possible syntax for a lig command could be: lig [source ] [to ] Parameter description: : is either a Fully Qualified Domain Name or a destination EID for a remote LISP site. source : is an optional source EID to be inserted in the "Source EID" field of the Map-Request. to : is an optional Fully Qualified Domain Name or RLOC address for a Map-Resolver. The lig utility has two usage cases. The first being a way to query the mapping database for a particular EID. And the other to verify if a site has registered successfully with a Map-Server. The first usage has already been described. Verifying registration is called "ligging yourself". What occurs is in the lig initiator, a Map-Request is sent for one of the EIDs for the lig initiator's site. The Map-Request is then returned to one of the ETRs for the lig initiating site. In response to the Map-Request, a Map-Reply is sent back to the locator address of the lig initiator (note the Map-Reply could be sent by the lig initiator). That Map-Reply is processed and the mapping data for lig initiating site is displayed for the user. Refer to the syntax in section Section 4.1 for an implementation of "ligging yourself". However, for host-based implementations within a LISP site, "lig self" is less useful since the host may not have an RLOC to receive a Map-Reply with. But, lig can be used in a non-LISP Farinacci & Meyer Expires February 11, 2012 [Page 7] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 site as well as from infrastructure hosts to get mapping information. Farinacci & Meyer Expires February 11, 2012 [Page 8] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 4. Implementation Details 4.1. LISP Router Implementation The cisco LISP prototype implementation has support for lig for IPv4 and IPv6. The command line description is: lig [source ] [to ] [count <1-5>] This command initiates the LISP Internet Groper. It is similar to the DNS analogue 'dig' but works on the LISP mapping database. When this command is invoked, the local system will send a Map-Request to the configured Map-Resolver. When a Map-Reply is returned, its contents will be displayed to the user. By default, up to 3 Map- Requests are sent if no Map-Reply is returned but once a Map-Reply is returned no other Map-Requests are sent. The destination can take a DNS name, or an IPv4 or IPv6 EID address. The can be one of the EID addresses assigned to the site in the default VRF. When is specified, then the Map-Request is sent to the address. Otherwise, the Map-Request is sent to a configured Map-Resolver. When a Map-Resolver is not configured then the Map-Request is sent on the ALT network if the local router is attached to the ALT. When "count <1-5>" is specified, 1, 2, 3, 4, or 5 Map-Requests are sent. Some sample output: titanium-dino# lig titanium-dmm.lisp4.net Send map-request to 10.0.0.1 for 192.168.1.1 ... Received map-reply from 10.0.0.2 with rtt 0.081468 secs Map-cache entry for titanium-dmm.lisp4.net EID 192.168.1.1: 192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58, via map-reply, auth Locator Uptime State Priority/Weight Packets In/Out 10.0.0.2 13:59:59 up 1/100 0/14 Using lig to "lig yourself" is accomplished with the following syntax: lig {self | self6} [source ] [to ] [count <1-5>] Use this command for a simple way to see if the site is registered with the mapping database system. The destination-EID address for the Map-Request will be the first configured EID-prefix for the site (with the host-bits set to 0). For example, if the site's EID-prefix Farinacci & Meyer Expires February 11, 2012 [Page 9] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 is 192.168.1.0/24, the destination-EID for the Map-Request is 192.168.1.0. The source-EID address for the Map-Request will also be 192.168.1.0 (in this example) and the Map-Request is sent to the configured Map-Resolver. If the Map-Resolver and Map-Server are the same LISP system, then the "lig self" is testing if the Map-Resolver can "turn back a Map-Request to the site". If another Map-Resolver is used, it can test that the site's EID-prefix has been injected into the ALT infrastructure in which case the lig Map-Request is processed by the Map-Resolver, propagated through each ALT router hop to the site's registered Map-Server. Then the Map-Server returns the Map-Request to originating site. In which case, an xTR at the originating site sends a Map-Reply to the source of the Map-Request (could be itself or another xTR for the site). All other command parameters are described above. Using "lig self6" tests for registering of IPv6 EID- prefixes. Some sample output for ligging yourself: rutile# lig self Send loopback map-request to 10.0.0.1 for 192.168.2.0 ... Received map-reply from 10.0.0.3 with rtt 0.001592 secs Map-cache entry for EID 192.168.2.0: 192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57 via map-reply, self Locator Uptime State Priority/Weight Packets In/Out 10.0.0.3 00:00:02 up 1/100 0/0 titanium-simlo# lig self6 Send loopback map-request to 10.0.0.1 for 2001:db8:1:: ... Received map-reply from 10::1 with rtt 0.044372 secs Map-cache entry for EID 192:168:1::: 2001:db8:1::/48, uptime: 00:00:01, expires: 23:59:58 via map-reply, self Locator Uptime State Priority/Weight Packets In/Out 10.0.0.3 00:00:01 up 1/100 0/0 2001:db8:ffff::1 00:00:01 up 2/0 0/0 4.2. Public Domain Host Implementation There is a public domain implementation that can run on any x86 based system. The only requirement is that the system that initiates lig must have an address assigned from the locator namespace. Farinacci & Meyer Expires February 11, 2012 [Page 10] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 lig [-d] -m [-c ] [-t ] Parameter description: -d: prints additional protocol debug output. : is the destination EID or FQDN of a LISP host. -m : is the RLOC address or FQDN of a Map-Resolver. -c : the number of Map-Requests to send before the first Map- Reply is returned. The default value is 3. The range is from 1 to 5. -t : the amount of time, in seconds, before another Map- Request is sent when no Map-Reply is returned. The default value is 2 seconds. The range is from 1 to 5. Some sample output: % lig titanium-test.lisp4.net -m 10.0.0.1 Send map-request to 10.0.0.1 for 192.168.1.1 ... Received map-reply from 10.0.0.2 with rtt 0.04000 sec Mapping entry for EID 192.168.1.1: 192.168.1.0/24, record ttl: 60 Locator State Priority/Weight 10.0.0.1 up 1/25 10.0.0.2 up 1/25 10.0.0.3 up 1/25 10.0.0.4 up 2/25 The public domain implementation of lig is available at http://github.com/davidmeyer/lig. Farinacci & Meyer Expires February 11, 2012 [Page 11] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 5. Testing the ALT There are cases where a Map-Reply is returned from a lig request but the user doesn't really know how much of the mapping infrastructure was tested. There are two cases to consider, avoiding the ALT and traversing the ALT. When an ITR sends a lig request to its Map-Resolver for a destination-EID, the Map-Resolver could also be configured as a Map- Server. And if the destination-EID is for a site that registers with this Map-Server, the Map-Request is sent to the site directly without testing the ALT. This occurs because the Map-Server is the source of the advertisement for the site's EID-prefix. So if the map-reply is returned to the lig requesting site, you cannot be sure that other sites can reach the same destination-EID. If a Map-Resolver is used that is not a Map-Server for the EID-prefix being sought, then the ALT infrastructure can be tested. This test case is testing the functionality of the Map-Resolver, traversal of the ALT (testing BGP-over-GRE), and the Map-Server. It is recommended that users issue 2 lig requests, each which send Map-Requests to different Map-Resolvers. The network can have a LISP-ALT router deployed as a "ALT looking- glass" node. This type of router has BGP peering sessions with other ALT routers where it does not inject any EID-prefixes into the ALT but just learns ones advertised by other ALT routers and Map-Servers. This router is configured as a Map-Resolver. Lig users can point to the ALT looking-glass router for Map-Resolver services via the "to " parameter on the lig command. The ALT looking-glass node can be used to lig other sites as well as your own site. When the ALT looking-glass is used as a Map-Resolver, you can be assured the ALT network is being tested. Farinacci & Meyer Expires February 11, 2012 [Page 12] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 6. Future Enhancements When negative Map-Replies have been further developed and implemented, lig should be modified appropriately to process and clearly indicate how and why a negative Map-Reply was received. Negative Map-Replies could be sent in the following cases, the lig request was initiated for a non-EID address or the Map-Request initiated by lig request is being rejected due to rate-limiting on the replier. Farinacci & Meyer Expires February 11, 2012 [Page 13] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 7. Deployed Network Diagnostic Tools There is an web-based interface to do auto-polling with lig on the back-end for most of the LISP sites on the LISP test network. The web-page can be accessed at http://www.lisp4.net/status. There is a LISP site monitoring web-based interface that can be found at http://www.lisp4.net/lisp-site. At http://baldomar.ccaba.upc.edu/lispmon, written by the folks at UPC, shows a geographical map indicating where each LISP site resides. Farinacci & Meyer Expires February 11, 2012 [Page 14] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 8. Security Considerations The use of lig does not affect the security of the LISP infrastructure as it is simply a tool that facilities diagnostic querying. See [LISP], [ALT], and [LISP-MS] for descriptions of the security properties of the LISP infrastructure. Farinacci & Meyer Expires February 11, 2012 [Page 15] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 9. IANA Considerations This document makes no request of the IANA. Farinacci & Meyer Expires February 11, 2012 [Page 16] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 10. References 10.1. Normative References [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. 10.2. Informative References [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietfr-lisp-alt-06.txt (work in progress). [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). [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-15.txt (work in progress). [LISP-LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", draft-farinacci-lisp-lig-02.txt (work in progress). [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", draft-ietf-lisp-ms-10.txt (work in progress). [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-08.txt (work in progress). Farinacci & Meyer Expires February 11, 2012 [Page 17] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 Appendix A. Acknowledgments Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and Vince Fuller for providing critical feedback on the lig design and prototype implementations. These folks as well as all the people on lisp-beta@external.cisco.com who tested lig functionality and continue to do so, we extend our sincere thanks. This working group draft is based on individual contribution draft-farinacci-lisp-lig-02.txt [LISP-LIG]. Farinacci & Meyer Expires February 11, 2012 [Page 18] =0C Internet-Draft LISP Internet Groper (LIG) August 2011 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Dave Meyer cisco Systems 170 Tasman Drive San Jose, CA USA Email: dmm@cisco.com Farinacci & Meyer Expires February 11, 2012 [Page 19] =0C --Apple-Mail=_F1D24CD1-0C4E-4A22-90B2-E59F7817BA89 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 --Apple-Mail=_F1D24CD1-0C4E-4A22-90B2-E59F7817BA89-- From hannu.flinck@nsn.com Thu Aug 11 01:19: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 ED1E421F88A1 for ; Thu, 11 Aug 2011 01:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 IJMOGLMpYB7Q for ; Thu, 11 Aug 2011 01:19:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id B73B521F889D for ; Thu, 11 Aug 2011 01:19:11 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p7B8JiC1003526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 11 Aug 2011 10:19:44 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p7B8JerP010210 for ; Thu, 11 Aug 2011 10:19:44 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Aug 2011 10:19:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Aug 2011 11:19:42 +0300 Message-ID: <26E5D1C5D5365D47B147E5E62FC735850374A413@FIESEXC035.nsn-intra.net> In-Reply-To: <4E1AD225.9090605@ac.upc.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] I-D Action: draft-ietf-lisp-deployment-01.txt Thread-Index: Acw/tm4UZvuoPrNiSD6RH32yYMc+PwYRXfeA References: <20110711102637.3235.17129.idtracker@ietfa.amsl.com> <4E1AD225.9090605@ac.upc.edu> From: "Flinck, Hannu (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 11 Aug 2011 08:19:44.0001 (UTC) FILETIME=[6CC4B710:01CC57FF] Subject: Re: [lisp] I-D Action: draft-ietf-lisp-deployment-01.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, 11 Aug 2011 08:19:13 -0000 Hello Lorand and the other authors, I have following comments to the draft: section 2.4 You introduce RLOC to RLOC bindings for recursive LISP use case. On the = other hand in draft-ietf-lisp-eid-block and EID block of /16 IPv6 prefix = is introduced with a target of " By defining an IPv6 EID Block is = possible to configure the router so to natively forward all packets that have not a destination address in the block, without performing any lookup whatsoever. " =20 Clearly this benefit is lost in the recursive LISP use case.=20 Also you introduce "a private database" for RLOC mappings to be used = instead of the global LISP mapping system. Further you recommend that = the use of recursion only between two ISPs. =20 To me this appears quite a heavy arrangement especially when taking = account the main disadvantages you enumerate in the draft. Why can't you = just tunnel (using your favorite tunneling protocol) between the two = ISPs? Without any mapping system. What does the mapping system bring in = to the scenario? Especially when the number of recursion ITRs and ETRs = between the two ISPs are not that many (order of tens I believe).=20 An editorial nit in section 5.4 Migration Summary: Acronym PITR-RD has not been opened up anywhere in the draft. Wouldn't = it be simpler (at least more reader friendly) to talk about EID route = servers instead of PITR-RDs? Best regards Hannu -----Original Message----- From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of = ext Lor=E1nd Jakab Sent: Monday, July 11, 2011 1:36 PM To: lisp@ietf.org Subject: Re: [lisp] I-D Action: draft-ietf-lisp-deployment-01.txt Folks, We moved the PITR scenarios to a new section discussing coexistence/migration/transition, and evolved the Tier 1 scenario into a much better PITR route distribution architecture, that will be presented in Quebec. Regards, Lorand Jakab (on behalf of the draft authors) On 07/11/11 12:26, internet-drafts@ietf.org wrote: > 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 Network Element Deployment Considerations > Author(s) : Lorand Jakab > Albert Cabellos-Aparicio > Florin Coras > Jordi Domingo-Pascual > Darrel Lewis > Filename : draft-ietf-lisp-deployment-01.txt > Pages : 22 > Date : 2011-07-11 > > This document discusses the different scenarios for the deployment = of > the new network elements introduced by the Locator/Identifier > Separation Protocol (LISP). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-lisp-deployment-01.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-deployment-01.txt > _______________________________________________ > 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 From terry.manderson@icann.org Thu Aug 11 17:32: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 6D84821F8B03 for ; Thu, 11 Aug 2011 17:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.634 X-Spam-Level: X-Spam-Status: No, score=-105.634 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_20=-0.74, 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 RinLwYxn6gvA for ; Thu, 11 Aug 2011 17:32:53 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 01B0121F8B02 for ; Thu, 11 Aug 2011 17:32:53 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 11 Aug 2011 17:33:28 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 11 Aug 2011 17:33:26 -0700 Thread-Topic: Minutes from IETF81 available Thread-Index: AcxYh3L+dEBrMcHlkUmEyJiG0cI4vg== Message-ID: 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: [lisp] Minutes from IETF81 available 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, 12 Aug 2011 00:32:53 -0000 Folks, The minutes from LISP@IETF81 have been uploaded. Please review them and if you see anything that doesn't match with your memory of the session please advise asap. http://www.ietf.org/proceedings/81/minutes/lisp.txt Thanks to Luigi and Wassim for taking notes and preparing minutes! Cheers Terry From liuyan.adams@gmail.com Mon Aug 15 20:33:37 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 5FAC611E8085 for ; Mon, 15 Aug 2011 20:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 omOpaH8MPnXk for ; Mon, 15 Aug 2011 20:33:36 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B529011E8086 for ; Mon, 15 Aug 2011 20:33:36 -0700 (PDT) Received: by gxk19 with SMTP id 19so4043635gxk.31 for ; Mon, 15 Aug 2011 20:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; bh=NFUv1jTAcx4Oi6t4S3Aa572g/eU0klKdJQU8gQcpG0Q=; b=rR3vo8dBSw4QRkHbBz4QrV54yCUvxOcWwGviGVXBFkLIAetxCJiFkbwyt5ReK4b4/F eEZm43hLfm20xr4Iik/WgBR982pVpQ4yxw740DPCfV/CuQ+6ncqX/qKo3Yln6IEtFbrg bP7moCZamWAASDM6/fQttyJNJCa/QMP3WYv1Q= Received: by 10.142.153.19 with SMTP id a19mr2386222wfe.70.1313465663323; Mon, 15 Aug 2011 20:34:23 -0700 (PDT) Received: from adams-PC ([125.71.228.131]) by mx.google.com with ESMTPS id p7sm3877811pbn.33.2011.08.15.20.34.19 (version=SSLv3 cipher=OTHER); Mon, 15 Aug 2011 20:34:22 -0700 (PDT) Date: Tue, 16 Aug 2011 11:34:21 +0800 From: "liuyan.adams" To: "lisp" Message-ID: <201108161134146838037@gmail.com> X-mailer: Foxmail 6, 15, 201, 26 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon338514432261_=====" X-Mailman-Approved-At: Tue, 16 Aug 2011 08:07:05 -0700 Subject: [lisp] a question about mapping in LISP ALT 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, 16 Aug 2011 05:15:33 -0000 This is a multi-part message in MIME format. --=====003_Dragon338514432261_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To who it may concern I am a junior student from a univeristy of China and I read LISP draft about internetworking ,LISP ALT , mobile node recently. Firstly, I personally feel that EID-to-RLOC mapping through LISP ALT is not efficient because ALT router routes EID . So I have questions as follows Will that create a large route table considering a large variety of EID? Even though EID is assigned by internet registry, in some region where a large population will migrate to another, the original hierarchical structure will then be destoyed. Will that make the time cost on mapping request longer? Because i think the time spend on lookup the routes will increase. Will the mobile node fail to keep connection with others because of the mapping efficiency? I find no answer to the above questions but I feel that the efficiency of the EID-to-RLOC mapping determine the future's development of LISP. So I wonder do you have any solutions to solve this problem? I am really looking forward to your reply. Sincerely. YAN LIU 2011-08-16 liuyan.adams --=====003_Dragon338514432261_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
To who it may concern
 
        I am a junior student from a univeristy of China and I read LISP draft about internetworking ,LISP ALT , mobile node recently.
        Firstly, I personally feel that EID-to-RLOC mapping through LISP ALT is not efficient because ALT router routes EID .
        So I have questions as follows
        Will that create a large route table considering a large variety of EID? Even though EID is assigned by internet registry, in some region where a large population will migrate to another, the original hierarchical structure will then be destoyed.
        Will that make the time cost on mapping request longer? Because i think the time spend on lookup the routes will increase.
        Will the mobile node fail to keep connection with others because of the mapping efficiency?
        I find no answer to the above questions but I feel that the efficiency of the EID-to-RLOC mapping determine the future's development
         of LISP. So I wonder do you have any solutions to solve this problem?
 
      I am really looking forward to your reply.
 
      Sincerely.
  
     YAN LIU
 
2011-08-16
liuyan.adams
--=====003_Dragon338514432261_=====-- From damien.saucez@uclouvain.be Tue Aug 16 08:28: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 ABBF321F8C0F for ; Tue, 16 Aug 2011 08:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=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 U+l8JXjezQ1O for ; Tue, 16 Aug 2011 08:28:24 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 80EE921F8C0D for ; Tue, 16 Aug 2011 08:28:24 -0700 (PDT) Received: from [10.10.8.117] (unknown [204.101.28.92]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id E4D5E11E252; Tue, 16 Aug 2011 17:29:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <201108161134146838037@gmail.com> Date: Tue, 16 Aug 2011 11:29:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <077D06BE-818E-4EDF-81EE-703A78C2D232@uclouvain.be> References: <201108161134146838037@gmail.com> To: "liuyan.adams" X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (sender authenticated); receiver=; client-ip=204.101.28.92; helo=[10.10.8.117] Received-SPF: Pass (sender authenticated); receiver=; client-ip=204.101.28.92; envelope-from= X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: E4D5E11E252.A25E1 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp Subject: Re: [lisp] a question about mapping in LISP ALT 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, 16 Aug 2011 15:28:25 -0000 Hello, On 15 Aug 2011, at 23:34, liuyan.adams wrote: > To who it may concern > =20 > I am a junior student from a univeristy of China and I read = LISP draft about internetworking ,LISP ALT , mobile node recently. > Firstly, I personally feel that EID-to-RLOC mapping through = LISP ALT is not efficient because ALT router routes EID . > So I have questions as follows > Will that create a large route table considering a large = variety of EID? Even though EID is assigned by internet registry, in = some region where a large population will migrate to another, the = original hierarchical structure will then be destoyed. > Will that make the time cost on mapping request longer? = Because i think the time spend on lookup the routes will increase. You can have a look at "LISP-TREE: A DNS Hierarchy to Support the LISP = Mapping System" = http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=3D5586446 for = this. > Will the mobile node fail to keep connection with others = because of the mapping efficiency? > I find no answer to the above questions but I feel that the = efficiency of the EID-to-RLOC mapping determine the future's development > of LISP. So I wonder do you have any solutions to solve this = problem? It is definitely an important question and solutions are on-going. Damien Saucez > =20 > I am really looking forward to your reply. > =20 > Sincerely. > =20 > YAN LIU > =20 > 2011-08-16 > liuyan.adams > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jari.arkko@piuha.net Fri Aug 19 13:19:17 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 8482421F8B6D for ; Fri, 19 Aug 2011 13:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 6-n5YMaL1xZu for ; Fri, 19 Aug 2011 13:19:17 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 95BE921F8A62 for ; Fri, 19 Aug 2011 13:19:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C82132CEFF; Fri, 19 Aug 2011 23:20:13 +0300 (EEST) 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 oZOePVLN9xra; Fri, 19 Aug 2011 23:20:13 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C6C832CE12; Fri, 19 Aug 2011 23:20:12 +0300 (EEST) Message-ID: <4E4EC57C.2090005@piuha.net> Date: Fri, 19 Aug 2011 23:20:12 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-lisp-multicast@tools.ietf.org, lisp@ietf.org, "Wassim Haddad (KI/EAB)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp-multicast (part 1/2) 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, 19 Aug 2011 20:19:17 -0000 I am reviewing this draft. This is the first part of my review, I've read up to end of Section 7. I should complete the review tomorrow but wanted to send out these early comments already today. So far I've liked what I saw, with the exception of few places where I think clarifications are needed (see below). Technical: > The fundamental multicast forwarding model is to encapsulate a > multicast packet into another multicast packet. An ITR will > encapsulate multicast packets received from sources that it serves in > another LISP multicast header. ... but elsewhere you say ... > Ingress Tunnel Router (ITR): a router which accepts an IP multicast > packet with a single IP header (more precisely, an IP packet that > does not contain a LISP header). The router treats this "inner" > IP destination multicast address opaquely so it doesn't need to > perform a map lookup on the group address because it is > topologically insignificant. The router then prepends an "outer" > IP header with one of its globally-routable RLOCs as the source > address field. I think the first text fragment should have said " An ITR will encapsulate multicast packets received from sources that it serves in a LISP multicast header. ", not " An ITR will encapsulate multicast packets received from sources that it serves in another LISP multicast header. " > MBGP: Even though MBGP is not a multicast routing protocol, it is > used to find multicast sources when the unicast BGP peering > topology and the multicast MBGP peering topology are not > congruent. When MBGP is used in a LISP-Multicast environment, the > prefixes which are advertised are from the RLOC namespace. This > allows receiver multicast sites to find a path to the source > multicast site's ITRs. MBGP peering addresses will be from the > RLOC namespace. > You should clearly state whether or not there are protocol changes (not just configuration or address space differences). You say so later in the conclusions of this section, but I think you should clearly state it already here. The same applies to the rest of the items in this section. I think it will be beneficial to the reader to know if there are no impacts, if some different configuration is needed or different address space is used (IGMP and MBGP), implementation changes are needed for some address mapping or other task (PIM-SM), or if the actual protocol needs to change in order to support LISP-Multicast. I liked the way the description was written for PIM-SM, maybe you can do the same for others. MBGP, MSDP, PIM-Bidir, and PIM-ASM entries were unclear to me. Editorial: The terms EID, RLOC, ASM, SSM, Bidir-mode, TE-ITR, TE-ETR, uPITR, oif-list, RPF should be expanded upon first use (and in some cases you should point to the relevant reference). Note that some of the terms are in Section 3 but used in Section 2. Jari From jari.arkko@piuha.net Sat Aug 20 14:14:20 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 A75E621F8584 for ; Sat, 20 Aug 2011 14:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 nFgKC3iuyDsk for ; Sat, 20 Aug 2011 14:14:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7C32F21F855D for ; Sat, 20 Aug 2011 14:14:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6C6DA2D223; Sun, 21 Aug 2011 00:15:16 +0300 (EEST) 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 k6684yk1NyXv; Sun, 21 Aug 2011 00:15:14 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id AE9E62CE12; Sun, 21 Aug 2011 00:15:14 +0300 (EEST) Message-ID: <4E5023E1.4050803@piuha.net> Date: Sun, 21 Aug 2011 00:15:13 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-lisp-multicast@tools.ietf.org, lisp@ietf.org, "Wassim Haddad (KI/EAB)" References: <4E4EC57C.2090005@piuha.net> In-Reply-To: <4E4EC57C.2090005@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] AD review of draft-ietf-lisp-multicast (part 2/2) 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, 20 Aug 2011 21:14:20 -0000 Continuing my review. The document was a pleasure to read and is in very good shape, despite some areas which were quite complex (such as the different interworking cases). Thank you for that. I think it is ready to move forward soon with a few small changes. I also had one question below and I want to understand the answer to it. Please answer the question and review the suggested changes. Send mail if there's anything that seems out of order. Technical: > This specification focuses on what changes are needed to the > multicast routing protocols to support LISP-Multicast as well as > other protocols used for inter-domain multicast, such as Multi- > protocol BGP (MBGP) [RFC4760 ]. The approach proposed in this > specification requires no changes to the multicast infrastructure > inside of a site when all sources and receivers reside in that site, > even when the site is LISP enabled. That is, internal operation of > multicast is unchanged regardless of whether or not the site is LISP > enabled or whether or not receivers exist in other sites which are > LISP-enabled. > > Therefore, we see changes only to PIM-ASM [RFC4601 ], MSDP [RFC3618 ], > and PIM-SSM [RFC4607 ]. Bidir-PIM [RFC5015 ], which typically does not > run in an inter-domain environment is not addressed in depth in this > version of the specification. > This text from the Introduction seems to say the protocols change. But section 7 says > Based on the protocol description above, the conclusion is that there > are no protocol message format changes, just a translation function > performed at the control-plane. I think you should soften the statement in the introduction to clarify that only mapping operations and router implementation changes are required, the protocols themselves are still as they were. > Since the ITR in the source multicast site has never received a > unicast encapsulated PIM Join/Prune message from any ETR in a > receiver multicast site, it knows there are no LISP-Multicast > receiver sites. Therefore, there is no need for the ITR to > encapsulate data. Since it will know a priori (via configuration) > that its site's EIDs are not routable (and not registered to the > mapping database system), it assumes that the multicast packets from > the source host are sent by a routable address. That is, it is the > responsibility of the multicast source host's system administrator to > ensure that the source host sends multicast traffic using a routable > source address. When this happens, the ITR acts simply as a router > and forwards the multicast packet like an ordinary multicast router. > I have a question about this. The source network is a LISP site, right? When you say that it is an admin responsibility to ensure that the hosts send multicast traffic using a routable source address, what exactly do you mean? That hosts are configured with multiple addresses, and that they know which address to use for which traffic? > Therefore, it is the responsibility of ETRs in multicast receiver > sites to map the group address into a group address where the > embedded-RP address is from the RLOC namespace. The mapped RP- > address is obtained from a EID-to-RLOC mapping database lookup. The > ETR will also send a unicast (*,G) Join/Prune message to the ITR so > the branch of the distribution tree from the source site resident RP > to the ITR is created. > I'm not sure I fully understand the implications of this. What has to be done by the source site to make this happen? Craft a specific database entry and possibly configure an additional IP address for its ITR? More generally, this specification would benefit from a "Manageability Considerations" section that talks about what expectations there are for the network administrator to configure different parameters in the xTRs and elsewhere. Finally, I think the introduction should provide a high-level overview of what the "in progress" or otherwise uncertain areas of the specification are, so that experimentation and future deployment experience can confirm how well these actually work in practice. You already do quite a bit of that, but I would still make the following edit: OLD: Also, the current version of this specification does not describe multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR descriptions in [LISP]. NEW: Also, the current version of this specification does not describe multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR descriptions in [LISP]. Futher work is also needed to determine the detailed behavior for multicast proxy ITRs (mPITRs, Section 9.1.3), mtrace (Section 12), and locator reachability (Section 6). Finally, further deployment and experimentation would be useful to understand the real-life performance of the LISP-Multicast solution. For instance, the design optimizes for minimal state and control traffic in the core, but can in some cases cause extra multicast traffic to be sent (Section 8.1.2). These are just a few things that I collected from elsewhere in the document. Feel free to edit the above text, I'm sure you can provide a more accurate description. But I think some of these things should at least be mentioned upfront. Editorial: > And to have the ITR use its own IP address (its RLOC), and > as the source address. Shouldn't this be: "... use its own IP address (its RLOC) as the source address."? > 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites Extra space Section 9 was hard to read. Maybe because its a complex topic. > o A mixed multicast locator-set with the best multicast priority > values MUST NOT be configured on multicast ITRs. A mixed locator- > set can exist (for unicast use), but the multicast priorities MUST > be the set for the same address family locators. > I had trouble parsing this requirement. Do you mean that on a multicast locator-set, there must always be one address family that is preferred? Expand the term "RP" when first used. I think [INTWORK] should be a normative reference, given how it is used in Section 9. > Therefore, this specifications > focuses on to map a source EID address of a multicast flow during > distribution tree setup and packet delivery. > ... this specification focuses ... Jari From terry.manderson@icann.org Tue Aug 23 17:00:21 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 4631821F8C6F for ; Tue, 23 Aug 2011 17:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.47 X-Spam-Level: X-Spam-Status: No, score=-106.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 IxJ2xynz27V1 for ; Tue, 23 Aug 2011 17:00:20 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id B662C21F8C57 for ; Tue, 23 Aug 2011 17:00:20 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 23 Aug 2011 17:01:29 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Tue, 23 Aug 2011 17:01:27 -0700 Thread-Topic: Nomcom 2011-2012: Call for Nominations Thread-Index: AcxhpyfsPR/C6s8SQ8GvoYVw66Y4CgASdA2L Message-ID: In-Reply-To: <20110822223218.94D9E21F8BF9@ietfa.amsl.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 Subject: [lisp] FW: Nomcom 2011-2012: Call for Nominations 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, 24 Aug 2011 00:00:21 -0000 Hey All, If you know of a person who might be both suitable and willing to to fill one of the open positions, please consider nominating them. The Nomcom has a tough job, I'm told its easier when good people are nominated! Cheers Terry ------ Forwarded Message > From: NomCom Chair > Date: Mon, 22 Aug 2011 15:32:18 -0700 > To: IETF Announcement list > Cc: > Subject: Nomcom 2011-2012: Call for Nominations >=20 > Hi All, >=20 > The 2011-2012 Nominating committee is seeking nominations from now > until October 2, 2011. The list of open positions can be found at: >=20 > https://www.ietf.org/group/nomcom/2011/ >=20 > Nominations may be made directly on the NomCom 2011-2012 pages by > selecting the Nominate link at the top of the page. The URL for > NomCom 2011-2012 pages is: >=20 > https://www.ietf.org/group/nomcom/2011/ >=20 > Nominations may also be made by email to nomcom11@ietf.org. > If you do so, please include the word "Nominate" in the Subject and > indicate in the email who is being nominated, their email address (to > confirm acceptance of the nomination), and the position for which you > are making the nomination. If you wish to nominate someone via email > for more than one position, please use separate emails to do so. >=20 > Self nomination is welcome. >=20 > NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing > Nominees" described in RFC 5680. As stated in RFC 5680: "The list of > nominees willing to be considered for positions under review in the > current NomCom cycle is not confidential". Willing Nominees for each > position will be publicly listed. The public nominee list will be > updated at least once a week and possibly more often as nominations are > received. >=20 > With the exception of publicly listing willing nominees, the > confidentiality requirements of RFC 3777 remain in effect. All > feedback and NomCom deliberations will remain confidential and not > disclosed. >=20 > Because the list of nominees this year is public, we will accept > feedback on the nominees starting August 23, 2011. Per RFC 5680, we > will accept feedback from the entire IETF community on all the nominees. >=20 > If you wish to provide anonymous feedback, the chair or any of the > members will be happy to handle this for you. The Nominating Committee > chair can be reached at nomcom-chair@ietf.org and the entire nominating > committee can be reached at nomcom11@ietf.org. The email addresses of > individual NomCom members is also on the NomCom 2011-2012 pages. >=20 > In addition to nominations, the Nominating Committee is actively > seeking community input on the jobs that need to be filled. We have > received the job descriptions from the IAB, IESG, and IAOC and they can > be found at: >=20 > https://www.ietf.org/group/nomcom/2011/iab-requirements > https://www.ietf.org/group/nomcom/2011/iesg-requirements > https://www.ietf.org/group/nomcom/2011/iaoc-requirements >=20 > However, we also need the community's views and input on the jobs > within each organization. If you have ideas on job responsibilities > (more, less, different), please let us know. Please send suggestions > and feedback to nomcom11@ietf.org. >=20 > Thank you, >=20 > Suresh Krishnan > Chair, NomCom 2011-2012 > nomcom-chair@ietf.org > suresh.krishnan@ericsson.com > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ------ End of Forwarded Message From ljakab@ac.upc.edu Sun Aug 28 15:11: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 42AF621F85F7 for ; Sun, 28 Aug 2011 15:11:50 -0700 (PDT) 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 bQQGmbF5xq7K for ; Sun, 28 Aug 2011 15:11:49 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id D14DD21F86AF for ; Sun, 28 Aug 2011 15:11:48 -0700 (PDT) Received: from [192.168.1.128] (225.252.77.188.dynamic.jazztel.es [188.77.252.225]) by gw.ac.upc.edu (Postfix) with ESMTP id 6DDD36B01DA; Mon, 29 Aug 2011 00:13:05 +0200 (CEST) Message-ID: <4E5ABD6E.5080503@ac.upc.edu> Date: Mon, 29 Aug 2011 00:13:02 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: lisp@ietf.org References: <20110711102637.3235.17129.idtracker@ietfa.amsl.com> <4E1AD225.9090605@ac.upc.edu> <26E5D1C5D5365D47B147E5E62FC735850374A413@FIESEXC035.nsn-intra.net> In-Reply-To: <26E5D1C5D5365D47B147E5E62FC735850374A413@FIESEXC035.nsn-intra.net> 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: 8bit Subject: Re: [lisp] I-D Action: draft-ietf-lisp-deployment-01.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: Sun, 28 Aug 2011 22:11:50 -0000 Hi Hannu, On 08/11/11 10:19, Flinck, Hannu (NSN - FI/Espoo) wrote: > Hello Lorand and the other authors, > > I have following comments to the draft: > > section 2.4 > > You introduce RLOC to RLOC bindings for recursive LISP use case. On the other hand in draft-ietf-lisp-eid-block and EID block of /16 IPv6 prefix is introduced with a target of " By defining an IPv6 EID Block is possible to configure the router so > to natively forward all packets that have not a destination address > in the block, without performing any lookup whatsoever. " > > Clearly this benefit is lost in the recursive LISP use case. Well, yes and no. Since the RLOC-to-RLOC mapping databases are mostly shared by two ISPs, they are expected to be in the order of several hundred prefixes even after being deaggregated. In that case NERD would be a good fit for the mapping system, and all prefixes can be pushed to the FIB of recursive routers. That way external lookups can be avoided. And if the prefixes are in the FIB, the lookup for each packet takes the same as for non-encapped packets. It is true that the draft mentions NERD only in passing, as potential solution to one of the disadvantages. If we make it the recommended mapping system for this scenario, would that address your concern? When this section was written, the lisp-eid-block draft was not "revived" yet, this is why it's missing from the discussion. Do you think it would be worth mentioning here, with the above explanation? > > Also you introduce "a private database" for RLOC mappings to be used instead of the global LISP mapping system. Further you recommend that the use of recursion only between two ISPs. > > > To me this appears quite a heavy arrangement especially when taking account the main disadvantages you enumerate in the draft. Why can't you just tunnel (using your favorite tunneling protocol) between the two ISPs? Without any mapping system. What does the mapping system bring in to the scenario? Especially when the number of recursion ITRs and ETRs between the two ISPs are not that many (order of tens I believe). This scenario is not so much offered as a "_most_ ISPs doing inter-ISP TE should do this", but rather as "_many_ ISPs doing inter-ISP TE could gain something from this". With that in mind, manually configuring tunnels from all the tens of recursive routers of ISP A to those of ISP B, and keeping the configuration up to date can also mean a heavy arrangement on the long run. Creating the shared database may have a higher initial cost, but having a single database distribute "dynamic tunnel" configuration to all routers can lower OpEx on the long run. However, the most interesting application of this scenario in my opinion lies in the finer-grained TE knobs offered by LISP: priorities and especially weights. I can imagine an ISP deploying a smart TE engine that can react in real time to changes in traffic volumes on the circuits they have to other peers, and modifying the weights of certain prefixes according to some algorithm to reach the ISP's TE goals. Note also that the disadvantages are mentioned for completeness sake, and all of them have suggestions for (relatively easy) solutions. > > An editorial nit in section 5.4 Migration Summary: > > Acronym PITR-RD has not been opened up anywhere in the draft. Wouldn't it be simpler (at least more reader friendly) to talk about EID route servers instead of PITR-RDs? For the 3 columns of the table we used the abbreviated forms of the titles of sections 5.1, 5.2 and 5.3, one for each scenario. Indeed, 5.3 doesn't contain the abbreviation in parentheses, will add that. Many thanks for the feedback! Best regards, -Lori (returning online) > > > > Best regards > Hannu > > > > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of ext Loránd Jakab > Sent: Monday, July 11, 2011 1:36 PM > To: lisp@ietf.org > Subject: Re: [lisp] I-D Action: draft-ietf-lisp-deployment-01.txt > > Folks, > > We moved the PITR scenarios to a new section discussing > coexistence/migration/transition, and evolved the Tier 1 scenario into a > much better PITR route distribution architecture, that will be presented > in Quebec. > > Regards, > Lorand Jakab (on behalf of the draft authors) > > On 07/11/11 12:26, internet-drafts@ietf.org wrote: >> 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 Network Element Deployment Considerations >> Author(s) : Lorand Jakab >> Albert Cabellos-Aparicio >> Florin Coras >> Jordi Domingo-Pascual >> Darrel Lewis >> Filename : draft-ietf-lisp-deployment-01.txt >> Pages : 22 >> Date : 2011-07-11 >> >> This document discusses the different scenarios for the deployment of >> the new network elements introduced by the Locator/Identifier >> Separation Protocol (LISP). >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-lisp-deployment-01.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-deployment-01.txt >> _______________________________________________ >> 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 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jari.arkko@piuha.net Mon Aug 29 14:53:30 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 DC6E221F8BBA for ; Mon, 29 Aug 2011 14:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 Prh4MIURXPQQ for ; Mon, 29 Aug 2011 14:53:30 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D954E21F8B46 for ; Mon, 29 Aug 2011 14:53:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 146BE2D223; Tue, 30 Aug 2011 00:54:55 +0300 (EEST) 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 TO3PJXlXgpqC; Tue, 30 Aug 2011 00:54:54 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 39CE42CE66; Tue, 30 Aug 2011 00:54:54 +0300 (EEST) Message-ID: <4E5C0AAD.2010209@piuha.net> Date: Tue, 30 Aug 2011 00:54:53 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: draft-ietf-lisp-map-versioning@tools.ietf.org, lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp-map-versioning 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, 29 Aug 2011 21:53:31 -0000 I have reviewed this draft. This is another well written and easy to understand document. Thank you for that. I only found minor editorial issues, one security aspect that you should document, and couple of small technical comments. I have sent the document forward to IETF Last Call anyway. Please revise the draft as soon as you can (even during Last Call). Ask me if something was unclear or I missed something. Technical: > The feature > introduced by Map-Version numbers is the possibility of blocking > traffic from ITRs not using the latest mapping. Indeed, after a > certain number of retries, if the Destination Map-Version number > in the packets is not updated, the ETR MAY silently drop packets > with a stale Map-Version number. This because either the ITR is > refusing to use the mapping for which the ETR is authoritative or > (worse) it might be some form of attack. I have two small comments about this. First, since an attack could spoof the source address, it is important to restrict the blocking to the offending traffic, not all traffic from a given ITR address. And this is your intention, as can be seen from the second sentence. Could you make the following change to make this even clearer in the first sentence as well: s/blocking traffic from ITRs not using the latest mapping/blocking traffic not using the latest mapping/. Second, I'm not sure I understand the different failure cases here. What if there's a network issue that causes unidirectional connectivity? We'd receive lisp encapsulated packets, but our attempts to send commands to update the mapping would be unsuccessful, as the traffic does not get through. In light of this, is the right action to start dropping packets on our side? Or maybe there is something else in Lisp that prevents us from getting into this situation. Please explain. And if you are not sure what the implications are, please indicate that in the text. > 3. The packet arrives with a Source Map-Version number smaller > (i.e., older) than the one stored in the local EID-to-RLOC Cache. > Such a case is not valid w.r.t. the specifications. Indeed, if > the mapping is already present in the EID-to-RLOC Cache, this > means that an explicit Map-Request has been sent and a Map-Reply > has been received from an authoritative source. Assuming that > the mapping system is not corrupted anyhow, the Map-Version in > the EID-to-RLOC Cache is the correct one and the packet MAY be > silently dropped. > I worry that there's a dependency on something which cannot be fully secured in the real-world, and if someone starts to drop packets due to an inconsistency there is no easy way to recover. I would suggest adding something to the security considerations section about reliance on the security of the mapping system and aggressive drop policies leading to the possibility of difficult recovery from a temporary mapping system issue. > Once no more traffic is received by the RLOC, because all sites have > updated the mapping, it can be shut down safely. Technically, there might be a mapping on some other site that has not had a reason to send a packet yet. But if it then sends a packet, it might use a locally cached copy of the mapping and the packet goes to the wrong place. Perhaps you should clarify this. E.g. " ... received by the RLOC, it can be shut down in relatively safety, because at least all sites actively using the mapping have updated it." Editorial: > This document describes the LISP Map-Versioning mechanism, which > provides in-packet information about EID-to-RLOC mappings used to > encapsulate LISP data packets. The proposed approach is based on > associating a version number to EID-to-RLOC mappings and transport > such a version number in the LISP specific header of LISP- > encapsulated packets. LISP Map-Versioning is particularly useful to > inform communicating xTRs about modifications of the mappings used to > encapsulate packets. The mechanism is transparent to legacy > implementations, since in the LISP-specific header and in the Map > Records, bits used for Map-Versioning can be safely ignored by xTRs > that do not support the mechanism. You should expand EID, RLOC, and xTR, as this is the abstract (it can be read by someone without seeing the rest of the document). > When Map-Versioning is used, LISP-encapsulated data packets contain > the version number of the two mappings used to select the RLOCs in > the outer header (i.e., both source and destination). These version > numbers are encoded in the 24 low-order bits of the first longword of > the LISP header and indicated by a specific bit in the flags (first 8 > high-order bits of the first longword of the LISP header). Note that > not all packets need to carry version numbers. I'd prefer seeing a reference to draft-ietf-lisp and section number that defines the Lisp header. > The Map-Request will either trigger a Map-Request back > using the SMR bit or it will piggyback the newer mapping. These > are not new mechanisms; how to SMR or piggyback mappings in Map- > Request messages is already described in [I-D.ietf-lisp], Expand SMR. > A Proxy-ETR does not have any mapping, since it just decapsulate > packets arriving from LISP site. s/decapsulate/decapsulates/ Jari From iesg-secretary@ietf.org Mon Aug 29 14:57:21 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 3B19521F8C9E; Mon, 29 Aug 2011 14:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 5tsCM8I+jv8Y; Mon, 29 Aug 2011 14:57:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2F121F8C71; Mon, 29 Aug 2011 14:57:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110829215720.26420.60193.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2011 14:57:20 -0700 Cc: lisp@ietf.org Subject: [lisp] Last Call: (LISP Map-Versioning) to Experimental RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 29 Aug 2011 21:57:21 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Map-Versioning' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the LISP Map-Versioning mechanism, which provides in-packet information about EID-to-RLOC mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating xTRs about modifications of the mappings used to encapsulate packets. The mechanism is transparent to legacy implementations, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by xTRs that do not support the mechanism. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-map-versioning/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-map-versioning/ No IPR declarations have been submitted directly on this I-D. From vaf@cisco.com Tue Aug 30 10:47:11 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 F3E5C21F8D70 for ; Tue, 30 Aug 2011 10:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=-3.584, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 cbp1Jfz8Cd+P for ; Tue, 30 Aug 2011 10:46:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 87FEF21F8D5C for ; Tue, 30 Aug 2011 10:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=60755; q=dns/txt; s=iport; t=1314726506; x=1315936106; h=date:from:to:subject:message-id:mime-version; bh=as06TslZcT2d2n2vdfYvHTGQSW5kwyGgom9u/7EH6xA=; b=KDmAvVNIXL92Dc/Pe+agyi/8yLT/6aL8SfznsUItTMrBSk0fmbkYqCk9 xr9tmbQbn0jlHY2Rsn5N0tkK3Gy5+b2/pUa9295sU2FEEqDkjcJhiSaJH llaHA0KOXPVjzIkXcHSp09627zKBueoRBj8/KGHILOs6oUiPZMmofqSTo U=; X-Files: draft-ietf-lisp-ms-11.txt, rfcdiff-ms-10-to-11.html : 33221, 25048 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAIUhXU6rRDoH/2dsb2JhbABCgk2WMYcaAYgbd4FZAQcBEhogBQIIMCYBIRgdJwkRCIdUmD+BIwGQdo5AhW1gBIdmlTiHKw X-IronPort-AV: E=Sophos;i="4.68,303,1312156800"; d="txt'?html'217?scan'217,208,217";a="17871668" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 30 Aug 2011 17:48:24 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7UHmOX4006615 for ; Tue, 30 Aug 2011 17:48:24 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id DABB415BA9E6; Tue, 30 Aug 2011 10:48:23 -0700 (PDT) Date: Tue, 30 Aug 2011 10:48:23 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20110830174823.GA53580@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [lisp] clarification to Map-Notify description in draft-ietf-lisp-ms 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, 30 Aug 2011 17:47:11 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In response to a question received on another mailing list, we are issuing draft-ietf-lisp-ms-11 to clarify that a Map-Notify messages is always sent to the LISP control port (UDP 4342), not to the source port specified in the triggering Map-Register message. As an editorial matter, the -11 draft also updates references to LISP-SEC and to the base LISP specification. There are no other changes to the document content. Thanks go to Rani Assaf for pointing out that the correct behavior was not completely specified in the -10 draft. The new version of the document and HTML wdiff are attached below. Vince and Dino --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-lisp-ms-11.txt" Network Working Group V. Fuller Internet-Draft D. Farinacci Intended status: Experimental cisco Systems Expires: March 2, 2012 August 30, 2011 LISP Map Server draft-ietf-lisp-ms-11.txt Abstract This draft describes the LISP Map Server (LISP-MS), a computing system which provides a simplified LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map Server is to reduce implementation and operational complexity of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. 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 2, 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 Fuller & Farinacci Expires March 2, 2012 [Page 1] Internet-Draft LISP Map Server August 2011 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 4.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 7 4.2. EID Prefix Configuration and ETR Registration . . . . . . 8 4.3. Map Server Processing . . . . . . . . . . . . . . . . . . 9 4.4. Map Resolver Processing . . . . . . . . . . . . . . . . . 10 4.4.1. Anycast Map Resolver Operation . . . . . . . . . . . . 12 5. Open Issues and Considerations . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Fuller & Farinacci Expires March 2, 2012 [Page 2] Internet-Draft LISP Map Server August 2011 1. Introduction [LISP] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate name spaces: EIDs, used within sites, and 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]. There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database. A single device may implement one or both types of operation. Conceptually, LISP Map Servers share some of the same basic configuration and maintenance properties as Domain Name System (DNS) [RFC1035] servers and 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, this is not intended to preclude the use of Map Servers and Map Resolvers as a standardized interface for ITRs and ETRs to access other mapping database systems. Fuller & Farinacci Expires March 2, 2012 [Page 3] Internet-Draft LISP Map Server August 2011 2. Definition of Terms Map Server: a network infrastructure component which learns EID-to- RLOC mapping entries from an authoritative source (typically, an ETR, via the registration mechanism described below). A Map Server publishes these mappings in the distributed mapping database. Map Resolver: a network infrastructure component which accepts LISP Encapsulated Map-Requests, typically from an ITR, quickly determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is immediately returned. Otherwise, the Map Resolver finds the appropriate EID-to-RLOC mapping by consulting the distributed 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]. Fuller & Farinacci Expires March 2, 2012 [Page 4] Internet-Draft LISP Map Server August 2011 3. Basic Overview A Map Server is a device which publishes EID-prefix information on behalf of ETRs and connects to the LISP distributed mapping database system to help answer LISP Map-Requests seeking the RLOCs for those EID-prefixes. 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. The LISP Map Server design also includes the operation of a Map Resolver, which receives Encapsulated Map-Requests from its client ITRs and uses the distributed 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. A Map Resolver may operate in a non-caching mode, where it simply de-capsulates and forwards the Encapsulated Map- Requests that it receives from ITRs. Alternatively, 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 ITRs. One significant issue with use of caching in a Map Resolver is 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 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 outdate, 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. 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. Fuller & Farinacci Expires March 2, 2012 [Page 5] Internet-Draft LISP Map Server August 2011 Detailed descriptions of the LISP packet types referenced by this document may be found in [LISP]. Fuller & Farinacci Expires March 2, 2012 [Page 6] Internet-Draft LISP Map Server August 2011 4. Interactions With Other LISP Components 4.1. ITR EID-to-RLOC Mapping Resolution An ITR is configured with the address of a Map Resolver. This address is a "locator" or RLOC in that it must be routeable on the underlying core network; it 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. Note that the stateless nature of non-caching Map Resolver forwarding means that the Map-Reply may not be from the Map Resolver to which the Encapsulated Map-Request was sent unless the target Map Resolver offers caching. See (Section 4.4) for more details on Map Resolver message processing. Fuller & Farinacci Expires March 2, 2012 [Page 7] Internet-Draft LISP Map Server August 2011 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 secret shared-key. 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 be 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- Fuller & Farinacci Expires March 2, 2012 [Page 8] Internet-Draft LISP Map Server August 2011 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 does set 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 supported directly by the mapping system. 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-Regsiter 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 "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. 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 Fuller & Farinacci Expires March 2, 2012 [Page 9] Internet-Draft LISP Map Server August 2011 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 answered 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, or learned from associated ETRs when the Map Resolver is also acting as a Map Server). If it finds a matching entry, it returns a non-authoritative LISP Map-Reply with the known mapping. If the Map Resolver does not have the mapping entry and if it can Fuller & Farinacci Expires March 2, 2012 [Page 10] Internet-Draft LISP Map Server August 2011 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 forwards the unencapsulated Map-Request, with the original ITR RLOC as the source, on to the distributed mapping database. Using a LISP+ALT mapping database, 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 information from the Encapsulated Map-Request, including the ITR RLOC and the original 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-Rqeuest 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 Fuller & Farinacci Expires March 2, 2012 [Page 11] Internet-Draft LISP Map Server August 2011 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. Fuller & Farinacci Expires March 2, 2012 [Page 12] Internet-Draft LISP Map Server August 2011 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 Feasibility, performance, and complexity trade-offs of implementing caching in Map Resolvers 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. Fuller & Farinacci Expires March 2, 2012 [Page 13] Internet-Draft LISP Map Server August 2011 6. IANA Considerations This document makes no request of the IANA. Fuller & Farinacci Expires March 2, 2012 [Page 14] Internet-Draft LISP Map Server August 2011 7. Security Considerations The 2-way 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-160 [RFC2104] and should support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated to 128 bits). During experimental and prototype deployment, authentication key changes 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 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 exchange. 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 the 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. Fuller & Farinacci Expires March 2, 2012 [Page 15] Internet-Draft LISP Map Server August 2011 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-07.txt (work in progress), June 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. Fuller & Farinacci Expires March 2, 2012 [Page 16] Internet-Draft LISP Map Server August 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. Fuller & Farinacci Expires March 2, 2012 [Page 17] Internet-Draft LISP Map Server August 2011 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. Fuller & Farinacci Expires March 2, 2012 [Page 18] Internet-Draft LISP Map Server August 2011 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 Fuller & Farinacci Expires March 2, 2012 [Page 19] --tThc/1wpZn/ma/RB Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="rfcdiff-ms-10-to-11.html" rfcdiff
 
IETF Home
About Tools
Tools:
diffs spell
xml2rfc idnits
tracker src
News
Get Passwd
IETF-82:
Rooms
Agenda
Calendar
Documents
RFCs
Doc fetch:
Wikis:
IESG IRTF
IAOC RSOC
Chairs Edu
Tools BOFs Development
NomCom
Areas
WGs:
concluded…
6lowpan*
6man
6renum
Abfab
Adslmib
Alto
Ancp
Appsawg*
Armd
Atoca
Autoconf
Avtcore*
Avtext*
Behave
Bfd
Bliss
Bmwg
Ccamp
Cdni
Clue
Codec
Conex
Core
Csi
Cuss
Dane
Dccp
Decade
Dhc
Dime*
Dispatch
Dkim
Dnsext
Dnsop
Drinks
Eai
Ecrit
Eman
Emu
Fecframe
Forces
Ftpext2
Geopriv
Grow*
Hip
Hokey
Homenet
Httpbis
Hybi
Idr
Intarea
Ipfix
Ippm
Ipsecme
Iri
Isis
Karp
Kitten*
Krb-wg
L2tpext
L2vpn
L3vpn
Ledbat
Lisp
Lwig
Manet
Marf
Mboned
Mediactrl
Mext
Mif
Mip4
Mmusic
Mpls*
Mptcp
Msec
Multimob
Nea
Netconf
Netext
Netmod
Nfsv4
Ntp
Oauth
Opsawg
Opsec
Ospf*
P2psip
Paws
Payload
Pce
Pcn
Pcp
Pim*
Pkix
Pppext*
Ppsp
Precis
Pwe3
Radext
Rmt
Roll*
Rtcweb*
Rtgwg
Salud
Savi
Sidr*
Sieve
Simple*
Sipclf
Sipcore
Siprec
Soc
Softwire*
Speechsc
Speermint
Splices
Storm*
Tcpm
Tictoc
Tls
Trill
Tsvwg
Urnbis
V6ops
Vcarddav
Vipr
Websec
Xcon
Xmpp
Xrblock
Yam

* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Rfcdiff Tool
Version: 0.11
Author:

Rfcdiff Web Service

File 1 -   Upload file:  
or enter URL:  
 
File 2 -   Upload file:  
or enter URL:  
 
Output format: Side-by-side diff
Before-after diff
Changebars
Html wdiff
Html Wdiff Options:
Colour of old text:
Colour of new text:
Larger diff text:
Column width:

You can also use this web-service with an URL query-string of the form:

http://tools.ietf.org//rfcdiff?url1=http-url-to-doc-1&url2=http-url-to-doc-2

which makes it possible to send around links to diffs between document versions withouth actually generating the diff yourself, as long as the two document versions are available by http.

Example (yes, it is long - no way to get around that... - but you could use tinyurl.com to get a short alias to one of these):

http://tools.ietf.org/rfcdiff?
  url1=http://tools.ietf.org/id/draft-ietf-atompub-format-10.txt
  &url2=http://tools.ietf.org/id/draft-ietf-atompub-format-11.txt




Generated from PyHt script /rfcdiff Latest update: 24 May 2011 09:22 GMT -
--tThc/1wpZn/ma/RB-- From internet-drafts@ietf.org Tue Aug 30 10:49:28 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 99C6C21F8DD2; Tue, 30 Aug 2011 10:49:28 -0700 (PDT) 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 WtasQYEj2t29; Tue, 30 Aug 2011 10:49:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7A521F8DC1; Tue, 30 Aug 2011 10:49:28 -0700 (PDT) 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.60 Message-ID: <20110830174928.1827.4829.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 10:49:28 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ms-11.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, 30 Aug 2011 17:49:28 -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 Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-11.txt Pages : 19 Date : 2011-08-30 This draft describes the LISP Map Server (LISP-MS), a computing system which provides a simplified LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map Server is to reduce implementation and operational complexity of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge&= quot; of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-11.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-11.txt