From luigi@net.t-labs.tu-berlin.de Tue Mar 3 10:48:12 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B5728C303 for ; Tue, 3 Mar 2009 10:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj+MnZKVTuC4 for ; Tue, 3 Mar 2009 10:48:10 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 45F6528C2F3 for ; Tue, 3 Mar 2009 10:48:00 -0800 (PST) Received: from dyn100.net.t-labs.tu-berlin.de (dyn100.net.t-labs.tu-berlin.de [130.149.220.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id D1854700D48B; Tue, 3 Mar 2009 19:22:44 +0100 (CET) Message-Id: From: Luigi Iannone To: rrg@irtf.org, lisp@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-25-99326634 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 19:22:44 +0100 References: <20090303181503.470533A67F2@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Cc: Olivier Bonaventure Subject: [lisp] Fwd: I-D Action:draft-iannone-lisp-mapping-versioning-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 18:48:13 -0000 --Apple-Mail-25-99326634 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi All, A new draft is available proposing a modification of the current lisp header format. Comments are welcome. Cheers Luigi Note: The draft is not meant to be considered for interoperability test concerning lisp implementation. For that purpose the reference is still the original lisp draft (now at version 12). Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 3, 2009 7:15:02 PM GMT+01:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-iannone-lisp-mapping-versioning-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : LISP Mapping Versioning > Author(s) : L. Iannone, et al. > Filename : draft-iannone-lisp-mapping-versioning-00.txt > Pages : 22 > Date : 2009-03-03 > > The present document sketches an alternative approach to provide > information about changes to EID-to-RLOC mappings in the context of > LISP. The proposed approach is based on a versioning system for the > EID-to-RLOC mapping itself. When there is a change in the mapping > (where change could mean adding/removing an RLOC or just a > modification in the priority or weight of one or more RLOCs) a new > version number is generated and propagated in the LISP data packet. > In the LISP context, ETRs do not keep state that allows to know when > an ITR changes a mapping. The versioning system is a data-driven > mechanism to annonce those changes. > > In order to support such an approach, the LISP encapsulation need to > be modified. In particular LISP-encapsulated data packets have to > contain the version number of the mapings used to select the RLOCs in > the outer header. These version numbers are contained in a "new" > LISP header. > > The mappings are distributed as usual through the mapping > distribution system (e.g., CONS, ALT); versioning is only a mean to > announce that something has changed in the mapping. The > infrastructure built by each specific mapping protocol does not > change anyhow. Nevertheless, two modifications are needed. The > first modification consist in including version number in the Map- > Reply messages. The second modification consist in the introduction > of a new message, the "Map-Update-Notification" message used by ETRs > to notify ITRs that the mapping used to encapsulate the packet is old > and needs to be updated. This message does not contain the mapping, > it just suggests ITRs to perform a Map-Request in order to retrieve > the updated mapping. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iannone-lisp-mapping-versioning-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-25-99326634 Content-Type: multipart/mixed; boundary=Apple-Mail-26-99326635 --Apple-Mail-26-99326635 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi All,

A = new draft is available proposing a modification of the current lisp = header format.

Comments are = welcome.

Cheers

Luigi

Note: The draft is not meant to be considered for = interoperability test concerning lisp implementation.
For that = purpose the reference is still the original lisp draft (now at version = 12).


Begin forwarded message:

Date: March 3, 2009 7:15:02 PM = GMT+01:00
To: i-d-announce@ietf.org
Subject: = I-D = Action:draft-iannone-lisp-mapping-versioning-00.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

Title =           : LISP = Mapping Versioning
Author(s) =       : L. Iannone, et al.
Filename =        : = draft-iannone-lisp-mapping-versioning-00.txt
Pages =           : = 22
= Date =            : = 2009-03-03

The present document sketches an alternative approach = to provide
information about changes to EID-to-RLOC mappings in the = context of
LISP.  The proposed approach is based on a versioning = system for the
EID-to-RLOC mapping itself.  When there is a = change in the mapping
(where change could mean adding/removing an = RLOC or just a
modification in the priority or weight of one or more = RLOCs) a new
version number is generated and propagated in the LISP = data packet.
In the LISP context, ETRs do not keep state that allows = to know when
an ITR changes a mapping.  The versioning system is = a data-driven
mechanism to annonce those changes.

In order to = support such an approach, the LISP encapsulation need to
be modified. =  In particular LISP-encapsulated data packets have to
contain = the version number of the mapings used to select the RLOCs in
the = outer header.  These version numbers are contained in a = "new"
LISP header.

The mappings are distributed as usual = through the mapping
distribution system (e.g., CONS, ALT); versioning = is only a mean to
announce that something has changed in the mapping. =  The
infrastructure built by each specific mapping protocol does = not
change anyhow.  Nevertheless, two modifications are needed. =  The
first modification consist in including version number in = the Map-
Reply messages.  The second modification consist in the = introduction
of a new message, the "Map-Update-Notification" message = used by ETRs
to notify ITRs that the mapping used to encapsulate the = packet is old
and needs to be updated.  This message does not = contain the mapping,
it just suggests ITRs to perform a Map-Request = in order to retrieve
the updated mapping.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iannone-lisp-map= ping-versioning-00.txt

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is = the data which will enable a MIME compliant mail = reader
implementation to automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-26-99326635 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-03-03100844.I-D@ietf.org>

--Apple-Mail-26-99326635 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-26-99326635-- --Apple-Mail-25-99326634-- From rw@firstpr.com.au Wed Mar 4 09:35:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A388928C41D for ; Wed, 4 Mar 2009 09:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6Lvs-0d6Cbb for ; Wed, 4 Mar 2009 09:35:39 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id CA59228C41E for ; Wed, 4 Mar 2009 09:35:33 -0800 (PST) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 9121D175E5F; Thu, 5 Mar 2009 04:35:58 +1100 (EST) Message-ID: <49AEBC00.9070306@firstpr.com.au> Date: Thu, 05 Mar 2009 04:36:00 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: RRG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: [lisp] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 17:35:40 -0000 Short version: The Devil is in the detail, but the I-Ds don't yet have all the details. Multiple levels of caching is good in some ways and troublesome in others. To: RRG, CC: LISP list. I suggest discussing this on the RRG list. I figure all people are on the RRG list, but not vice-versa. The questions of multiple points of caching are of general architectural interest regarding potential scalable routing solutions other than LISP. There is a new LISP I-D (2009-03-03): http://tools.ietf.org/html/draft-fuller-lisp-ms-00 and an updated one (2009-03-02) to match: http://tools.ietf.org/html/draft-farinacci-lisp-12 LISP Map Server draft-fuller-lisp-ms-00 Abstract This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simple 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 simplify the implementation and operation 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. My understanding of and comments on this are: Instead of ITRs and ETRs needing to act as routers in the ALT network, they communicate via the ordinary Internet with Map Servers, which are routers on the ALT network. This will greatly reduce the complexity and configuration difficulties of ITR and ETRs. These Map Server devices are implicitly local to the ITRs and ETRs in a given network and are intended to be used only by those ITRs and ETRs. They are always on RLOC (stable, globally reachable, non LISP-mapped) addresses. There are two functions which may be combined in the one device: Map Resolver (MR) Accepts a mapping query from an ITR and (usually) sends the ITR a mapping reply. (The exception is if the MR doesn't have the information and sends the query verbatim to some other device, which will answer the query directly to the ITR.) MRs can be caching or non-caching. More on that below. ITRs are intended to be configured with a single address for their local MR. This would raise questions of robustness if not for the next item: Multiple MRs in a local network (such as an ISP network or I guess any end-user network which has ITRs) can be configured on the one anycast address. This way, the ITR's request will be forwarded to the nearest currently active MR. All communication is via single packets, not via TCP. Presumably the MRs will also have their own unique addresses so they can be managed via TCP. I think the MR is an important improvement to LISP-ALT, since it enables an ITR to be a much more casual and unstable concept than was the case when all ITRs needed to participate in the ALT network as routers (AFAIK). This means that ITRs can be added easily, without having to configure anything. It also means (though this is my suggestion, not from the LISP team) that an ITR function could easily be implemented in a sending host, assuming it was not behind NAT. I guess the sending host would need to be on an RLOC address - which rules out this idea for sending hosts in end-user networks. Ivip's ITR in sending host function (ITFH) requires the host to be on a non-NAT address which can be and ordinary or a Scalable PI address - RLOC or EID in LISP parlance. Map Server (MS) Is a router on the ALT network and accepts secure messages from one or more ETRs. (Secret key pairs to secure these.) ETRs are (typically, or always?) the authoritative source of mapping information in LISP. ETRs can be on any RLOC address and use ordinary packets to communicate with the MS. My understanding is that the MS announces the appropriate prefixes on the ALT network - one for every EID the ETR tells it. Ignoring MSes for a moment, I have never understood how this would work with two ETRs in two separate ISPs handling the same EID. Both ETRs would be routers on the ALT network and would announce the same prefix. So where do packets go to? I guess to either. But then the ETRs somehow need to coordinate themselves, or be coordinated by something else, so they act in a unified manner. Then, as long as both were reachable and working properly, it wouldn't matter which ETR got the query. The same problem seems to apply with MSes. There would be two ETRs in two separate ISPs and each would presumably (for robustness in a multihoming situation and probably for security reasons) have its own MS in its own ISP network. So now we have two ETRs and two MSes which need to be coordinated. The two MSes both announce the one EID prefix on the ALT network. Yet they are supposed to still be coordinated during outages. However this is resolved, I think it is a big improvement for LISP to have MSes, since it reduces the cost, complexity, management effort etc. for ETRs similarly to how MRs do the same for ITRs. Both these functions can presumably be performed quite adequately by software devices, such as a COTS server with suitable software. There doesn't have to be any hardware router FIB etc. AFAIK. This would enable hardware routers to assume ITR and ETR responsibilities without them also needing all the software and configuration, stable address etc. to be an ALT router. Also, by decreasing the total number of ALT routers, this simplifies the ALT network. I gather from this new I-D, and from what I read in: http://www.lisp4.net/docs/lisp-ausnog02.ppt that the current test network and the intention for the future is not to send traffic packets on the ALT network. This approach was initially an option, with the intention that the ALT network would forward the initial packet(s) to the correct ETR, which would then forward it to the destination network, while also recognising it as a map request and so would send a map reply message to the ITR. I recall from somewhere that the ITR typically sends out a few mapping requests, just in case one of them is dropped. When the ITR connects directly to the ALT network, these packets presumably usually traverse the entire global ALT network until they are delivered to one or more (probably just all to one) ETR which responds. I guess the ETR sends multiple replies, but maybe not. The reply goes to the ITR via the ordinary Internet. Removing these potentially long and voluminous traffic packets from the ALT network seems like a good idea to me. There may well be security benefits in doing so too. Below, I assume the ALT network only carries mapping requests, and that the map replies go back from whatever answers them (an ETR connected to ALT network, or more likely a Map Server) via a direct ordinary Internet packet to the device which made the query (perhaps a directly connected ITR or more likely a Map Resolver). A Caching Map Resolver? If the MR caches, then it has the potential to significantly reduce the traffic on the ALT network. This is due to two or more ITRs in a given ISP network wanting the same mapping, and the second and subsequent ones getting it directly from the local caching MR. This also has the potential to eliminate, for the second and subsequent ITRs which need this mapping, the major problem of "LISP-ALT's initial packet delays", so much debated on the RRG in recent months. There is nothing in draft-fuller-lisp-ms-00 to describe this caching behavior. The caching time of map replies is specified in units of one minute: draft-farinacci-lisp-12: Record TTL: The time in minutes the recipient of the Map-Reply will store the mapping. Let's say at time T = 0 minutes, ITR-A sends a map request to MR-1, which has no mapping for the EID prefix which matches the EID address in the request message. MR-1 sends its own map request message (with its own nonce) onto the ALT network which forwards it to either the single Map Server which advertises the matching EID prefix on the ALT network, or to one of the multiple such Map Serves, or perhaps to the directly ALT-connected ETR(s) which do the same. That device sends the mapping reply back to MR-1 directly via the Internet. The reply is secured by returning MR-1's nonce. Let's say the mapping reply comes back with a 90 minute caching time. MR-1 sends to ITR-A a map reply, with ITR-A's request's nonce, with the fresh mapping information and a caching time of 90 minutes. Now MR-1 can encapsulate packets to its choice of ETRs, based on the fresh mapping it has received and whatever it has determined about reachability of those ETRs, and of the ETRs' ability to get packets to the destination network. Later, at T = 85 minutes, ITR-B sends a mapping request to MR-1 for an address which matches this same EID prefix. MR-1 can use its cached information and send a reply within a few milliseconds. This means ITR-B's traffic will not be delayed by any significant amount. What caching time will be in that reply to ITR-B? I assume it will be 5 minutes. If it would be 90 minutes, ITR-B could be running for a long time to come on stale mapping information. Assuming ITR-A no longer needs this EID's mapping, but ITR-B keeps needing to tunnel packets addressed to this EID, then at T=90 minutes, ITR-B will want mapping information again. Should ITR-B request the mapping again at at T = 88 minutes, in readiness for probably needing it in 1 minute's time? This would seem like a generally reasonable approach if it prompted MR-1 to get fresh mapping information, but why should MR-1 do this? Would MR-1 need to look at the original caching time and how much has expired to decide whether it should, by some algorithm, request fresh mapping? But what if the mapping hadn't changed in the distant Map Server, but the ETR was going to change it two minutes later? If ITR-B waited until T = 90 or a little later before requesting fresh mapping, then unless MR-1 had already got fresh mapping in the last minute or two, then there would presumably be a delay in the ITR being able to handle traffic for this EID, since it would take some time for MR-1's second mapping request to traverse the ALT network and generate a reply to MR-1. There are various scenarios, but I think there are potential difficulties with caching times running out in three locations now rather than one. Previously, it was simple (despite the scaling problems of lots of ITRs peppering an ETR for mapping, not to mention them all trying to decide reachability for this and other ETRs): ITR query -----------> ETR <----------- reply cache Now we have: ITR query -----> Map query -----> Map <----- reply Resolver <----- reply Server <--Register- ETR Cache Cache Cached, in a sense, controlled by messages from the ETR(s) whenever they can reach the Map Server and decide to send a Map Register message. I think this raises more complex problems with: 1 - How to avoid cache times running out at ITRs which are going to be tunneling packets addressed to this EID after the cache time expires. Such a situation will cause a traffic delay unless the local Map Resolver has recently got fresh mapping. 2 - How to minimise unnecessary map requests by Map Resolvers trying to anticipate ITRs making such requests, but actually requesting fresh mapping from the distant Map Server when the ITR doesn't need it. Without further complications, the Map Resolver can't know whether the one or more ITRs which requested the mapping for an EID are still handling traffic for that EID. So it can't very well request fresh mapping towards the end of its expiry, just in case an ITR wants it. To do so would approximately double the volume of map requests traversing the ALT network, since it is reasonable to assume, with longish caching times, that the original caching time will generally suffice for the needs of the one or more ITRs served by the Map Resolver. (This would not be true with a busy Map Resolver and popular EIDs many ITRs are sending packets to.) Without some elaboration of the request protocol, ITR-B at T = 85 minutes can't ask the Map Resolver to get fresh mapping and send it a new reply - unless there is some algorithm in the Map Resolver such as: "If the cached mapping is 90% of the way to its expiry time, do not answer the new request from the cache, but send a fresh map request and then answer the query if and when the new reply arrives." To do so would effectively shorten all the caching times. At present, there is only one kind of map request message from an ITR to a Map Server - implicitly an urgent request. If there was a second kind: "This ITR has mapping for this EID which will expire in some time period (specified) soon, and requests the Map Resolver to get fresh mapping from the Map Server now, and to send a reply once this arrives." then I think these problems would be resolvable with less trouble and less need for choices based on limited information. - Robin From rw@firstpr.com.au Wed Mar 4 10:00:34 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21EE23A6CB0 for ; Wed, 4 Mar 2009 10:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO8wafcVus0v for ; Wed, 4 Mar 2009 10:00:32 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id C4EFF3A6B79 for ; Wed, 4 Mar 2009 10:00:31 -0800 (PST) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 11C581759CF; Thu, 5 Mar 2009 05:00:58 +1100 (EST) Message-ID: <49AEC1DC.3020001@firstpr.com.au> Date: Thu, 05 Mar 2009 05:01:00 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: rrg@irtf.org References: <20090303181503.470533A67F2@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] [rrg] Fwd: I-D Action:draft-iannone-lisp-mapping-versioning-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:00:34 -0000 Hi Luigi, I read your new I-D: http://tools.ietf.org/html/draft-iannone-lisp-mapping-versioning-00 and have the following comments and questions. I understand this is a proposed change to the LISP protocol. I guess it is independent of the work of the main LISP-ALT team, who have updated their main I-D and added a new one: http://tools.ietf.org/html/draft-fuller-lisp-ms-00 http://tools.ietf.org/html/draft-farinacci-lisp-12 in recent days, in ways which seem unrelated to your suggestion. I guess that your suggested replacement of LISP's Locator Reachability Bits system with the new Versioning system is motivated by problems you encountered, or anticipated, as part of your OpenLISP project. I don't clearly understand all the ways the Locator Reach Bits are intended to be used. There is a complex description within six pages of material 6.2 to 6.5.2: http://tools.ietf.org/html/draft-farinacci-lisp-12 However, I can well imagine that there would be problems with Locator Reachability Bits. Your section 9.2 includes a critique of these lists of bits having holes in them as RLOCs are added to or removed from the list. I have not been able to understand to what extent the various bits sent by various ETRs are coordinated with the bits sent by other ETRs. You also mention security problems (10.2): ... with explicit reachability bits where an attacker can set all RLOCs to down with one single packet, with disruptive consequences on the traffic. I don't understand how these bits can be used securely, but I assume there is a genuine problem motivating your proposal to replace them with a versioning system. I think I understand the Destination Mapping Version part of your proposal: All mapping distributed by the ALT network contains an additional 15 bit Destination Mapping Version number, which is incremented for every new version of the mapping information. (This, and the similar 15 bits for Source Mapping Version, are intended to replace the Reachability Bits in the the LISP traffic packet header.) This Destination Mapping Version number is cached at the ITR, and in every traffic packet the ITR encapsulates, the (modified) LISP header includes this 15 bit number. When the encapsulated packet arrives at the correct ETR, this ETR is the authoritative source of mapping for the destination EID - or at least is directly controlled by, or in communication with, whatever it is which is the authoritative controller of that mapping. Therefore, the ETR knows the latest mapping version number for this EID. If an ITR-X is sending packets with an older version of the mapping, then the ETR can quickly determine this and send a Map Update Notification Message to ITR-X. This should prompt ITR-X to look up the mapping for this EID in the usual, secure, manner - and so hopefully get the latest mapping with the latest version number. There is nothing secure about such a message - so any attacker could generate one and send it to any ITR. (The ITR might be fussy about the source address of such messages, but an attacker could easily find out the address of an authoritative ETR for this EID, and send a spoofed message with that source address. Also, if the ITR was to be fussy about the source address of the message, that would need to be based on RLOCs in older mapping information, and this would make it difficult to adapt to new ETRs which are in fact authoritative.) In order to respond to genuine Map Update Notification messages, the ITR needs to respond to spoofed ones too - since it can't tell the difference. When it gets such a message, which I will assume is genuine, the ITR requests fresh mapping for the EID specified in that message. With the ordinary ALT network, this involves a possibly or typically global path (or longer, due to the LISP-ALT long-path problem) for the query packet over the ALT network, and then a rapid, though still potentially global distance, response from the ETR (or whatever responds to the request). So I think your proposal is in some ways at least an attempt to improve the responsiveness of the LISP system to changes in whatever is happening with an EID's ETRs, in ways which are more efficient than simply shortening the caching time of the map replies. LISP mapping caching time is specified in units of minutes. If an ETR answered all queries with replies containing a 1 minute caching time, then as long as ITRs respected this (which can generally be assumed, though some operators might decide this short time was unreasonable) and as long as ITRs requested fresh mapping a few seconds before the cache time expired (since I think it may take a seconds or two or more to get it over the global ALT network) then the ITR would always have mapping data which was no more than 1 minute behind whatever was the latest. However, this is generally unscalable, since it would burden the ITRs and the ETRs with a great deal of processing and traffic. Worse still, it would burden the global ALT network with a great deal more query traffic. While the ITR and the ETR operators are directly involved in the communications and so are getting paid according to the usage, there must be operators of ALT routers which these query packets traverse who have a difficult time getting paid by the ITR and ETR operators according to the burden of query traffic these operators place on the ALT network routers between them. So I guess you are assuming something like the caching time being "long" such as 120 minutes, and the Versioning system being used only occasionally to cause ITRs to get fresher mapping than would otherwise be the case. If your Versioning system repeatedly involved new mapping every 10 minutes, for instance, then I think it would be simpler and more efficient to simply set the caching time in the replies to 10 minutes and let the standard ITR caching mechanism do its work. Can you comment on my understanding that Versioning is best for generating fast responses in all the world's ITRs to changes in mapping which do not happen all that frequently? (I think there are typos in the last paragraph in section 3.) I do not clearly understand the following: 5. Dealing with Version Numbers OK The main idea of using Mapping Version Numbers is that whenever there is a change in the mapping (e.g., adding/removing RLOCs, a change in the weights due to new TE policies, or a change in the priorities) or ?? an ISP realizes that one or more of its own RLOCs are not reachable anymore from a local perspective (e.g., through IGP, due to route flap, or policy changes) the ISP updates the mapping with a new mapping version number. I understand the need for a new version number if there is a change in the existence or addresses of ETRs, or in the priority of the ETRs (to control the ITRs' choice of ETR when two or more are reachable) or in the weighting (to tell the ITR how to spread traffic between multiple ETRs). I don't understand the second section, where an ISP does something because one of its ETRs has become unusable for traffic - for instance it may be reachable by one or all ITRs, but its link to the destination network is broken, or questionable. Assuming the whole purpose of this is to support multihoming, and assuming the one destination network has an ETR-A in ISP-A and an ETR-B in ISP-B, then I don't know how one ISP can act unilaterally to change the mapping in some way. Part of my difficulty is that I have never been able to understand in practical terms how the two ISPs are supposed to securely coordinate their two ETRs, or whatever it is which controls their ETRs, so the two act in a unified manner regarding responding to mapping requests - and now including version numbers. These ISPs may not know each other, like each other or trust each other. There could be 10,000 ISPs, with hundreds of millions of multihomed customers, and a very wide spread of customers choosing ISPs. Any one ISP might have 10,000 customers, and those customers other ISPs could number in the hundreds or thousands. So how is any one ISP supposed to securely coordinate its ETRs with the ETRs of hundreds or thousands of other ISPs? This is a major critique of LISP in general - not of your Versioning system. I haven't raised it before, but I have never been able to understand how this could scale well. Those customers will be chopping and changing ISPs frequently and I can't see how the ETRs are supposed to reliably and securely communicate when they most need to - when there are outages in the DFZ and/or inside each ISP's network. (Ivip doesn't have any such problems: the ETRs simply decapsulate packets and handle a PMTUD protocol with ITRs. For modified header forwarding, the ETRs have no such protocol or communication with the ITRs at all. At no time do ETRs communicate with each other, either within or between ISPs.) Returning to the section I couldn't understand: ?? an ISP realizes that one or more of its own RLOCs are not reachable anymore from a local perspective (e.g., through IGP, due to route flap, or policy changes) the ISP updates the mapping with a new mapping version number. Does this mean the ISP would generate a different mapping, temporarily removing the faulty ETR, so that the other ISP's ETR would be the only one which an ITR could choose to tunnel packets to? If so, how is this to be coordinated with the other ISP? Surely the other ISP's ETR would need to change its mapping and give out the new version number too - but there is an outage going on, affecting the ETR in some way so it could be difficult to coordinate the two. Alternatively, do you mean that the ISP doesn't change its mapping, but only changes the version number? I doubt this, but then why would you describe it separately from simply adding and/or removing an RLOC? The last two dot points in 5.1 contain frequent references to an ETR dropping traffic packets tunnelled to it by an ITR, or at least apparently by an ITR. (ETR cannot know the IP addresses of all ITRs, or whether a specific IP address is of an ITR. Even if they could, attackers could send encapsulated packets with a spoofed outer source address.) You suggest that if packets arrive with an old (or too high, not recently used) Destination Mapping Version number, despite the ETR trying repeatedly to prompt the ITR to update its mapping, that the ETR could drop the packets. Here are the scenarios I can imagine: 1 - The packets are sent by an attacker. It is good to drop them, but there is no way an ETR can be sure they came from an attacker - so this is not a reasonable option. 2 - The packets are genuine traffic packets. The ETR is the correct ETR for packets with this destination EID address. Even though the version number might be wrong, the ITR is nonetheless tunneling the packets to the right place, so why drop them? 3 - The packets are genuine traffic packets. The ETR is not the correct ETR. It should try to prompt the ITR into updating its routing, but the question of dropping the packets does not arise, because the packets are already in a black hole due to being tunnelled to the wrong ETR. ETRs are not and cannot be in the business of trying to send the packets to some other ETR. So I can't imagine what sense there is in an ETR deciding whether or not to drop traffic packets. Even if there was a reason for dropping them, there seems little point in dropping packets just because they arrive with a too-high version number. An attacker can easily send them with the right version number, so there is no reason to think that these packets arise from an attacker. Attackers can be assumed to have access the mapping system in some way - it is a global, public, system and there is no way of fencing it off entirely from someone who really wants to query it. Also, the mapping system arguably needs to be open to public scrutiny, if only for debugging purposes and for helping to understand where traffic is actually going. Can you confirm my understanding of the Source Mapping Version number system? A device AAA, acting as an ITR, sending Source Mapping Version numbers in the LISP header of encapsulated traffic packets to a device BBB acting as an ETR is doing so in the expectation that BBB will soon be, or is already, acting as an ITR and needs to tunnel packets which are addressed to the EID of the original sending host aaa which sent packets to AAA's ITR function. Since that sending host aaa is presumably in some end-user network using ETRs in the ISP which runs AAA, then the AAA device presumably has an up-to-date Destination Mapping Version number for the EID which aaa's address matches. - Robin From dino@cisco.com Wed Mar 4 10:08:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98ED83A6CC9 for ; Wed, 4 Mar 2009 10:08:25 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImaDzzv0zPlK for ; Wed, 4 Mar 2009 10:08:24 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 922F43A6BB1 for ; Wed, 4 Mar 2009 10:08:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,301,1233532800"; d="scan'208";a="139377223" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2009 18:08:53 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n24I8raf001493; Wed, 4 Mar 2009 10:08:53 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n24I8qqx023381; Wed, 4 Mar 2009 18:08:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 10:08:52 -0800 Received: from [192.168.1.5] ([10.21.126.4]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 10:08:51 -0800 Message-Id: <60970FDB-3CBE-47C0-B613-80EAF6F371CD@cisco.com> From: Dino Farinacci To: Robin Whittle In-Reply-To: <49AEC1DC.3020001@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 10:08:52 -0800 References: <20090303181503.470533A67F2@core3.amsl.com> <49AEC1DC.3020001@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 04 Mar 2009 18:08:51.0739 (UTC) FILETIME=[4603FEB0:01C99CF4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=448; t=1236190133; x=1237054133; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[rrg]=20Fwd=3A=20I-D=20Action= 3Adraft-iannone-lisp-mapping-versioning-00.txt |Sender:=20; bh=aArjf0c3BHSl8uyj7yZDvLQbxmk0gChwqTIPztGmXfg=; b=BFylkmyBYF/pkDSKPAzjleDMUipbymTRqjfqirwnJ9MWp7vEJjtJnJDpAS 11YWNG6mf9iwPYs5WJZy8fufwDyl/GxbdehnjqC8HGppOOXUl/WAEe2qaI5j HkW3Mx5cDCWN6yWaEoMw3w3eKTYca3F3NNO7U1+0mUVPyR3Ij00LM=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: rrg@irtf.org, lisp@ietf.org Subject: Re: [lisp] [rrg] Fwd: I-D Action:draft-iannone-lisp-mapping-versioning-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:08:25 -0000 > I understand this is a proposed change to the LISP protocol. I guess > it is independent of the work of the main LISP-ALT team, who have > updated their main I-D and added a new one: > > http://tools.ietf.org/html/draft-fuller-lisp-ms-00 > http://tools.ietf.org/html/draft-farinacci-lisp-12 > > in recent days, in ways which seem unrelated to your suggestion. Yes the two efforts are completely independent and not related. Dino From damian.lezama@hotmail.com Thu Mar 5 08:41:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB0B28C312 for ; Thu, 5 Mar 2009 08:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKDAvfg+YPu3 for ; Thu, 5 Mar 2009 08:40:59 -0800 (PST) Received: from col0-omc2-s3.col0.hotmail.com (col0-omc2-s3.col0.hotmail.com [65.55.34.77]) by core3.amsl.com (Postfix) with ESMTP id 8542728C0D0 for ; Thu, 5 Mar 2009 08:40:59 -0800 (PST) Received: from COL110-DS19 ([65.55.34.72]) by col0-omc2-s3.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 08:41:28 -0800 X-Originating-IP: [24.87.8.194] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: , Date: Thu, 5 Mar 2009 08:41:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdsTNus8iUByvdQuaZaUnw3+zxcQ== Content-Language: en-us X-OriginalArrivalTime: 05 Mar 2009 16:41:28.0761 (UTC) FILETIME=[3B5ECA90:01C99DB1] Subject: [lisp] Concerns about LISP Reachability Bits X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 16:41:00 -0000 Hi, Since mapping versioning has been raised for discussion I'd like to comment some concerns I have about Lisp Reachability Bits. While versioning seems to solve part of this I think some issues still remain. 1. Reporting local reachability complicates implementation of ITRs: Every time an ITR encapsulates a package it needs to report local reachability of the site's ETRs. Not only ITRs must know it (Map Server proposes lighter ITRs) but there are also ugly failures to take into account i.e. ITRs in the site getting isolated one from another but both working. 2. Reachability bits don't solve the problem completely: As this bits detect only some reachability problems ITRs will also use other mechanisms. To be on the safe side some ITR implementations will probably send Map Requests after a short period detecting only outbound traffic to some RLOC (and repeat as often as the standard allows while this condition continues). Is it worth having this complicated reachability bits mechanism if it doesn't help us much? 3. Ugly failures appear also here (from LISP draft) The ETRs, at the site with the changed mapping, records the fact that the site that sent the Map-Request has received the new mapping data in the mapping cache entry for the remote site so the loc-reach-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending packets with the SMR-bit set. ETRs can never be sure if the remote site received or not the Map Replies. What if they didn't? What if (or while) some ITRs did and some didn't? Having an old mapping is bad enough, having reachability bits inconsistent with the mapping gets the problem worse. Versioning looks good to solve this one. Regards, Damian Lezama From rw@firstpr.com.au Thu Mar 5 21:40:30 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE033A6808 for ; Thu, 5 Mar 2009 21:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93Xqx-ZGv5lx for ; Thu, 5 Mar 2009 21:40:29 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 975343A6C12 for ; Thu, 5 Mar 2009 21:40:28 -0800 (PST) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 5938A175A6F; Fri, 6 Mar 2009 16:13:03 +1100 (EST) Message-ID: <49B0B0E3.5050801@firstpr.com.au> Date: Fri, 06 Mar 2009 16:13:07 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: rrg@irtf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] [rrg] Concerns about LISP Reachability Bits X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 05:40:30 -0000 Short version: A core-edge separation scheme such as LISP which does not use real-time mapping distribution to control the behavior of ITRs therefore needs some way each ITR can decide which of multiple RLOCs to use. Attempts to improve this real-time process include the ETR sending locator reachability bits and the use of versioning in the mapping information. LISP also involves ETRs being the authoritative source of mapping information. This raises further technical and administrative questions about how the ETRs for one end-user network, which are typically in different ISPs, can work together securely and reliably, especially at times of outages and other sources of network instability. With a real-time mapping distribution architecture, as used by Ivip, there is no need for ITRs to make such decisions - and ETRs can be much simpler, with no need to communicate with ITRs at all, and no need for them to be coordinated in any way. Also, end-user networks can probe reachability and decide which ETR will be used, in real time, with any techniques they like. Hi Damien, While I only partially understand this part of LISP, I share your concerns about ETRs sending real-time reachability information to ITRs. Even if it was secure (which I understand it is not) there are all sorts of problems with different ETRs having a different understanding of the reachability of all the ETRs for a given EID prefix, and then the ITR receiving multiple differing sets of locator reachability bits from different ETRs at different times. Also, I think there is a problem with the bits needing to refer to a specific order of RLOC addresses, as defined in the complex mapping data. When the ITR receives a mapping reply with a different order of RLOCs than the one it has cached, then it can be difficult for an ITR to know whether the bits it receives relate to the current or to a previous order of RLOCs. With LISP, I have no idea how the ETRs of a particular end-user network are supposed to coordinate their activities so as to be able to do anything consistent or reliable regarding telling ITRs which ETRs are currently reachable, or at least which are reachable from the DFZ and are also connected well (not congested) to the destination network. These ETRs are going to be in different ISPs, so how are the ISPs supposed to configure their ETR to communicate reliably and securely with ETRs in some other ISP, for every single end-user network which uses that ETR? When things are getting rough, with outages, traffic flowing in different ways to get around the outage, congestion, misconfiguration etc. how are the ETRs supposed to communicate reliably to work consistently together? How are they supposed to decide what the real reachability situation is? Likewise the mapping information? There might be three ETRs in different ISPs, each in some way configured by one or more ISPs and/or in some way controlled by the end-user network in terms of the mapping information they send out to the APT network (or register with their respective Map Servers which do this). But what if ETR-A becomes isolated from the end-user network? The end-user network might configure (or ask its ISPs to configure) the other two - ETR-B and ETR-C - with some different mapping information, such as new RLOCs, deleted RLOCs or rearranged RLOCs. But ETR-A will not have this new configuration and so will be causing different mapping and/or different locator reachability bits to be sent out via the ALT network or to ITRs. Versioning may be more secure than the ETR sending locator reachability bits, and it may involve the ETR in less complexity. However, I think the whole business of involving ETRs in matters concerning reachability and mapping is a problem for LISP. During times of disruption, when they most need to communicate, ETRs will often be unable to communicate reliably. In Ivip, ETRs do two things: 1 - For encapsulation: Decapsulate packets Modified header forwarding: Restore original IP headers Then the ETR forwards the packets to the destination network by some locally configured means. 2 - For encapsulation only, the ETR engages in a protocol by which the ITR can reliably and rapidly determine the Path MTU to that ETR: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ ETRs might be involved in probing of reachability, by whatever external system the end-user network hires (or deploys themselves). Ivip has no reachability testing or ETR decision making functions at all. It is up to the end-user network to do this, however they choose, and to use that information to change the mapping of each of their micronets (EID prefix, but with arbitrary start point and length) to a single ETR address, in real-time. The reachability probing system would be multiple servers in the DFZ, operating as a coordinated system. The end-user network may well give the operators of this system the authority to make decisions about which ETR(s) traffic should flow to, so the reachability probing network would actually control the mapping of their micronets in real time. This reachability probing network could also coordinate with a router in the destination network, or be under manual control, to spread traffic over multiple ETRs to achieve incoming TE. This would be by splitting the servers which receive the incoming packets over multiple IP addresses so they could be in separate micronets, each separately mappable to a different ETR. While the reachability probing system might specifically probe ETRs, a more likely scenario doesn't directly involve the ETR at all. Probe Servers ISP1 Destination end-user network PS1 ----------- ETR1-----\ / \ / CER1--- PS2 ----------- ETR2-----/ \ ISP2 Two probe servers in the DFZ can send packets to either ETR. They can probe the full status of the ETR without probing it directly. To do this, they act like an ITR, by encapsulating a probe packet addressed to the CER1 end-user router, or to some other router or host within the end-user network. They can encapsulate it with the address of either ETR1 or ETR2. Each probe carries a nonce and there needs to be a response returned from the target device - which could be as simple as a ping response with enough of the original packet to include the nonce. This way, each individual probe server can probe full reachability of the end-user network via either ETR. The ETR would have no special functionality to support this, and does not need to be configured in any way regarding the probe network. The same system would apply for modified header forwarding - instead of encapsulation. The probe servers would create the modified headers so the probe packet would be forwarded via one ETR or the other. The probe servers would communicate their results to some central server system in the probe network, which would make decisions about changing mapping in real time whenever it appeared that one or the other ETRs was unable to get packets to the destination network. All core-edge separation schemes need ITRs and ETRs. However, with a real-time mapping distribution architecture such as used with Ivip, the ITR does not make any decisions about which ETR to send packets through, because the Ivip architecture externalises the probing and decision-making system from the core-edge separation scheme itself, and require end-user networks to do it themselves. This reduces the probe traffic, compared to every ITR doing its own probing, and enables an endless choice of probe techniques and decision making logic to be employed. It also means the ETRs can be very simple indeed. For modified header forwarding, there is no PMTUD stuff to do, and the ETR simply restores the format of the packet to a normal IP format. It then forwards the packet to the correct destination network by some means. That's it. The ETR only needs to be configured to recognise that certain address ranges in the restored packet's destination address correspond to destination networks which it can forward the packet to. As long as LISP and APT or any other core edge separation scheme rely on a slow mapping distribution system, there are going to be complex tasks for the ITRs in determining which of the multiple ETRs' RLOC addresses to use. For LISP (including OpenLISP, which is independent of the main LISP-ALT project), the attempts to handle this real-time problem include locator reachability bits and versioning. Both of these involve ETRs being highly complex and also working in a coordinated manner with the ETRs of other ISPs. Ivip requires none of this because the real-time mapping system tells all the ITRs exactly what to do for each micronet (EID prefix): tunnel the packet to just one ETR address. Consequently the Ivip ITRs and ETRs are much simpler than would be possible in a fully developed LISP or APT system (APT's ITR functions are split between the ITR and the Default Mapper). - Robin From dino@cisco.com Thu Mar 5 21:46:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0393A69AF for ; Thu, 5 Mar 2009 21:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.444 X-Spam-Level: X-Spam-Status: No, score=-5.444 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aamf8ayQyUQ2 for ; Thu, 5 Mar 2009 21:46:09 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D7C5A3A6A46 for ; Thu, 5 Mar 2009 21:46:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,312,1233532800"; d="scan'208";a="151732206" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 06 Mar 2009 05:45:37 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n265jbpt031817; Thu, 5 Mar 2009 21:45:37 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n265jb5l008763; Fri, 6 Mar 2009 05:45:37 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Mar 2009 21:45:37 -0800 Received: from [192.168.1.5] ([10.21.79.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Mar 2009 21:45:36 -0800 Message-Id: <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> From: Dino Farinacci To: Robin Whittle In-Reply-To: <49AEBC00.9070306@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Mar 2009 21:39:44 -0800 References: <49AEBC00.9070306@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Mar 2009 05:45:36.0635 (UTC) FILETIME=[C616A4B0:01C99E1E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=21879; t=1236318337; x=1237182337; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20LISP=20Map=20Server=20I-D=20&= 20updated=20draft-farinacci-lisp=20-=202=20stages=20of=20cac hing=20mapping |Sender:=20; bh=OQOd8JGcOoo8LG4LgXitYTSPzoKIoaJ/T/fyPzVENIc=; b=GrUsOUPE6nADKww/07pm8HvYVJoNUWaHXvJln5eSp+2UfaDu3K89L2fnbZ fPWq0NxQuc2rUNbK4R0roypPNbcDZK3MEGQKx54HrXHrgvKSYngFxgdnKbKB uYBh7IwmLy; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: RRG , lisp@ietf.org Subject: Re: [lisp] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 05:46:09 -0000 > Short version: The Devil is in the detail, but the I-Ds don't yet > have all the details. Multiple levels of caching > is good in some ways and troublesome in others. Thanks for your comments Robin. The main point of draft-fuller-lisp-ms-00.txt is to create a API of sorts for LISP sites. So they can use a set of primitives regardless of the mapping database system deployed. By doing this, the cost of managing an xTR goes way down. No GRE tunnels, no BGP. Simply Map-Request, Map-Reply, and Map-Register primitives. > LISP Map Server draft-fuller-lisp-ms-00 > Abstract > > This draft describes the LISP Map-Server (LISP-MS), a computing > system which provides a simple 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 simplify the implementation > and operation 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. > > My understanding of and comments on this are: > > Instead of ITRs and ETRs needing to act as routers in the ALT > network, they communicate via the ordinary Internet with Map Servers, > which are routers on the ALT network. This will greatly reduce the > complexity and configuration difficulties of ITR and ETRs. Yes, that is right. ITRs send encapsulated Map-Requests to Map- Resolvers via the Map-Resolver's RLOC address. ETRs get encapsulated Map-Requests from Map-Servers via the ETR's RLOC address only after the ETR Map-Registers to the Map-Server. > These Map Server devices are implicitly local to the ITRs and ETRs in > a given network and are intended to be used only by those ITRs and > ETRs. They are always on RLOC (stable, globally reachable, non > LISP-mapped) addresses. Don't know what you mean by local. But if you meant the Map-Server is colocated with ITRs, that is not true. The Map-Server would typically not be at the site but in the Internet infrastructure somewhere. Most likely in an service provider, an interconnect provider, a RIR, or a third-party. > There are two functions which may be combined in the one device: > > Map Resolver (MR) > > Accepts a mapping query from an ITR and (usually) sends the > ITR a mapping reply. (The exception is if the MR doesn't > have the information and sends the query verbatim to some > other device, which will answer the query directly to the > ITR.) Right, we want to experiment with Map-Resolver caching but want to do that as a second phase in the implementation. So the Map-Resolver gets the Map-Request from the ITR which now puts it on the LISP-ALT network. If there is another mapping database service, it could be used. This way we can make the mapping database service modular and don't need the sites to participate in it directly. > MRs can be caching or non-caching. More on that below. > > ITRs are intended to be configured with a single address for > their local MR. This would raise questions of robustness if > not for the next item: > > Multiple MRs in a local network (such as an ISP network or > I guess any end-user network which has ITRs) can be configured > on the one anycast address. This way, the ITR's request will > be forwarded to the nearest currently active MR. All > communication is via single packets, not via TCP. Presumably > the MRs will also have their own unique addresses so they can > be managed via TCP. Right. > I think the MR is an important improvement to LISP-ALT, since It's not an improvement to the LISP-ALT mapping database, but a Map- Resolver can be a LISP-ALT router/system, a NERD system, or a CONS/DHT system. > it enables an ITR to be a much more casual and unstable concept > than was the case when all ITRs needed to participate in the > ALT network as routers (AFAIK). This means that ITRs can be > added easily, without having to configure anything. True. > It also means (though this is my suggestion, not from the LISP > team) that an ITR function could easily be implemented in a > sending host, assuming it was not behind NAT. I guess the > sending host would need to be on an RLOC address - which rules > out this idea for sending hosts in end-user networks. Ivip's > ITR in sending host function (ITFH) requires the host to be > on a non-NAT address which can be and ordinary or a Scalable PI > address - RLOC or EID in LISP parlance. True, however, it would increase the number of locators for a site. That is the EID to RLOC ratio would be 1-to-1. And the mapping database would be orders of magnitude larger! > Map Server (MS) > > Is a router on the ALT network and accepts secure messages from > one or more ETRs. (Secret key pairs to secure these.) ETRs > are (typically, or always?) the authoritative source of mapping > information in LISP. Right. The ETRs are registering their EID-prefixes more so than the mapping. Just an FYI, if that wasn't clear. Map-Servers don't answer Map-Requests because they wouldn't be authoritative. > ETRs can be on any RLOC address and use ordinary packets to > communicate with the MS. Yes, they send Map-Register messages from one of their local RLOCs. > My understanding is that the MS announces the appropriate > prefixes on the ALT network - one for every EID the ETR > tells it. Right, but if the Map-Server is at an aggregation boundary, the specific EID-prefix won't be announced but the configured aggregate in the Map-Server would. > Ignoring MSes for a moment, I have never understood how this > would work with two ETRs in two separate ISPs handling the same Multiple ETRs reside at the same site not in the SP network. > EID. Both ETRs would be routers on the ALT network and would > announce the same prefix. So where do packets go to? I guess Within their aggregation level, there are two paths for Map-Requests to travel to the site. It's the upstream BGP routers that decide which path to take. They would take shortest path based on AS-path hop- count. Recall that each LISP-ALT router is doing "eBGP". > to either. But then the ETRs somehow need to coordinate > themselves, or be coordinated by something else, so they act > in a unified manner. Then, as long as both were reachable and > working properly, it wouldn't matter which ETR got the query. Right, but they don't need to coordinate. All they need is to be consistently configured to Map-Register the same EID-prefix. > The same problem seems to apply with MSes. There would be two > ETRs in two separate ISPs and each would presumably (for > robustness in a multihoming situation and probably for security > reasons) have its own MS in its own ISP network. No, not true. > So now we have two ETRs and two MSes which need to be > coordinated. The two MSes both announce the one EID prefix > on the ALT network. Yet they are supposed to still be > coordinated during outages. The 2 Map-Servers will converge into a topology that will aggregate the site's Registered EID-prefix so we can have a smaller ALT core. Smaller meaning, a small number of EID-prefixes needing to be stored in the core of the ALT network. > However this is resolved, I think it is a big improvement for > LISP to have MSes, since it reduces the cost, complexity, > management effort etc. for ETRs similarly to how MRs do the > same for ITRs. > > Both these functions can presumably be performed quite adequately by > software devices, such as a COTS server with suitable software. > There doesn't have to be any hardware router FIB etc. AFAIK. Yep, that is true. > This would enable hardware routers to assume ITR and ETR > responsibilities without them also needing all the software and > configuration, stable address etc. to be an ALT router. Also, by > decreasing the total number of ALT routers, this simplifies the ALT > network. Yes, we thought so too. > I gather from this new I-D, and from what I read in: > > http://www.lisp4.net/docs/lisp-ausnog02.ppt > > that the current test network and the intention for the future is not > to send traffic packets on the ALT network. This approach was > initially an option, with the intention that the ALT network would > forward the initial packet(s) to the correct ETR, which would then > forward it to the destination network, while also recognising it as a > map request and so would send a map reply message to the ITR. Right that is correct. The implementation support both sending Map- Requests and Data-Probes on the ALT network, but we default to Map- Requests and might possibly deprecate Data-Probes. > I recall from somewhere that the ITR typically sends out a few > mapping requests, just in case one of them is dropped. When the ITR Well no, we rate-limit Map-Requests but they are triggered when a source at the site sends data. However, we can play with this to see what works well. > connects directly to the ALT network, these packets presumably > usually traverse the entire global ALT network until they are > delivered to one or more (probably just all to one) ETR which > responds. I guess the ETR sends multiple replies, but maybe not. > The reply goes to the ITR via the ordinary Internet. Map-Replies are rate-limited as well. > Removing these potentially long and voluminous traffic packets from > the ALT network seems like a good idea to me. There may well be > security benefits in doing so too. Below, I assume the ALT network > only carries mapping requests, and that the map replies go back from > whatever answers them (an ETR connected to ALT network, or more > likely a Map Server) via a direct ordinary Internet packet to the > device which made the query (perhaps a directly connected ITR or more > likely a Map Resolver). Yes, this is true. > A Caching Map Resolver? > > If the MR caches, then it has the potential to significantly reduce > the traffic on the ALT network. This is due to two or more ITRs in a > given ISP network wanting the same mapping, and the second and > subsequent ones getting it directly from the local caching MR. Yes, this was Noel's idea with CONS. It is worth experimenting. > This also has the potential to eliminate, for the second and > subsequent ITRs which need this mapping, the major problem of > "LISP-ALT's initial packet delays", so much debated on the RRG in > recent months. Well, I'm not so sure. If you point an ITR to an RLOC of a Map- Resolver, you take the shortest path to it. But if you had a GRE tunnel to the same box, the GRE tunnel destination would be the same RLOC. So the path would be the same. But you couldn't run an anycast Map-Resolver service because the eBGP connections that ran over the GRE tunnels would reset. So I guess this is an improvement. > There is nothing in draft-fuller-lisp-ms-00 to describe this caching > behavior. > > The caching time of map replies is specified in units of one minute: > > draft-farinacci-lisp-12: > > Record TTL: The time in minutes the recipient of the Map-Reply > will store the mapping. That detail will come in a later draft. > Let's say at time T = 0 minutes, ITR-A sends a map request to MR-1, > which has no mapping for the EID prefix which matches the EID address > in the request message. MR-1 sends its own map request message (with > its own nonce) onto the ALT network which forwards it to either the Well, that's not the way it works. The ITR sends an encapsulated Map- Request to the Map-Resolver. The Map-Resolver strips the outer header and then forwards the Map-Request on the ALT. The source address is the ITR RLOC address and the destination address is the EID that caused the map-cache fault on the ITR. > single Map Server which advertises the matching EID prefix on the ALT > network, or to one of the multiple such Map Serves, or perhaps to the > directly ALT-connected ETR(s) which do the same. Correct. > That device sends the mapping reply back to MR-1 directly via the > Internet. The reply is secured by returning MR-1's nonce. No, it would go to the ITR because in the Map-Request payload there is an "ITR RLOC" field. This is quite important because if that Map- Request was an IPv6 Map-Request with an IPv6 outer header, and since the LISP-ALT network we have deployed is dual-stack, the IPv6 Map- Request is forwarded on the ALT, but the ETR may not (and probably not) have a IPv6 path back to the ITR. So if the "ITR RLOC" field is encoded with an IPv4 RLOC, the ETR sends a Map-Reply back with an IPv4 header. In the entire LISP design we treat IPv4 and IPv6 equally and try to enhance IPv6 connectivity by using IPv4 outer headers or IPv4 RLOCs when encapsulating. Today, two IPv6-only sites can open an IPv6 TCP connection to each other if they run LISP and use IPv4 locators. > Let's say the mapping reply comes back with a 90 minute caching time. > > MR-1 sends to ITR-A a map reply, with ITR-A's request's nonce, with > the fresh mapping information and a caching time of 90 minutes. Now > MR-1 can encapsulate packets to its choice of ETRs, based on the > fresh mapping it has received and whatever it has determined about > reachability of those ETRs, and of the ETRs' ability to get packets > to the destination network. No, no, no. The Map-Resolver does not encapsulate any packets. Remember the ALT has no data going over it. If the Map-Resolver is caching Map-Replies and the ITR sends a Map- Request with A=0, then the Map-Resolver can respond with a Map-Reply. If the ITR sends a Map-Request with A=1, the Map-Resolver must forward the Map-Request over the ALT so an authoritative Map-Reply can be returned by the ETR. > Later, at T = 85 minutes, ITR-B sends a mapping request to MR-1 for > an address which matches this same EID prefix. MR-1 can use its > cached information and send a reply within a few milliseconds. This > means ITR-B's traffic will not be delayed by any significant amount. > > What caching time will be in that reply to ITR-B? I assume it will > be 5 minutes. If it would be 90 minutes, ITR-B could be running for > a long time to come on stale mapping information. We haven't figure that out yet. We don't want to create an impression that a cacher of a Map-Reply can use any TTL it wants. We want to make it mandatory to respect the ETR's value. > Assuming ITR-A no longer needs this EID's mapping, but ITR-B keeps > needing to tunnel packets addressed to this EID, then at T=90 > minutes, ITR-B will want mapping information again. > > Should ITR-B request the mapping again at at T = 88 minutes, in > readiness for probably needing it in 1 minute's time? It could, but the reasons to time out the map-cache entry is to keep the cache small and to be resilient, to some extent for locator-set changes at the ETR site. > This would seem like a generally reasonable approach if it prompted > MR-1 to get fresh mapping information, but why should MR-1 do this? > Would MR-1 need to look at the original caching time and how much > has expired to decide whether it should, by some algorithm, request > fresh mapping? But what if the mapping hadn't changed in the distant > Map Server, but the ETR was going to change it two minutes later? One of the problems I see with caching in the Map-Resolver is if the map-cache entry does have a locator-set change and the ETR asks all cachers to send Map-Requests (it does this by setting the SMR-bit for active flows), the Map-Resolvers cannot get updated because they are not seeing data. However, I have a solution for this because, it will be the ITR that sends A=1 Map-Requests with an SMR-bit set. That can tell the Map- Resolver to ask for the Map-Reply back to update it cache. I know there are security issues with this but it's one way of doing it. There are also details how a Map-Resolver asks to get the Map-Reply back. We want to do this in a stateless manner in the Map-Resolver. So we might have to preserve the ITR RLOC's address in the Map-Request but instruct the ETR where to send the Map-Reply. We have some ideas and what to think about it before changing packet formats. > If ITR-B waited until T = 90 or a little later before requesting > fresh mapping, then unless MR-1 had already got fresh mapping in the > last minute or two, then there would presumably be a delay in the ITR > being able to handle traffic for this EID, since it would take some > time for MR-1's second mapping request to traverse the ALT network > and generate a reply to MR-1. > > There are various scenarios, but I think there are potential > difficulties with caching times running out in three locations now > rather than one. Yeah, we can't get too tricky about manipulating TTLs. DNS has bee fraught with problems due to TTL issues. If anyone has advice about this, it would be nice to hear about it. > Previously, it was simple (despite the scaling problems of lots of > ITRs peppering an ETR for mapping, not to mention them all trying to > decide reachability for this and other ETRs): > > ITR query -----------> ETR > <----------- reply > cache > > > Now we have: > > ITR query -----> Map query -----> Map > <----- reply Resolver <----- reply Server <--Register- ETR > > Cache Cache Cached, in a sense, > controlled by messages > from the ETR(s) whenever > they can reach the > > Map Server and decide > to send a Map Register > message. Right, but what if we used for first case and have the ETR schedule an update to the Map-Resolver? Or what if the ITR updated the Map- Resolver? Not sure yet. And not even sure how much RTT will buy us with Map-Resolver caching. > I think this raises more complex problems with: > > 1 - How to avoid cache times running out at ITRs > which are going to be tunneling packets addressed > to this EID after the cache time expires. > > Such a situation will cause a traffic delay unless > the local Map Resolver has recently got fresh mapping. But I think this is issue has continually been exaggerated. The Map- Request delay is not for a lot of packets and will be relatively rare I imagine. > 2 - How to minimise unnecessary map requests by Map > Resolvers trying to anticipate ITRs making such > requests, but actually requesting fresh mapping from > the distant Map Server when the ITR doesn't need it. Right, Map-Resolver caching could be more trouble than it is worth. > Without further complications, the Map Resolver can't know whether > the one or more ITRs which requested the mapping for an EID are still > handling traffic for that EID. So it can't very well request fresh > mapping towards the end of its expiry, just in case an ITR wants it. > To do so would approximately double the volume of map requests > traversing the ALT network, since it is reasonable to assume, with > longish caching times, that the original caching time will generally > suffice for the needs of the one or more ITRs served by the Map > Resolver. (This would not be true with a busy Map Resolver and > popular EIDs many ITRs are sending packets to.) > > Without some elaboration of the request protocol, ITR-B at T = 85 > minutes can't ask the Map Resolver to get fresh mapping and send it a > new reply - unless there is some algorithm in the Map Resolver such > as: "If the cached mapping is 90% of the way to its expiry time, do > not answer the new request from the cache, but send a fresh map > request and then answer the query if and when the new reply arrives." > > To do so would effectively shorten all the caching times. Well, it the mappings don't change, longer TTLs will help the Map- Request load on the ALT. If there are frequent changes and you want fast convergence to them, then you use more resources. That is the tradeoff. > At present, there is only one kind of map request message from an ITR > to a Map Server - implicitly an urgent request. > > If there was a second kind: > > "This ITR has mapping for this EID which will expire in some > time period (specified) soon, and requests the Map Resolver > to get fresh mapping from the Map Server now, and to send > a reply once this arrives." There is no reason why the ITR cannot send a Map-Request directly to the RLOC of the ETR. It does have a set of them he can try. And the nonce will protect against ETR spoof attacks. > then I think these problems would be resolvable with less trouble and > less need for choices based on limited information. > > - Robin Thanks again for your comments Robin, Dino From rw@firstpr.com.au Fri Mar 6 01:17:17 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E365A28C111 for ; Fri, 6 Mar 2009 01:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgXR4lPvCVy1 for ; Fri, 6 Mar 2009 01:17:17 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 1BACF28C0FB for ; Fri, 6 Mar 2009 01:17:17 -0800 (PST) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id EC858175A6C; Fri, 6 Mar 2009 19:50:36 +1100 (EST) Message-ID: <49B0E3E0.3010407@firstpr.com.au> Date: Fri, 06 Mar 2009 19:50:40 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: rrg@irtf.org References: <49B0B0E3.5050801@firstpr.com.au> In-Reply-To: <49B0B0E3.5050801@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] [rrg] Concerns about LISP Reachability Bits - oops X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 09:17:18 -0000 I have been told offlist that with LISP, the ETRs are at the site of the end-user network. I will confirm this and write something separate about it. Assuming LISP ETRs are always located at, and run by, the end-user network, the critique I wrote in my previous message about difficulties coordinating ETRs does not apply. I will respond to Dino's reply to my "LISP Map Server I-D ..." message once I am clear about where LISP ETRs are located. - Robin From pfrejborg@gmail.com Fri Mar 6 02:06:44 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD1E3A6C22 for ; Fri, 6 Mar 2009 02:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXQLcFrNnGql for ; Fri, 6 Mar 2009 02:06:43 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by core3.amsl.com (Postfix) with ESMTP id 25C713A6B12 for ; Fri, 6 Mar 2009 02:06:42 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so132231fkf.5 for ; Fri, 06 Mar 2009 02:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6tI0VJSG+JljAA/zvQTpmJggMxP/jCO5OOcG1nWQj5Y=; b=Dvhn4v875cb6SblHxx1ulacgEA3sXamP9lY2hk9160ykiiosayWm0FBLvVZeYQlVzx 64I+ZIAImGqsdG7zEFcNWWQ63GMt+GwSO2CD35QREKahgwWG7c/gY2Y69smLD0yNUYAN djVdAbz65AnMD6oBYrxtXMr+Yq1HKikZd1sIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qMTxshr5SZpj2XnA3Xb44efasAy6MfpUXDZWcMvXh7HFDGqRnb+2KvhvmhjU2qcpt8 3XyXj7YrkaYnvbf6VJP/BjossU5GGfhz2xHz2+P8yoQbkgTvLP3Z+w32Vyp7g6vI2U96 FMUQzIaY16vOM+03UcfvmTx1crQARc21GeHC0= MIME-Version: 1.0 Received: by 10.180.208.2 with SMTP id f2mr737610bkg.83.1236334032866; Fri, 06 Mar 2009 02:07:12 -0800 (PST) In-Reply-To: <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> Date: Fri, 6 Mar 2009 12:07:12 +0200 Message-ID: <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> From: Patrick Frejborg To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 06 Mar 2009 08:08:28 -0800 Cc: RRG , lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 10:06:44 -0000 On Fri, Mar 6, 2009 at 7:39 AM, Dino Farinacci wrote: > >> =A0 =A0 So now we have two ETRs and two MSes which need to be >> =A0 =A0 coordinated. =A0The two MSes both announce the one EID prefix >> =A0 =A0 on the ALT network. =A0Yet they are supposed to still be >> =A0 =A0 coordinated during outages. > > The 2 Map-Servers will converge into a topology that will aggregate the > site's Registered EID-prefix so we can have a smaller ALT core. Smaller > meaning, a small number of EID-prefixes needing to be stored in the core = of > the ALT network. > Dino, I think the Map-Server proposal is great and I can see synergies with my hIPv4 framework proposal. Because the Map-Server is not put in the forwarding path, it is similar to a DNS solution, why can not the Map-Server contain all prefixes and their RLOC identifiers, i.e. the Map-Server would become the new DFZ and Map-Severs (MS) are tied together with BGP? The MS is decoupled from the forwarding fabric, it is more or less a database and "signaling" instance, right? A powerful server with a lot of memory should be able to deal with the RIB churn. I have also a feeling that every service provider would prefer to have their own MS and therefore the ITR/ETR of that service provider are adjacent with the MS of the ISP. The ISP would still have in their RIB all prefixes attached to the SP's network and the RIB also need to carry all global RLOC identifiers. But overall the growth of the entries in the routers' RIB and FIB would be reduced for each AS. When a client resolves a destination and found out the destination IP address it is forwarded to the network, if the destination is not found in the RIB/FIB it is forwarded to the closest ITR upon the default route. The ITR make a lookup from the MS and once the RLOC is found the packets are encapsulated and forwarded to the ETR. The ETR updates its cache on the information in the packet. Most likely the ETR has to inform the adjacent MS that it is dealing with this new EID entry. When a EID changes location the ETR is updating the MS and BGP is announcing to all MS the change. The MS should then flush the adjacent ITR/ETRs, if they have "subscribed" for that specific EID during the last , e.g. 24 hours. The update churn is not "flat" anymore, all MS will be influenced but not all ITR/ETR, except if they have been using the affected EID. Or have I misunderstood something? Then we have the exhaustion of the IPv4 address space, when that occurs we have to upgrade the hosts anyway and my draft is trying to address that issue. I'm little bit early with my proposal but now I can see both fitting together on a high level. Then a commercial: draft 01 is on its way through the process - the LSR can be removed in the future and also "session based" multihoming can be achieved without the need to implement AS border routing. -- patte From dmm@1-4-5.net Fri Mar 6 08:24:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFEF83A6784; Fri, 6 Mar 2009 08:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCVEss9zkg3j; Fri, 6 Mar 2009 08:24:14 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id C1DE93A680A; Fri, 6 Mar 2009 08:24:14 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n26GOfY3025994; Fri, 6 Mar 2009 08:24:41 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n26GOfaU025993; Fri, 6 Mar 2009 08:24:41 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 6 Mar 2009 08:24:41 -0800 From: David Meyer To: Patrick Frejborg Message-ID: <20090306162441.GA25825@1-4-5.net> References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: RRG , lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 16:24:15 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Patrick, > Because the Map-Server is not put in the forwarding path, it is > similar to a DNS solution, why can not the Map-Server contain all > prefixes and their RLOC identifiers, i.e. the Map-Server would become > the new DFZ and Map-Severs (MS) are tied together with BGP? I'll just point out here that there is no requirement that the networking elments implementing the ALT need to be in the data path either. =20 > The MS is decoupled from the forwarding fabric, it is more or less a > database and "signaling" instance, right? A powerful server with a lot > of memory should be able to deal with the RIB churn. Yes, but we don't expect much churn on the ALT in any event (at least not the churn we find from edges going up and down; ALT nodes are connnected by GRE tunnels and there are diverse underlying paths between ALT nodes). > I have also a feeling that every service provider would prefer to have > their own MS and therefore the ITR/ETR of that service provider are > adjacent with the MS of the ISP.=20 Sure, that would be a legit deployment scenario. > The ISP would still have in their RIB > all prefixes attached to the SP's network and the RIB also need to > carry all global RLOC identifiers. But overall the growth of the > entries in the routers' RIB and FIB would be reduced for each AS. > When a client resolves a destination and found out the destination IP > address it is forwarded to the network, if the destination is not > found in the RIB/FIB it is forwarded to the closest ITR upon the > default route. The ITR make a lookup from the MS and once the RLOC is > found the packets are encapsulated and forwarded to the ETR. The ETR > updates its cache on the information in the packet. Most likely the > ETR has to inform the adjacent MS that it is dealing with this new EID > entry. I'm not sure I understand. The map-server connects to the ALT, which of course has a RIB, but it seems you're talking about the DFZ RIB (RLOCs and all). Which one are you talking about? > When a EID changes location the ETR is updating the MS and BGP is > announcing to all MS the change.=20 What you want to happen is for the ETR to register to a map-server that can aggregate its EID prefix. If that happens, there's zero update activity since the map-server will already be advertising a covering prefix. > The MS should then flush the adjacent > ITR/ETRs, if they have "subscribed" for that specific EID during the > last , e.g. 24 hours. The update churn is not "flat" anymore, all MS > will be influenced but not all ITR/ETR, except if they have been using > the affected EID. > Or have I misunderstood something? The only thing I see is that the toplogy is virutal, so one in theory can prevent any "churn" in the register/deregister process if the map-server is already announcing a covering prefix. Remember, the map-server sends the map-request LISP-encapsulated to the ETR on the underlying infrastructure, so can be anywhere (of course, the "wheres" may have different attributes, e.g., latency, packet loss, all of that). > Then we have the exhaustion of the IPv4 address space, when that > occurs we have to upgrade the hosts anyway and my draft is trying to > address that issue. I'm little bit early with my proposal but now I > can see both fitting together on a high level. Then a commercial: > draft 01 is on its way through the process - the LSR can be removed in > the future and also "session based" multihoming can be achieved > without the need to implement AS border routing. s/Then we have/If we have/ Dave --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmxTkkACgkQORgD1qCZ2KeCJgCePfeyCkRXfLDkHa2Ahvyj3dG6 T/IAnRfmLOQGR4Zm1i0vhIYeo1LHZfL5 =Di+U -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From pfrejborg@gmail.com Fri Mar 6 11:59:23 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2951128C2D6 for ; Fri, 6 Mar 2009 11:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQaZRKQ3m7FC for ; Fri, 6 Mar 2009 11:59:21 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 6838F3A68CB for ; Fri, 6 Mar 2009 11:59:21 -0800 (PST) Received: by fxm24 with SMTP id 24so529482fxm.37 for ; Fri, 06 Mar 2009 11:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Sov7XnTKMWW4ggzQXfXlUKBqJHuIKlSHIDPKtX1CfGw=; b=W+3vuBQJDMHGzE22g9ib1peA0nPZhgIbycPudWtNdajdrovQ/87TyTuwP/uByPrdEx oIraRZj2/5pHya6cNyBKSa0sM7Goc9JAADg62Jf0f0xjFAgvzvKHCF1mdabGCmOG0YqQ Oe9qdNGaCvn2a0N3Ss6UgjHYEKdEa+Nlxx0DU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ibhjdGG8aGrJJCWxEmzk6p9w2njPprUMcp9l7ow7zbuNP2qmhDZ5Sww94OBraCrLg7 Vishhos4BLqZtkpS/CKb/Viud9T5aA1dVW/kDLNiot5JA7RIGBoDvlvUA11XwoTdQZha 61KRiq/WaGXXPq2qFmr9M15TAahKsPyVCq6JE= MIME-Version: 1.0 Received: by 10.181.31.16 with SMTP id i16mr904208bkj.129.1236369591484; Fri, 06 Mar 2009 11:59:51 -0800 (PST) In-Reply-To: <20090306162441.GA25825@1-4-5.net> References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> <20090306162441.GA25825@1-4-5.net> Date: Fri, 6 Mar 2009 21:59:51 +0200 Message-ID: <5bc37fd40903061159q62464ca2y478f212a5342fa8b@mail.gmail.com> From: Patrick Frejborg To: David Meyer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: RRG , lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 19:59:23 -0000 Hi Dave On Fri, Mar 6, 2009 at 6:24 PM, David Meyer wrote: >> The ISP would still have in their RIB >> all prefixes attached to the SP's network and the RIB also need to >> carry all global RLOC identifiers. But overall the growth of the >> entries in the routers' RIB and FIB would be reduced for each AS. >> When a client resolves a destination and found out the destination IP >> address it is forwarded to the network, if the destination is not >> found in the RIB/FIB it is forwarded to the closest ITR upon the >> default route. The ITR make a lookup from the MS and once the RLOC is >> found the packets are encapsulated and forwarded to the ETR. The ETR >> updates its cache on the information in the packet. Most likely the >> ETR has to inform the adjacent MS that it is dealing with this new EID >> entry. > > =A0 =A0 =A0 =A0I'm not sure I understand. The map-server connects to the > =A0 =A0 =A0 =A0ALT, which of course has a RIB, but it seems you're > =A0 =A0 =A0 =A0talking about the DFZ RIB (RLOCs and all). Which one are > =A0 =A0 =A0 =A0you talking about? I got a little bit carried away here... I had my first architecture (that haven't been published) in mind which is close with the MS -except that instead of a MS I had a DNS server. It got complicated and after some discussions I decided to go after the host stack instead. So I'll try to explain what I have in mind. If you have a B-RAS with a very good IP-subnetting plan in place you will have only one IP subnet on the B-RAS. So applying ITR/ETR on that B-RAS will not reduce the size of the DFZ - we are mapping a subnet/RLOC 1-to-1. Also if you have very good aggregation in place LISP will not help that much. So I thought that the RLOC should be connected to the AS (or actually an area) somehow, let say you assign a block /23 to an AS (or geographical area) and the ISP are taking its RLOC identifiers from that block for its ITR/ETR. The ITR/ETR are located in the ISP network but not necessary at the edge routers - if you have ITR/ETR on the edge routers you need a lot of IP addresses and you need to replace a lot of hardware (costs have to be covered somehow). Instead you place them on strategic places in the network so you can have several edge routers behind one ITR/ETR. And to the ALT network you just advertise on prefix, the /23 and not the individual RLOC host prefixes. This becomes a sort of super aggregate, the AS or an area is shown behind one /23 RLOC prefix. Once everything is in place you could remove the current granular distribution of prefixes, only the /23 RLOC prefixes would be exchanged between the service providers. When this is finally in place I have in my own AS only the prefixes that are connected to my network and the /23 RLOC prefixes of other service providers. When a customer makes a connection outside my AS it will not be found in the RIB of my AS, the SYN will end up in the closest ITR. If the ITR doesn't have that entry in its cache, it need to lookup it from the MS. The MS returns the RLOC identifier for that prefix to the ITR and then the ITR can add the RLOC identifier to the packet, now it can be routed to the destination. So my routers have only - lets change to PSTN lingo - the domestic numbers and the country codes to make international calls. This way the RIB and the FIB can be heavily suppressed, every AS expand on their own and will not influence on the RIB/FIB of other AS. Don't know if this matches yours design, I perhaps assumed too much here. LISP-ALT will be the global directory, which IP prefix is connected to which RLOC identifier for time being and this directory will grow but it is disconnected from the forwarding plane so the FIB doesn't need to be upgraded - only in the AS that grows too big. But that is then up to the service provider, split the AS to two AS or buy new hardware - the ISP have a choice. But this can be achieved when every ISP have moved to LISP, will it happen? > >> Then we have the exhaustion of the IPv4 address space, when that >> occurs we have to upgrade the hosts anyway and my draft is trying to >> address that issue. I'm little bit early with my proposal but now I >> can see both fitting together on a high level. Then a commercial: >> draft 01 is on its way through the process - the LSR can be removed in >> the future and also "session based" multihoming can be achieved >> without the need to implement =A0AS border routing. > > =A0 =A0 =A0 =A0s/Then we have/If we have/ > We can agree that we disagree on this topic :-) One question for you, how are you going to deal with portsweep on the ITR? I have seen ISP using NAT on the B-RAS (along time ago), an end user could easily saturate the NAT table so that all customer behind that B-RAS lost connectivity. I think we should design LISP and LISP-ALT so that later on the functionality can be taken to the hosts, both options are needed so that the enterprise and service providers do have a choice. If the ISP charges too much the enterprise can upgrade its host or if the LISP service is cheap enough the enterprise doesn't need to upgrade the hosts Also much can be improved by going after the hosts, e.g. mobility and UDT features can be interesting for the enterprises and a good reason to upgrade. And finally I have to borrow something from a paper RJ Atkinson brought to the rrg list, IMHO, wise words -- patte http://www.ee.ucl.ac.uk/lcs/papers2002/LCS072.pdf Regrettably, most current applications have been built around the assumption that IP addresses and ports do not change during a session =96 an assumption that was reasonable in the era of the static Internet. However, we believe that the end-to-end principle, which implicitly requires changes to be made at the end hosts, has repeatedly proven itself as the guardian of evolvability through openness [13]. The reliance on an overlay network is a logical step in facilitating the development of new technology but is an indication of the immaturity of that technology. As the technology matures and becomes more widely used, we believe that its natural home lies in the endpoints in common with similar technologies From damian.lezama@hotmail.com Sun Mar 8 00:56:47 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7716828C0F9 for ; Sun, 8 Mar 2009 00:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgtzTwBFO6dk for ; Sun, 8 Mar 2009 00:56:46 -0800 (PST) Received: from col0-omc4-s5.col0.hotmail.com (col0-omc4-s5.col0.hotmail.com [65.55.34.207]) by core3.amsl.com (Postfix) with ESMTP id D514C28C0DB for ; Sun, 8 Mar 2009 00:56:46 -0800 (PST) Received: from COL110-DS2 ([65.55.34.201]) by col0-omc4-s5.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Mar 2009 00:57:19 -0800 X-Originating-IP: [24.87.8.194] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> <20090306162441.GA25825@1-4-5.net> <5bc37fd40903061159q62464ca2y478f212a5342fa8b@mail.gmail.com> In-Reply-To: <5bc37fd40903061159q62464ca2y478f212a5342fa8b@mail.gmail.com> Date: Sun, 8 Mar 2009 00:56:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmeliDWzWnwC7chRVGf64aJ2QAnoQBNQlxw Content-Language: en-us X-OriginalArrivalTime: 08 Mar 2009 08:57:19.0203 (UTC) FILETIME=[E2FABB30:01C99FCB] Subject: [lisp] Map Register AH ICV is 16 bits? (LISP Draft 12) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 08:56:47 -0000 Hi, I have a question. >From the draft: "The Authentication Data is 16 bytes and holds a MD5 HMAC." Isn't it 12 bits? Is it RFC2403 HMAC-MD5-96? Regards, Damian From damian.lezama@hotmail.com Sun Mar 8 00:58:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17EEA28C0E7 for ; Sun, 8 Mar 2009 00:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JxYZOa5tTA0 for ; Sun, 8 Mar 2009 00:58:44 -0800 (PST) Received: from col0-omc4-s1.col0.hotmail.com (col0-omc4-s1.col0.hotmail.com [65.55.34.203]) by core3.amsl.com (Postfix) with ESMTP id 56D8C3A68E5 for ; Sun, 8 Mar 2009 00:58:44 -0800 (PST) Received: from COL110-DS1 ([65.55.34.200]) by col0-omc4-s1.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Mar 2009 00:59:17 -0800 X-Originating-IP: [24.87.8.194] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> <20090306162441.GA25825@1-4-5.net> <5bc37fd40903061159q62464ca2y478f212a5342fa8b@mail.gmail.com> In-Reply-To: Date: Sun, 8 Mar 2009 00:58:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmeliDWzWnwC7chRVGf64aJ2QAnoQBNQlxwAAAvXAA= Content-Language: en-us X-OriginalArrivalTime: 08 Mar 2009 08:59:17.0394 (UTC) FILETIME=[296D3F20:01C99FCC] Subject: Re: [lisp] Map Register AH ICV is 16 BYTES? (LISP Draft 12) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 08:58:45 -0000 Sorry for the typo, I mean bytes! > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of > Damian Lezama > Sent: Sunday, March 08, 2009 12:57 AM > To: lisp@ietf.org > Subject: [lisp] Map Register AH ICV is 16 bits? (LISP Draft 12) > > Hi, I have a question. > > From the draft: > > "The Authentication Data is 16 bytes and holds a MD5 HMAC." > > Isn't it 12 BYTES? Is it RFC2403 HMAC-MD5-96? > > Regards, > Damian > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damian.lezama@hotmail.com Sun Mar 8 09:36:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4406D28C11E for ; Sun, 8 Mar 2009 09:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.082 X-Spam-Level: X-Spam-Status: No, score=-1.082 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otK-pVZW6c1N for ; Sun, 8 Mar 2009 09:36:42 -0700 (PDT) Received: from col0-omc4-s7.col0.hotmail.com (col0-omc4-s7.col0.hotmail.com [65.55.34.209]) by core3.amsl.com (Postfix) with ESMTP id 9908C3A68F2 for ; Sun, 8 Mar 2009 09:36:42 -0700 (PDT) Received: from COL110-DS16 ([65.55.34.199]) by col0-omc4-s7.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Mar 2009 09:37:15 -0700 X-Originating-IP: [24.87.8.194] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: Date: Sun, 8 Mar 2009 09:36:45 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C99FD1.664EEEC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmgDBHFSUsUpTTOSr2CuX5BXWrlmg== Content-Language: en-us X-OriginalArrivalTime: 08 Mar 2009 16:37:15.0908 (UTC) FILETIME=[23E5BC40:01C9A00C] Subject: [lisp] Map Register has no reply/ACK? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 16:36:43 -0000 ------=_NextPart_000_004D_01C99FD1.664EEEC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, It surprises me that an ETR Map Register UDP message to a Map Server has no reply. How can the ETR be sure that it has successfully registered the prefix? Regards, Damian ------=_NextPart_000_004D_01C99FD1.664EEEC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It surprises me that an ETR Map Register UDP = message to a Map Server has no reply. How can the ETR be sure that it has successfully registered the prefix?

 

Regards,

Damian

 

------=_NextPart_000_004D_01C99FD1.664EEEC0-- From dino@cisco.com Sun Mar 8 09:40:28 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A5C3A6899 for ; Sun, 8 Mar 2009 09:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 414gg8g+aFXP for ; Sun, 8 Mar 2009 09:40:27 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D52DE3A6809 for ; Sun, 8 Mar 2009 09:40:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,325,1233532800"; d="scan'208";a="152528435" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2009 16:41:01 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n28Gf1Wq030875; Sun, 8 Mar 2009 09:41:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n28Gf1xA027213; Sun, 8 Mar 2009 16:41:01 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 09:41:00 -0700 Received: from [192.168.1.5] ([10.21.149.247]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 09:41:00 -0700 Message-Id: From: Dino Farinacci To: "Damian Lezama" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Mar 2009 09:41:00 -0700 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Mar 2009 16:41:00.0329 (UTC) FILETIME=[A9A9A990:01C9A00C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=331; t=1236530461; x=1237394461; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Map=20Register=20has=20no=20re ply/ACK? |Sender:=20; bh=/vWkI27wmpXUlRT9hdkFx3XQJ1mNEhvNCHGl0Tb3sOk=; b=U6vUdNpiGy4b8lIRscFZZMlk/pz+53sJm2EkaDe/4quk5EloI4isVZD8uz ppvWnFuoyZTlMFPT4Azh7ZYZDolZm/Eitv9iNPDgY689F206wmwdlo6OTgje RlkBhdeP54; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Map Register has no reply/ACK? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 16:40:28 -0000 > It surprises me that an ETR Map Register UDP message to a Map Server > has no reply. How can the ETR be sure that it has successfully > registered the prefix? Periodic. Right now our implementation is sending a Map-Register every 3 minutes and the map-server will time out after 9 minutes of not hearing. Dino From jmh@joelhalpern.com Sun Mar 8 09:59:57 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4219D3A69A7 for ; Sun, 8 Mar 2009 09:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVCLRh7SCTVN for ; Sun, 8 Mar 2009 09:59:56 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 849763A697E for ; Sun, 8 Mar 2009 09:59:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BD9CE430194; Sun, 8 Mar 2009 10:00:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-50-192.clppva.btas.verizon.net [71.161.50.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 07D17430192; Sun, 8 Mar 2009 10:00:28 -0700 (PDT) Message-ID: <49B3F9A7.1000407@joelhalpern.com> Date: Sun, 08 Mar 2009 13:00:23 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dino Farinacci References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Map Register has no reply/ACK? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 16:59:57 -0000 It seems to me that this is at least overly simplified. 1) Timers need significant jitter. (Imagine a single server getting a bunch of synchronized map register messages? While this structure is not as prone to synchronization as some, I would hate to bet against it.) 2) Under congestion, 3 scattered loss events is not that unlikely. The SIP folks concluded that if they were going to use UDP then they needed UDP acknowledgments, and a lot of logic to go with it. 3) If you are willing to have messages that often, why not use TCP instead? The servers can easily handle the number of connections involved. You get reliability, congestion control, and other aspects as you need them. This is particularly useful if a single ETR is a PE serving multiple customers, and therefore needing to send multiple registers (some PEs handle a very large number of customers.) Yours, Joel Dino Farinacci wrote: >> It surprises me that an ETR Map Register UDP message to a Map Server >> has no reply. How can the ETR be sure that it has successfully >> registered the prefix? > > Periodic. Right now our implementation is sending a Map-Register every 3 > minutes and the map-server will time out after 9 minutes of not hearing. > > Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From damian.lezama@hotmail.com Sun Mar 8 10:05:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 459AF3A69F1 for ; Sun, 8 Mar 2009 10:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjOeoUnTLlGq for ; Sun, 8 Mar 2009 10:05:08 -0700 (PDT) Received: from col0-omc2-s10.col0.hotmail.com (col0-omc2-s10.col0.hotmail.com [65.55.34.84]) by core3.amsl.com (Postfix) with ESMTP id 8413D3A67CF for ; Sun, 8 Mar 2009 10:05:08 -0700 (PDT) Received: from COL110-DS10 ([65.55.34.73]) by col0-omc2-s10.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Mar 2009 10:05:41 -0700 X-Originating-IP: [24.87.8.194] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: "'Dino Farinacci'" References: In-Reply-To: Date: Sun, 8 Mar 2009 10:05:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmgDKoQe7sY0cNSQEedi+tUf1pQWwAA0bWQ Content-Language: en-us X-OriginalArrivalTime: 08 Mar 2009 17:05:42.0005 (UTC) FILETIME=[1CCF7A50:01C9A010] Cc: lisp@ietf.org Subject: Re: [lisp] Map Register has no reply/ACK? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 17:05:09 -0000 Great, thanks! Regards, Damian > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Sunday, March 08, 2009 9:41 AM > To: Damian Lezama > Cc: lisp@ietf.org > Subject: Re: [lisp] Map Register has no reply/ACK? > > > It surprises me that an ETR Map Register UDP message to a Map Server > > has no reply. How can the ETR be sure that it has successfully > > registered the prefix? > > Periodic. Right now our implementation is sending a Map-Register every > 3 minutes and the map-server will time out after 9 minutes of not > hearing. > > Dino From damian.lezama@hotmail.com Sun Mar 8 10:21:22 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800293A6C3A for ; Sun, 8 Mar 2009 10:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6zlRze0aHPg for ; Sun, 8 Mar 2009 10:21:21 -0700 (PDT) Received: from col0-omc2-s8.col0.hotmail.com (col0-omc2-s8.col0.hotmail.com [65.55.34.82]) by core3.amsl.com (Postfix) with ESMTP id B91C73A697E for ; Sun, 8 Mar 2009 10:21:21 -0700 (PDT) Received: from COL110-DS18 ([65.55.34.71]) by col0-omc2-s8.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Mar 2009 10:21:55 -0700 X-Originating-IP: [24.87.8.194] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: "'Joel M. Halpern'" , "'Dino Farinacci'" References: <49B3F9A7.1000407@joelhalpern.com> In-Reply-To: <49B3F9A7.1000407@joelhalpern.com> Date: Sun, 8 Mar 2009 10:21:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmgD2I+zK7IWmq6TBKn0UGzeQFRQgAAon+A Content-Language: en-us X-OriginalArrivalTime: 08 Mar 2009 17:21:55.0458 (UTC) FILETIME=[61089E20:01C9A012] Cc: lisp@ietf.org Subject: Re: [lisp] Map Register has no reply/ACK? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 17:21:22 -0000 Hi Joel, I think Dino is referring to a current test implementation not to a proposed standard. The draft doesn't say anything about this 3 retries or 3 min and 9 min timers. I bet the schema will be more reliable and complex once specified in the draft. Regards, Damian > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Sunday, March 08, 2009 10:00 AM > To: Dino Farinacci > Cc: Damian Lezama; lisp@ietf.org > Subject: Re: [lisp] Map Register has no reply/ACK? > > It seems to me that this is at least overly simplified. > 1) Timers need significant jitter. (Imagine a single server getting a > bunch of synchronized map register messages? While this structure is > not as prone to synchronization as some, I would hate to bet against > it.) > 2) Under congestion, 3 scattered loss events is not that unlikely. The > SIP folks concluded that if they were going to use UDP then they needed > UDP acknowledgments, and a lot of logic to go with it. > 3) If you are willing to have messages that often, why not use TCP > instead? The servers can easily handle the number of connections > involved. You get reliability, congestion control, and other aspects > as > you need them. This is particularly useful if a single ETR is a PE > serving multiple customers, and therefore needing to send multiple > registers (some PEs handle a very large number of customers.) > > Yours, > Joel > > > Dino Farinacci wrote: > >> It surprises me that an ETR Map Register UDP message to a Map Server > >> has no reply. How can the ETR be sure that it has successfully > >> registered the prefix? > > > > Periodic. Right now our implementation is sending a Map-Register > every 3 > > minutes and the map-server will time out after 9 minutes of not > hearing. > > > > Dino > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > > From grampin@fing.edu.uy Sun Mar 8 10:38:47 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52EC63A6AFE for ; Sun, 8 Mar 2009 10:38:47 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUB3cGs3N0yz for ; Sun, 8 Mar 2009 10:38:46 -0700 (PDT) Received: from davinci.fing.edu.uy (smtp.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id 07F423A6AA2 for ; Sun, 8 Mar 2009 10:38:45 -0700 (PDT) Received: from e-mac.local (r190-134-35-236.dialup.adsl.anteldata.net.uy [190.134.35.236]) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id n28Hd1kX021338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Mar 2009 14:39:02 -0300 (UYT) Message-ID: <49B40269.500@fing.edu.uy> Date: Sun, 08 Mar 2009 14:37:45 -0300 From: Eduardo Grampin User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Damian Lezama References: <49B3F9A7.1000407@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Sun, 08 Mar 2009 14:39:04 -0300 (UYT) X-Scanned-By: MIMEDefang 2.63 on 164.73.32.2 Cc: lisp@ietf.org Subject: Re: [lisp] Map Register has no reply/ACK? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 17:38:47 -0000 Hi all, If we go for TCP, we could easily adopt other existing map/reply protocols, such as PCEP, which just became RFC 5440 this week. With PCEP, tight integration between TE-servers and map-servers could be achieved, simplifying ISP management infrastructure. Moreover, PCE-like TE functionality could be coordinated with mapping. Regards, Eduardo Damian Lezama wrote: > Hi Joel, > > I think Dino is referring to a current test implementation not to a proposed > standard. The draft doesn't say anything about this 3 retries or 3 min and 9 > min timers. I bet the schema will be more reliable and complex once > specified in the draft. > > Regards, > Damian > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Sunday, March 08, 2009 10:00 AM >> To: Dino Farinacci >> Cc: Damian Lezama; lisp@ietf.org >> Subject: Re: [lisp] Map Register has no reply/ACK? >> >> It seems to me that this is at least overly simplified. >> 1) Timers need significant jitter. (Imagine a single server getting a >> bunch of synchronized map register messages? While this structure is >> not as prone to synchronization as some, I would hate to bet against >> it.) >> 2) Under congestion, 3 scattered loss events is not that unlikely. The >> SIP folks concluded that if they were going to use UDP then they needed >> UDP acknowledgments, and a lot of logic to go with it. >> 3) If you are willing to have messages that often, why not use TCP >> instead? The servers can easily handle the number of connections >> involved. You get reliability, congestion control, and other aspects >> as >> you need them. This is particularly useful if a single ETR is a PE >> serving multiple customers, and therefore needing to send multiple >> registers (some PEs handle a very large number of customers.) >> >> Yours, >> Joel >> >> >> Dino Farinacci wrote: >>>> It surprises me that an ETR Map Register UDP message to a Map Server >>>> has no reply. How can the ETR be sure that it has successfully >>>> registered the prefix? >>> Periodic. Right now our implementation is sending a Map-Register >> every 3 >>> minutes and the map-server will time out after 9 minutes of not >> hearing. >>> Dino >>> >>> _______________________________________________ >>> 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 dino@cisco.com Sun Mar 8 12:33:02 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C273A6AFE for ; Sun, 8 Mar 2009 12:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHGLWUu77Zd5 for ; Sun, 8 Mar 2009 12:33:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 104623A69F3 for ; Sun, 8 Mar 2009 12:32:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,325,1233532800"; d="scan'208";a="263539650" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 08 Mar 2009 19:33:25 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n28JXP20004156; Sun, 8 Mar 2009 12:33:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n28JXPQn002540; Sun, 8 Mar 2009 19:33:25 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 12:33:25 -0700 Received: from [192.168.1.5] ([10.21.149.247]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 12:33:24 -0700 Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <49B3F9A7.1000407@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Mar 2009 12:33:24 -0700 References: <49B3F9A7.1000407@joelhalpern.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Mar 2009 19:33:24.0573 (UTC) FILETIME=[BF5008D0:01C9A024] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2817; t=1236540805; x=1237404805; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Map=20Register=20has=20no=20re ply/ACK? |Sender:=20; bh=4ULsYEN8dSl21xYk0pF6klugeYyOC0Dt2bXUfeY39co=; b=Hnv7J2fc2BVDm4MQQbikNBO1QqnHf5KIdIq4lVLSVVC17YCtLXojRVUpge AhYGJn5t5LTO/gbuHIH/15DBhaiIcWwfk9Y4mcm75vP1cXSKgA+fmrbpYnJ2 ar7yXZJvTs; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Map Register has no reply/ACK? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 19:33:02 -0000 > It seems to me that this is at least overly simplified. Well it's a place to start. > 1) Timers need significant jitter. (Imagine a single server getting > a bunch of synchronized map register messages? While this structure > is not as prone to synchronization as some, I would hate to bet > against it.) Yes, all timers are jittered. That goes without saying. We figured that out back in 1991 with IS-IS. > 2) Under congestion, 3 scattered loss events is not that unlikely. > The SIP folks concluded that if they were going to use UDP then they > needed UDP acknowledgments, and a lot of logic to go with it. Yes, this is all well-known. I actually hope that we might not have to do periodic at all. The registration is a one-time thing. And an ETR, if it does not get Map-Requests after it has booted up can try to send a Map-Register. Having this lightweight is a feature, not a bug. We did consider a Map- Register-Ack but it really isn't needed. We want to keep the API between the site and the infrastructure trivial. This is pretty much a one-time registration when a new EID- prefix is added to the site. The Map-Register doesn't really imply reachability. > 3) If you are willing to have messages that often, why not use TCP > instead? The servers can The fanout on map-server could be very large. We want to keep no more data then the configuration state that is needed to do key verification. GRE tunnels, TCP connections, or any other hard state that requires a lot of exchange between the two has always had scaling problems. The very reason we introduced map-server was to eliminate the LISP-ALT GRE tunnels to all xTRs to all sites the LISP-ALT router serves. > easily handle the number of connections involved. You get > reliability, congestion control, and other aspects as you need > them. This is particularly useful if a single ETR is a PE We don't need congestion control. It's too big a hammer. And we get probabilistic reliability. > serving multiple customers, and therefore needing to send multiple > registers (some PEs handle a very large number of customers.) Yes, and we want them to handle more for the next-generation. Dino > > > Yours, > Joel > > > Dino Farinacci wrote: >>> It surprises me that an ETR Map Register UDP message to a Map >>> Server has no reply. How can the ETR be sure that it has >>> successfully registered the prefix? >> Periodic. Right now our implementation is sending a Map-Register >> every 3 minutes and the map-server will time out after 9 minutes of >> not hearing. >> Dino >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Sun Mar 8 12:33:36 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9AEA3A6C3C for ; Sun, 8 Mar 2009 12:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xlmPk2yA16P for ; Sun, 8 Mar 2009 12:33:36 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 16D273A6B47 for ; Sun, 8 Mar 2009 12:33:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,325,1233532800"; d="scan'208";a="139050752" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2009 19:34:09 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n28JY9nr031083; Sun, 8 Mar 2009 12:34:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n28JY94N026804; Sun, 8 Mar 2009 19:34:09 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 12:34:09 -0700 Received: from [192.168.1.5] ([10.21.149.247]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 12:34:08 -0700 Message-Id: <265C31B8-E9D3-411B-974D-C51D8C6BACA5@cisco.com> From: Dino Farinacci To: "Damian Lezama" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Mar 2009 12:34:08 -0700 References: <49B3F9A7.1000407@joelhalpern.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Mar 2009 19:34:08.0979 (UTC) FILETIME=[D9C7DA30:01C9A024] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=453; t=1236540849; x=1237404849; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Map=20Register=20has=20no=20re ply/ACK? |Sender:=20; bh=fbR9Z1aoEkOM21zdJZPS/y0DOarx3ABVG1mW85UxKyU=; b=hg3fdvgKIzwQv6fcPYeFyOOLh/wPuYcg90Eus/ksgDV4UcLPieqpk5YrmG FTIbXlu8BdS5kefSXWT0zgGtpK+wzyVHrsQTc/5EjADnU1upcELg1bsz7DjQ qK3yOwt2fc; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Map Register has no reply/ACK? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 19:33:36 -0000 > I think Dino is referring to a current test implementation not to a > proposed > standard. The draft doesn't say anything about this 3 retries or 3 > min and 9 > min timers. I bet the schema will be more reliable and complex once > specified in the draft. The spec didn't want to be committal on the -00 version. Hence we'll try something in the implementation and then make a conclusion, using the WG, and update the spec. Dnio From dino@cisco.com Sun Mar 8 12:46:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F91028C185 for ; Sun, 8 Mar 2009 12:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85Rs+FByTrZT for ; Sun, 8 Mar 2009 12:46:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8F56A3A6860 for ; Sun, 8 Mar 2009 12:46:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,325,1233532800"; d="scan'208";a="152555425" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2009 19:46:34 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n28JkYJd010548; Sun, 8 Mar 2009 12:46:34 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n28JkY2v000909; Sun, 8 Mar 2009 19:46:34 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 12:46:34 -0700 Received: from [192.168.1.5] ([10.21.149.247]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 12:46:34 -0700 Message-Id: From: Dino Farinacci To: Damian Lezama In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Mar 2009 12:46:34 -0700 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Mar 2009 19:46:34.0510 (UTC) FILETIME=[9626DAE0:01C9A026] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4311; t=1236541594; x=1237405594; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Concerns=20about=20LISP=20Reac hability=20Bits |Sender:=20; bh=5YEHhXPiIGY0bvJ4EcdPdDWxiD/By6kUUFcv6g2Trxs=; b=i/15lu4Osmn8zTceVwfx+fu8ryjTxAw7mn3KtPmH9W+/CjqpgXBJjxopjL 0FG68Wb5dov7pV2RRdmQG+CDxiOMXV0TV4kR7+9G0uQDT9pHd0382ibc+hv5 +ZpqLcCQvK; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rrg@irtf.org, lisp@ietf.org Subject: Re: [lisp] Concerns about LISP Reachability Bits X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 19:46:04 -0000 Sorry for the delay on this response. > Since mapping versioning has been raised for discussion I'd like to > comment > some concerns I have about Lisp Reachability Bits. While versioning > seems to > solve part of this I think some issues still remain. > > 1. Reporting local reachability complicates implementation of ITRs: > Every > time an ITR encapsulates a package it needs to report local > reachability of > the site's ETRs. Not only ITRs must know it (Map Server proposes > lighter > ITRs) but there are also ugly failures to take into account i.e. > ITRs in the > site getting isolated one from another but both working. This is really easy to implement. You decide what the reachability is and then you set the bit-string. Once you have this bit-string it is stored as part of a MAC re-write string when you decide to encapsulate. So the forwarding engine, by no means, is figuring out reachability at packet forwarding time. > 2. Reachability bits don't solve the problem completely: As this > bits detect > only some reachability problems ITRs will also use other mechanisms. > To be Right, we have been saying that since we created them. See the Santo Domingo Nanog slide-set on LISP. The loc-reach-bits handle 3 types of failures, 1) xTR going down, as discovered by the other xTRs in the site, 2) CE-PE link goes down attached to an xTR, or 3) the PE box goes down that is attached to an xTR. So, let's make this clear, we have always said the loc-reach-bits are a *hint*. They don't tell you about up reachability, but do tell you about down reachability. An xTR that receives loc-reach-bit changes could react to them right-away if it wanted to trust the site. An xTR could verify the loc-reach-bits to make sure they are in fact valid and from the right source. The R-bit per locator entry in the locator-set from a Map-Reply are authoritative and can be trusted. The ITR doesn't need per-packet time status of an RLOC. Having it in the data plane provides the opportunity. And we have found some Data Center applications that will use this feature but for the capital-I Internet, cautious use of loc-reach-bits should be considered. > on the safe side some ITR implementations will probably send Map > Requests > after a short period detecting only outbound traffic to some RLOC (and > repeat as often as the standard allows while this condition > continues). Is > it worth having this complicated reachability bits mechanism if it > doesn't > help us much? They are not complicated. They are a compressed way to give you information about many RLOCs in the data-plane. To get the compression, you need the bit-string to refer to the Map-Reply order of RLOCs. Those don't change often so this isn't really a problem. > 3. Ugly failures appear also here (from LISP draft) > > The ETRs, at the site with the changed mapping, records the fact > that the site that sent the Map-Request has received the new > mapping data in the mapping cache entry for the remote site so > the loc-reach-bits are reflective of the new mapping for packets > going to the remote site. The ETR then stops sending packets > with the SMR-bit set. We have outlined that SMRs don't have to be sent often. Removing RLOCs from a locator-set can be flagged as down and the ITRs using the map- cache entry for this site can quickly change to new RLOCs. Add RLOCs are appended to the end so if a site with an old map-cache entry sees a loc-reach-bit that is set for a locator-set it has as "shorter" it can ignore it. The SMR processing needs to only be used when you have to do "compaction" for the above two cases. > ETRs can never be sure if the remote site received or not the Map > Replies. > What if they didn't? What if (or while) some ITRs did and some didn't? > Having an old mapping is bad enough, having reachability bits > inconsistent > with the mapping gets the problem worse. Versioning looks good to > solve this > one. They won't be inconsistent. The xTR that gets the SMR-bit makes sure that it gets a Map-Reply by rate-limiting the retransmission of the Map-Request. Dino From dino@cisco.com Sun Mar 8 12:58:36 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466573A6C62 for ; Sun, 8 Mar 2009 12:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lF2oa8mLC33 for ; Sun, 8 Mar 2009 12:58:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 45F3D3A6C52 for ; Sun, 8 Mar 2009 12:58:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,325,1233532800"; d="scan'208";a="263544707" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 Mar 2009 19:59:08 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n28Jx8Zr029398; Sun, 8 Mar 2009 12:59:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n28Jx8aC005127; Sun, 8 Mar 2009 19:59:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 12:59:08 -0700 Received: from [192.168.1.5] ([10.21.149.247]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 12:59:07 -0700 Message-Id: From: Dino Farinacci To: Robin Whittle In-Reply-To: <49B0B0E3.5050801@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Mar 2009 12:59:07 -0700 References: <49B0B0E3.5050801@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Mar 2009 19:59:08.0060 (UTC) FILETIME=[574D75C0:01C9A028] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4139; t=1236542348; x=1237406348; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Concerns=20about=20LISP=20Reach ability=20Bits |Sender:=20; bh=XUjhg9bT0X1wnyJsW2dp6Jxic8lYXbNkgiuPhIRnULc=; b=Nljd2RtehSHhysHf0r6B+hlWckhFbNsLnDtLU8nm9NtNtHkS8s62cY0DG8 y5mVll7CL+yf6KUu2iHdJyHteEUDRrsd5TcGlCqdSDsylrzjMU5sAQl5mI7i vW6fvvV84HxR2uA/PkNkFTQ0UOelcaUxH7cFdDtiPi1ts1LnthYLo=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: rrg@irtf.org, lisp@ietf.org Subject: Re: [lisp] [rrg] Concerns about LISP Reachability Bits X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 19:58:36 -0000 > With LISP, I have no idea how the ETRs of a particular end-user > network are supposed to coordinate their activities so as to be able > to do anything consistent or reliable regarding telling ITRs which > ETRs are currently reachable, or at least which are reachable from > the DFZ and are also connected well (not congested) to the > destination network. They are configured the same way. > These ETRs are going to be in different ISPs, so how are the ISPs > supposed to configure their ETR to communicate reliably and securely > with ETRs in some other ISP, for every single end-user network which > uses that ETR? ETRs reside at sites. The IGP helps each of them determine the up/down status of the routers. > When things are getting rough, with outages, traffic flowing in > different ways to get around the outage, congestion, misconfiguration > etc. how are the ETRs supposed to communicate reliably to work > consistently together? There is no solution to this today with existing protocols. But you have to think about a network that is designed that would cause a site to completely partition. That is typically known as a dumbbell topology. Where there is a lot of redundant topology on each side of the dumbbell but for some reason there is only a single set of links connecting both ends. No one would design a dumbbell topology and haven't seen one for about 15 years. So we have to choose what failure cases we want to solve and which ones we should leave alone. > How are they supposed to decide what the real reachability situation > is? Likewise the mapping information? There might be three ETRs in > different ISPs, each in some way configured by one or more ISPs > and/or in some way controlled by the end-user network in terms of the > mapping information they send out to the APT network (or register > with their respective Map Servers which do this). > > But what if ETR-A becomes isolated from the end-user network? The > end-user network might configure (or ask its ISPs to configure) the > other two - ETR-B and ETR-C - with some different mapping > information, such as new RLOCs, deleted RLOCs or rearranged RLOCs. > But ETR-A will not have this new configuration and so will be causing > different mapping and/or different locator reachability bits to be > sent out via the ALT network or to ITRs. > > > Versioning may be more secure than the ETR sending locator > reachability bits, and it may involve the ETR in less complexity. > However, I think the whole business of involving ETRs in matters > concerning reachability and mapping is a problem for LISP. Versioning creates the opportunity of having to keep many sets of mappings. Plus the spec encourages use of it more so then we encourage use of SMRs. So I would conclude that there could be more cases and more complexity with versioning. We did consider versioning and realized we'd have to probably implement similar mechanisms as how BGP uses versioning for it's RIB. > During times of disruption, when they most need to communicate, ETRs > will often be unable to communicate reliably. > > In Ivip, ETRs do two things: > > 1 - For encapsulation: Decapsulate packets > > Modified header forwarding: Restore original IP headers > > Then the ETR forwards the packets to the destination network > by some locally configured means. With all due respect Robin, this description lacks any details to allow me to believe you solved the problem. > ETRs might be involved in probing of reachability, by whatever > external system the end-user network hires (or deploys themselves). Probing just doesn't scale for the scale of any-to-any connectivity we have planned. Let me put it this way. Just think about a Google DNS server having to probe every system that has ever sent it a DNS query. And when you have to probe that many systems from many different places, the only way you can scale it is temporally. And when you do that, the usefulness of switchover is lost (takes too long). Dino From dino@cisco.com Sun Mar 8 12:59:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005A628C1EA for ; Sun, 8 Mar 2009 12:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw1nN4UE1m5X for ; Sun, 8 Mar 2009 12:59:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E89DF28C200 for ; Sun, 8 Mar 2009 12:59:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,325,1233532800"; d="scan'208";a="139053230" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2009 20:00:10 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n28K0Aaf030319; Sun, 8 Mar 2009 13:00:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n28K0Adt005873; Sun, 8 Mar 2009 20:00:10 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 13:00:10 -0700 Received: from [192.168.1.5] ([10.21.149.247]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 13:00:09 -0700 Message-Id: <0D10D792-DEEC-4777-8011-9E86923A6C48@cisco.com> From: Dino Farinacci To: Damian Lezama In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Mar 2009 13:00:09 -0700 References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> <20090306162441.GA25825@1-4-5.net> <5bc37fd40903061159q62464ca2y478f212a5342fa8b@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Mar 2009 20:00:09.0667 (UTC) FILETIME=[7C05F130:01C9A028] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=367; t=1236542410; x=1237406410; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Map=20Register=20AH=20ICV=20is =2016=20bits?=20(LISP=20Draft=2012) |Sender:=20; bh=+k1QgNTKkEF1t7dOqRlvtoQ/cKxolbDiePwlgerbMto=; b=YaYJtygNhj+gMSDyGijNo0ybIHrFyez1R0k/2oR3aggpwtnrqSriZYpRT8 /eW4tTfzurfMzSFHUdh3kVBoHQnPqPRbOW7gfMiekobG0iepjnxF/6nDixdD VtXOgRF+P5iZsdHPeXCBZDgbYXj7AzI4vuVFz3UWbfWMrXdRjU8cA=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Map Register AH ICV is 16 bits? (LISP Draft 12) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 19:59:38 -0000 > Hi, I have a question. > > From the draft: > > "The Authentication Data is 16 bytes and holds a MD5 HMAC." > > Isn't it 12 bits? Is it RFC2403 HMAC-MD5-96? No, it is 16 bytes. Dino > > > Regards, > Damian > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Sun Mar 8 13:23:20 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF243A6B30 for ; Sun, 8 Mar 2009 13:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFybkM-MOeGU for ; Sun, 8 Mar 2009 13:23:20 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EE9133A6860 for ; Sun, 8 Mar 2009 13:23:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,325,1233532800"; d="scan'208";a="263549955" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 08 Mar 2009 20:22:53 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n28KMrlr029324; Sun, 8 Mar 2009 13:22:53 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n28KMrwD019811; Sun, 8 Mar 2009 20:22:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 13:22:53 -0700 Received: from [192.168.1.5] ([10.21.149.247]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Mar 2009 13:22:52 -0700 Message-Id: From: Dino Farinacci To: Patrick Frejborg In-Reply-To: <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Mar 2009 13:22:52 -0700 References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Mar 2009 20:22:52.0669 (UTC) FILETIME=[A86F8AD0:01C9A02B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4679; t=1236543773; x=1237407773; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20[lisp]=20LISP=20Map=20Server=20 I-D=20&=20updated=20draft-farinacci-lisp=20-=20=202=20stages =20of=20caching=20mapping |Sender:=20; bh=YzX0VGU96Sh+uuyRDnWl/jxDpN1rj2fRmU86TuK1qXI=; b=D4E2hQacdlKn2ZsVkPgFeDtSutzp8bY3q9dGroSUxzOM5apCm1IrAx3Qp5 MLce45wEzV1ehc+2JEg22pi1daw5ViQYSczjb+qpydsPYoWmJqzmn+lEVJJH LDmckN3jv0; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: RRG , lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 20:23:20 -0000 >>> So now we have two ETRs and two MSes which need to be >>> coordinated. The two MSes both announce the one EID prefix >>> on the ALT network. Yet they are supposed to still be >>> coordinated during outages. >> >> The 2 Map-Servers will converge into a topology that will aggregate >> the >> site's Registered EID-prefix so we can have a smaller ALT core. >> Smaller >> meaning, a small number of EID-prefixes needing to be stored in the >> core of >> the ALT network. >> > > Dino, I'd like to add to what Dave said. > I think the Map-Server proposal is great and I can see synergies with > my hIPv4 framework proposal. Cool, thanks. > Because the Map-Server is not put in the forwarding path, it is > similar to a DNS solution, why can not the Map-Server contain all > prefixes and their RLOC identifiers, i.e. the Map-Server would become > the new DFZ and Map-Severs (MS) are tied together with BGP? Right, that is the concept. When the Map-Servers use LISP-ALT, they are tied together with BGP. If the database mapping service is a DHT, or CONS, or NERD, then those mechanisms tie together the map-servers. > The MS is decoupled from the forwarding fabric, it is more or less a > database and "signaling" instance, right? A powerful server with a lot > of memory should be able to deal with the RIB churn. Right. > I have also a feeling that every service provider would prefer to have > their own MS and therefore the ITR/ETR of that service provider are That will depend on the business model. And if the site wants to decouple it's physical link dependency on an ISP with the one it uses for database mapping services. > adjacent with the MS of the ISP. The ISP would still have in their RIB > all prefixes attached to the SP's network and the RIB also need to > carry all global RLOC identifiers. But overall the growth of the Which are out of PA blocks so can be aggregated to keep routing table size down. > entries in the routers' RIB and FIB would be reduced for each AS. > When a client resolves a destination and found out the destination IP > address it is forwarded to the network, if the destination is not > found in the RIB/FIB it is forwarded to the closest ITR upon the > default route. The ITR make a lookup from the MS and once the RLOC is > found the packets are encapsulated and forwarded to the ETR. The ETR > updates its cache on the information in the packet. Most likely the > ETR has to inform the adjacent MS that it is dealing with this new EID > entry. Yes, you just described LISP egress forwarding from a site in one paragraph. > When a EID changes location the ETR is updating the MS and BGP is > announcing to all MS the change. The MS should then flush the adjacent Well, we did think people would get this reaction to the registration services. But that is not what was intended. The registration service is used so an ETRs at a site can tell the database mapping system that they are available to answer Map-Requests. They are not really registering mappings. They are registering the EID-prefixes they are authoriatively going to answer for. The list of RLOCs in a Map- Register message don't have to be all the RLOCs used to encapsulate data to the site. It's just a list of RLOCs willing to answer Map- Requests for the site. > ITR/ETRs, if they have "subscribed" for that specific EID during the > last , e.g. 24 hours. The update churn is not "flat" anymore, all MS > will be influenced but not all ITR/ETR, except if they have been using > the affected EID. > Or have I misunderstood something? No, it's not that dynamic. We are not claiming you Register and timeout for achieving EID mobility. > Then we have the exhaustion of the IPv4 address space, when that > occurs we have to upgrade the hosts anyway and my draft is trying to > address that issue. I'm little bit early with my proposal but now I > can see both fitting together on a high level. Then a commercial: > draft 01 is on its way through the process - the LSR can be removed in > the future and also "session based" multihoming can be achieved > without the need to implement AS border routing. Well, I'll use this opportunity to say, that once the ISPs get back PA blocks from the sites that move to LISP and decide to get PI blocks, the ISPs can now assign RLOCs to many more sites and those sites can run IPv6-only and use IPv6 addresses as EIDs. So the fact that IPv4 addresses become available is not to keep IPv4 living longer, but to accelerate the adoption of IPv6. Dino From damian.lezama@hotmail.com Sun Mar 8 14:05:46 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB843A69AA for ; Sun, 8 Mar 2009 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHo-tweIxGUo for ; Sun, 8 Mar 2009 14:05:45 -0700 (PDT) Received: from col0-omc2-s8.col0.hotmail.com (col0-omc2-s8.col0.hotmail.com [65.55.34.82]) by core3.amsl.com (Postfix) with ESMTP id 4C84D3A68DA for ; Sun, 8 Mar 2009 14:05:45 -0700 (PDT) Received: from COL110-DS6 ([65.55.34.71]) by col0-omc2-s8.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Mar 2009 14:06:18 -0700 X-Originating-IP: [24.87.17.51] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: "'Dino Farinacci'" References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> <20090306162441.GA25825@1-4-5.net> <5bc37fd40903061159q62464ca2y478f212a5342fa8b@mail.gmail.com> <0D10D792-DEEC-4777-8011-9E86923A6C48@cisco.com> In-Reply-To: <0D10D792-DEEC-4777-8011-9E86923A6C48@cisco.com> Date: Sun, 8 Mar 2009 14:05:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmgKHw4ZhQBh/eaQqu4QWFqd+LmogAApABQ Content-Language: en-us X-OriginalArrivalTime: 08 Mar 2009 21:06:18.0500 (UTC) FILETIME=[B9A1CC40:01C9A031] Cc: lisp@ietf.org Subject: Re: [lisp] Map Register AH ICV is 16 BYTES? (LISP Draft 12) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 21:05:46 -0000 Hi, Thanks. I asked this because even if the key has 128 bits length and the authentication valued computed is also 128 bits long, 96 bits are transmitted for instance in Linux native kernel AH support. This is from RFC2403: HMAC-MD5-96 produces a 128-bit authenticator value. This 128-bit value can be truncated as described in RFC 2104. For use with either ESP or AH, a truncated value using the first 96 bits MUST be supported. Upon sending, the truncated value is stored within the authenticator field. Upon receipt, the entire 128-bit value is computed and the first 96 bits are compared to the value stored in the authenticator field. No other authenticator value lengths are supported by HMAC-MD5-96. I may be missing something here, I'm not an IPsec expert (or anything close to that:) But I'm working in a Linux implementation and I only could get it send packets with 12 bytes AH ICVs for HMAC-MD5 natively, also as per this RFC this 12 bytes truncation MUST be supported. If LISP will use 16 bytes I'll make it work somehow :) Regards, Damian > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Sunday, March 08, 2009 1:00 PM > To: Damian Lezama > Cc: lisp@ietf.org > Subject: Re: [lisp] Map Register AH ICV is 16 bits? (LISP Draft 12) > > > Hi, I have a question. > > > > From the draft: > > > > "The Authentication Data is 16 bytes and holds a MD5 HMAC." > > > > Isn't it 12 bits? Is it RFC2403 HMAC-MD5-96? > > No, it is 16 bytes. > > Dino > > > > > > > Regards, > > Damian > > > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp From rw@firstpr.com.au Mon Mar 9 00:33:02 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EFE3A6A53 for ; Mon, 9 Mar 2009 00:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.541 X-Spam-Level: X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sExO8QGI4DUZ for ; Mon, 9 Mar 2009 00:33:01 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 247213A67CC for ; Mon, 9 Mar 2009 00:33:01 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 70F63175B96; Mon, 9 Mar 2009 18:33:33 +1100 (EST) Message-ID: <49B4C654.7080907@firstpr.com.au> Date: Mon, 09 Mar 2009 18:33:40 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: RRG , lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] LISP Versioning vs. Solicit-Map-Request X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 07:33:02 -0000 Short version: The proposed (not at all official) mapping Versioning approach to LISP should work in all circumstances on a direct ETR to ITR basis. However, its equivalent in the current LISP drafts - Solicit-Map-Request - I think will only work when the sending host is on an EID address, which will frequently not be the case. I think one of the advantages of the Versioning approach: http://tools.ietf.org/html/draft-iannone-lisp-mapping-versioning-00 is that the ETR sends a packet directly to the remote ITR which is sending it encapsulated traffic packets, prompting the ITR to request new mapping if its cached mapping version is less than the version number in the message. This should work in all circumstances where the ITR's Map-Request goes to the ETR, including with the use of non-caching Map-Resolvers. http://tools.ietf.org/html/draft-fuller-lisp-ms-00 or with a caching Map-Resolver when the ITR's Map-Request has the A (Authoritative) bit set, causing the caching Map-Resolver not to answer from its cache, but to send the Map-Request to the ALT network, verbatim, with the ITR's address rather than its own. The ETR sends the Map-Reply straight back to the ITR. The Versioning system should also work to some extent when the ITR requests mapping with the A (Authoritative) flag set to zero, via a caching Map-Resolver. In this case, the Map-Resolver requests the mapping (if it doesn't already have it) and the ETR replies to the Map-Resolver. The ETR then could cache the address of the Map-Resolver and send it a Map-Update-Notification Message. The first potential problem here is how the ETR could figure out the Map-Resolver to send the Map-Update-Notification Message to. This is not a problem if the ETR decides to send it to all recent requesters. But if, for some reason (I don't know how) the ETR decided that a particular ITR's behaviour was indicative of it needing to get new mapping, it could be difficult or impossible for the ETR to figure out which caching Map-Requester the errant ITR got its mapping from. The second potential problem is how a Map-Resolver, which has just obtained updated mapping and recognises it differs from the mapping it recently had and recently sent in a Map-Reply to an ITR, could prompt the ITR to get fresh mapping. I guess the Map-Resolver could send the ITR a Map-Update-Notification Message and rely on the ITR requesting the mapping again, ideally with the A bit zeroed, to save the burden on the ALT network and ETR of sending the request all the way to the ETR, rather than the Map-Resolver generating the Map-Reply from its fresh cache. The ETR could always send a Map-Update-Notification Message direct to the ITR. I guess the ITR should then respond by making a Map-Request with the A flag set, so as to ignore any (perhaps or presumably stale) cached mapping in its local caching Map-Resolver. There is no explicit way in the current LISP protocols for the ITR to request the caching Map-Resolver refresh its mapping cache before sending a reply, other than perhaps sending the Map-Resolver a Map-Update-Notification Message, waiting a few seconds and then requesting the mapping again, with A set to zero. However Dino wrote of an implicit technique: http://www.ietf.org/mail-archive/web/rrg/current/msg04575.html ITR sends A=1 Map-Requests with an SMR-bit set. That can tell the Map-Resolver to ask for the Map-Reply back to update it cache. I know there are security issues with this but it's one way of doing it. At least this Versioning system should work in all circumstances on a direct ETR to ITR basis. The existing LISP system of Solicit-Map-Request (SMR): http://tools.ietf.org/html/draft-farinacci-lisp-12#section-6.5.2 won't work when the remote sending host is on an RLOC address, as will be the hosts of ISPs, of end-users who retain BGP-mapped PI addresses and of the many end-users, such as DSL customers at home, who will continue to use PA address space provided by their ISP. SMR would work when the remote sending host is on an EID address, so packets going to it are encapsulated in a local ITR, with the LISP header with its SMR bit set, to be decapsulated by the remote ETR where the SMR bit will be recognised. Then, the remote ETR signals the ITR at that end-user network to request new mapping. As far as I know, there is no provision for an ETR sending a Solicit-Map-Request to a caching Map-Resolver. Maybe it can, but neither "SMR" nor "Solicit" appear in: http://tools.ietf.org/html/draft-fuller-lisp-ms-00 - Robin From rw@firstpr.com.au Mon Mar 9 01:27:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1AD3A6BBA for ; Mon, 9 Mar 2009 01:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUF6RK9H9aew for ; Mon, 9 Mar 2009 01:27:05 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id B03353A6BCF for ; Mon, 9 Mar 2009 01:27:04 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 5FC61175BDA; Mon, 9 Mar 2009 19:27:37 +1100 (EST) Message-ID: <49B4D2F1.1080908@firstpr.com.au> Date: Mon, 09 Mar 2009 19:27:29 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: rrg@irtf.org References: <49B0B0E3.5050801@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] [rrg] Concerns about LISP Reachability Bits & Ivip's distributed probing X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 08:27:06 -0000 Hi Dino, You wrote: >> With LISP, I have no idea how the ETRs of a particular end-user >> network are supposed to coordinate their activities so as to be able >> to do anything consistent or reliable regarding telling ITRs which >> ETRs are currently reachable, or at least which are reachable from >> the DFZ and are also connected well (not congested) to the >> destination network. > > They are configured the same way. OK, I now understand LISP ETRs reside at the end-user network, and so can be controlled directly there without the ISPs knowing or caring about them. >> Versioning may be more secure than the ETR sending locator >> reachability bits, and it may involve the ETR in less complexity. >> However, I think the whole business of involving ETRs in matters >> concerning reachability and mapping is a problem for LISP. > > Versioning creates the opportunity of having to keep many sets of > mappings. Plus the spec encourages use of it more so than we encourage > use of SMRs. I just wrote a separate message on how I think the Versioning system would work in circumstances where the Solicit-Map-Request wouldn't. > So I would conclude that there could be more cases and more > complexity with versioning. We did consider versioning and realized we'd > have to probably implement similar mechanisms as how BGP uses versioning > for it's RIB. OK - Ivip doesn't have complexities such as Locator Reachability Bits, Versioning or Solicit-Map-Requests. >> During times of disruption, when they most need to communicate, ETRs >> will often be unable to communicate reliably. I understand now that in LISP this is unlikely to be the case, since the ETRs are supposed to be in the end-user network, not in the ISPs. >> In Ivip, ETRs do two things: >> >> 1 - For encapsulation: Decapsulate packets >> >> Modified header forwarding: Restore original IP headers >> >> Then the ETR forwards the packets to the destination network >> by some locally configured means. > > With all due respect Robin, this description lacks any details to allow > me to believe you solved the problem. I was trying to keep it brief . . . ISPs and end-user networks can make their own arrangements for ISP-based ETRs forwarding packets to destination networks, including tunnels, dedicated links or whatever. It is beyond the scope of Ivip to say what those should be, but there may well be reasons for standardising some approaches if anything new is needed. In Ivip, the ETR can be anywhere - it does not have to be at the ISP or at the end-user network. The ETR may have no relationship with the access network of the destination network, especially if the destination network is a Mobile Node. The MN's owner may employ a Translating Tunnel Router company to supply TTRs and other services close to wherever they happen to be: http://www.firstpr.com.au/ip/ivip/#mobile The MN makes a two-way encrypted tunnel to a preferably nearby TTR, from wherever it is, including behind one or more layers of NAT. Incoming and outgoing packets traverse the tunnel and the TTR also acts as an ITR for any outgoing packets which need to go to Ivip-mapped micronet addresses. >> ETRs might be involved in probing of reachability, by whatever >> external system the end-user network hires (or deploys themselves). > > Probing just doesn't scale for the scale of any-to-any connectivity we > have planned. The idea is to have some specialised company with a bunch of probing servers distributed around the Net. These work as a team, and according to whatever the end-user network wants, probes reachability of their network by whatever means and frequency they desire. Typically this would be four to eight or whatever globally dispersed probe servers sending a nonce-carrying ping packet to one or more routers or hosts in the end-user network, but first encapsulating (for map-encap) the packet so it goes via one ETR or another. For modified header forwarding, the probe servers also behave like ITRs and convert the packet's header to include the ETR address (IPv4) or enough of the ETR address (IPv6) - so the upgraded DFZ and other routers to forward the packet to one or another of the ETRs. This way, without the ETRs being explicitly involved in probing (they don't have to recognise or respond to probe packets - but they could), their connectivity from various places in the Net and their connectivity to the end-user network can be probed with whatever frequency the end-user network specifies. The end-user network would also typically give a (revocable) mapping control username and password to the reachability probing company so this company could control the mapping of the end-user network's micronets (EIDs) Then the end-user network would give the company instructions on how long to wait, in the even of an apparent outage (detected by probe packets not acknowledged), before changing the mapping to the ETR which does appear to be working, from the one which was being used, but is now no longer reachable from a sufficient number of probe servers for it to be considered not worth using for traffic. In Ivip, the mapping for any one micronet consists of a single ETR address, so the ITRs have no decisions to make and the mapping is simple and short. In principle, this Ivip approach is less finely adaptable to outages which are localised in some parts of the DFZ, than would be the approach used by LISP or any other system where the ITRs individually decide which ETR to use. However, I doubt this will be a show-stopper. It would only be an advantage to LISP, over Ivip, when both ETRs were partially affected, so that each one had a different section of the Net which could not reach it, and when the affected ITRs could figure this out in time. Assuming the mapping of a micronet is currently to ETR A: As long as one of the ETRs (B) is reachable from the entire Net, then as long as the proposed external probing and decision making system indicates this is the case, and also detects that ETR A is partially or completely unreachable from various places in the DFZ, then the mapping will be changed in a few seconds so all ITRs will tunnel packets to ITR A. At times of both ETRs being unreachable from different parts of the Net, I doubt if the average LISP ITR is going to be able to do a significantly better job than a well designed, individually customised, distributed prober company system as I describe. I imagine that situations where neither ETR is reachable from the entire DFZ would be short-lived, since the BGP system will be busy adapting to whatever has happened and will fix it pretty quickly. I don't think any core-edge separation can prevent outages of a few seconds to 30 seconds or whatever. With Ivip, the response time depends on how frequently the probing is done and how twitchy the decision making process is. I think the Ivip system should be able to change the behavior of all currently involved ITRs in a few seconds. I see the purpose of multihoming and the other benefits of the new kind of address space (I call it Scalable PI space) not so much as trying to prevent short glitches, but in recovering quickly from outages which go on for more than 20 seconds, a minute or whatever - and which might go on for hours, including especially technical or business failure in one of the ISPs. > Let me put it this way. Just think about a Google DNS server having to > probe every system that has ever sent it a DNS query. And when you have > to probe that many systems from many different places, the only way you > can scale it is temporally. And when you do that, the usefulness of > switchover is lost (takes too long). I don't understand how this relates to what I am trying to explain about how with Ivip, the end-user network typically appoints a separate, specialised, company to continually probe its network via how ever many ETRs it has. That probing and the resulting mapping decision making can be customised in any way, by agreement between the probing company and their customer, the end-user network. This is not part of Ivip. So any frequency, any protocol, any number of probing servers in any mix of locations, any decision making algorithm at all can be chosen and finely adapted until the end-user network is happy about the responsiveness to outages and with the frequency of probing. For any network with significant incoming traffic, this burden of probe packets will be far less than whatever probing, or attempts at sending traffic packets, the ITRs of LISP or APT make, since there are potentially thousands of such ITRs sending packets at any one time. You can't rely with LISP or APT on getting any messages to these ITRs about real-time changes in reachability. For one thing, it may not scale to try to send a message to them all. Secondly, you can't easily secure such a message. Thirdly, you can't necessarily piggyback a Solicit-Map-Request on a traffic packet going back to the site with the ITR, since the sending host might not be on an EID address. Also, there could be one-way traffic flows. - Robin From rw@firstpr.com.au Mon Mar 9 02:13:50 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C88528C11B for ; Mon, 9 Mar 2009 02:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fWMSSkFimxc for ; Mon, 9 Mar 2009 02:13:46 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 8ADA028C0ED for ; Mon, 9 Mar 2009 02:13:44 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id D75D2175BE2; Mon, 9 Mar 2009 19:41:46 +1100 (EST) Message-ID: <49B4D641.9090803@firstpr.com.au> Date: Mon, 09 Mar 2009 19:41:37 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: RRG References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> In-Reply-To: <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 09:13:50 -0000 Warning: Long message ahead! Suggested changed to the I-D to make it clearer that the Map-Server does not cache. Map-Servers needing to make GRE tunnels to a large number (hundreds, thousands) of level 1 ALT aggregation routers - and likewise those routers needing to make GRE tunnels to large numbers of Map-Servers. Two Map-Servers for an end-user network's two ETRs will generally link directly (via a GRE tunnel) to the same level 1 ALT aggregation router. There, the router will (I guess) send packets for this network's EID prefix only to one of these, since they both have the same AS hop count of 1. Which will depend on the AS number of the ISP. How can an ALT router, such as this busy level 1 aggregation router, detect the failure or unreachability of a Map-Server? I guess it would find out when it tries to send a Map-Request message to the Map-Server via the GRE tunnel. But is there a keepalive arrangement so the level 1 router could detect the disappearance of this Map-Server before it sends a Map-Request? More on potential problems with caching Map-Resolvers. Hi Dino, Thanks for your reply. Before I respond to what you wrote, I want to point out some ways I think the I-D: http://tools.ietf.org/html/draft-fuller-lisp-ms-00 could be improved, assuming that Map Servers never do any caching, which is what I understand from your reply: > The ETRs are registering their EID-prefixes more so than the > mapping. Just an FYI, if that wasn't clear. Map-Servers don't > answer Map-Requests because they wouldn't be authoritative. 2 Introduction 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. This text: Map-Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database. made me think from the start that Map-Servers are told by the ETR what the current mapping is for the ETR's EIDs, and then, in an abstract way "publish" them globally. In the case of ALT, this meant to my way of thinking, to respond to queries and to answer those queries based on the saved (cached) mapping information provided from time-to-time by ETRs. Then the next section indicating that Map-Servers are analogous to DNS servers, at least in some ways, reinforced my misunderstanding. Again here, it is quite explicit that the Map-Servers store ("learns") the mapping: 3. Definition of Terms Map-Server: a network infrastructure component which learns EID-to-RLOC mapping entries from an authoratative source (typically, an ETR, though static configuration or another out-of-band mechanism may be used). A Map-Server publishes these mappings in the distributed mapping database. However, I realise the above could be interpreted in a different way. For instance, instead of the ETR telling the Map-Server the mapping for some EID, it simply tells it that the ETR is an authoritative query server for mapping requests concerning this EID. "Publishing" then, at least in the case of ALT, means that the ALT network part of the Map-Server "announces" the EID on the ALT network. Then, queries come to the Map-Server and it passes them on to the ETR, as you described in your reply. Actually, with ALT, the Map-Server doesn't simply "announce" the EID over its existing BGP links with other ALT routers (including potentially other Map-Servers. As far as I understand ALT, in a fully operational deployment with 10M EIDs etc. due to the "highly aggregated" nature of the ALT network, it doesn't at all resemble a hodge-podge of geographically close connections to other ALT routers. I think the Map-Server would need to establish GRE tunnels to many first level ALT routers, which could be all over the world. I will write some more about this in a separate message on the scaling of the ALT network. If I had read this definition more carefully, I would have figured out that Map-Servers don't cache mapping information or answer mapping queries: 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. However . . . when I looked at the Map-Register message, and when I look at it now: http://tools.ietf.org/html/draft-farinacci-lisp-12#section-6.1.6 (BTW, "randomly selected UDP port number." should mention "source".) the message is identical to the Map-Reply message, except that the type field is set to 3 instead of 2. The descriptive text is simply: The definition of each field of the Map-Register can be found in the Map-Reply section. So I think pretty much anyone reading this would think that in the Map-Register message, the ETR is telling the Map-Server the complete mapping for an EID, including Locator Reach Bits, TTL (caching time), potentially multiple RLOCs each with Priority and Weight etc. In a recent message: http://www.ietf.org/mail-archive/web/rrg/current/msg04584.html you wrote: The registration service is used so an ETRs at a site can tell the database mapping system that they are available to answer Map-Requests. They are not really registering mappings. They are registering the EID-prefixes they are authoriatively going to answer for. The list of RLOCs in a Map-Register message don't have to be all the RLOCs used to encapsulate data to the site. It's just a list of RLOCs willing to answer Map-Requests for the site. It would be good to add a description like this to the I-D. I would have thought that a Map-Register message from an ETR would only register itself and would only register it in respect of that one Map-Server it was sent to. If you have two Map-Servers in two ISPs, and two ETRs in the end-user network, then - assuming each ETR has a single RLOC address from one ISP, it doesn't make sense to tell the Map-Server of one ISP that it should preferentially forward Map-Requests to a different ETR than the one on this ISP's RLOC address, for instance the ETR which is on the other ISP's RLOC address. Such forwarded messages would be sent out of the first ISP, to the second ISP and than through the PE-CE link to the end user network. Para 1 and 2 of the Basic Overview gives a better impression of the Map-Server forwarding Map-Request messages to the ETR. However, I think you could make it more explicit by stating something like this, maybe after para 1: Map-Servers do not answer Map-Queries or store mapping information. They receive Map-Queries from the distributed mapping database system and forward these to the ETR which registered itself as being an authoritative query server for the EID which matches the address in the Map-Query. The ETR then sends a Map-Reply directly to the RLOC address contained in the Map-Query message. I think the use of "publish" may not be ideal - maybe "announce" would be better. I think this text could be improved, because for someone who wrongly assumes that the Map-Server caches the full mapping of an EID and answers queries, they could find their impression largely confirmed by: (5.2) 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). It would be easy to look at this and think, wrongly, that the ETR tells the Map-Server the full mapping of its EIDs, and then doesn't need to do anything more. In fact, it does need to accept queries and send responses, which are arguably both instances of "participating in the mapping database protocols". 5.3 is quite specific about the Map-Server forwarding requests to the appropriate ETR. I must have not clearly understood this when I first read it. A question I didn't raise in my initial message is how the Map-Server can know, quickly and reliably, that an ETR which has registered itself is no longer available. Firstly, how can the ETR tell the Map-Server that an EID it previously registered is no longer one it handles? Secondly, if the ETR dies, or becomes unreachable to the Map-Server, how does the Map-Server detect this and what decision making algorithms does it employ before withdrawing the advertisement of this ETR's registered EIDs from the ALT network? One thing which confused me on my second reading was: 5.4. Map-Resolver Processing In response to an Encapsulated Map-Request, a Map-Resolver de- capsulates the message then checks its local database of ? mapping entries (statically configured, cached, or learned ? from associated ETRs). If it finds a matching entry, it returns a non-authoratative LISP Map-Reply with the known mapping. I understand that if it is a caching Map-Resolver, it may have the requested mapping in its cache, but I don't understand the other two mechanisms: Static configuration This would mean the Map-Resolver was somehow configured to return mapping replies for some EID - yet it is not an ETR and how could this make sense, since all mapping is supposed to come from an ETR? learned from associated ETRs I don't understand what this could be, since ETRs have no links to the Map-Resolver, and since you haven't defined links between a Map-Resolver and any nearby or integrated Map-Server. You wrote: > Thanks for your comments Robin. > > The main point of draft-fuller-lisp-ms-00.txt is to create a API of > sorts for LISP sites. So they can use a set of primitives regardless of > the mapping database system deployed. OK. > By doing this, the cost of managing an xTR goes way down. No GRE > tunnels, no BGP. Simply Map-Request, Map-Reply, and Map-Register > primitives. Yes - it greatly reduces the need for stability and configuration for each ITR and ETR, since the ALT network is going to need to be carefully managed. Now only the Map-Resolvers and Map-Servers need to be managed so carefully to be a part of the ALT network. However, the original ALT network (without Map-Resolvers and Map-Servers): ITRs ALT routers ETRs was pretty simple in terms of the number of network elements. The ITRs and ETRs also had to be ALT routers, but since I think you can cobble together an ALT router from existing functional blocks in a suitably flexible software- or hardware-based router, this still means you have just 3 types of device in your entire core-edge separation system. That is enviable simplicity! Now you have five: ITRs Map Resolvers ALT routers Map Servers ETRs types of device which is not so elegant. Still, I think any well designed core-edge separation scheme is going to have quite a few functional elements. Ivip has: ITRs (all caching) (Optional caching query servers - QSCs) Full database query servers - QSDs ETRs Replicators for the fast push of mapping to the QSDs Also, there is a single system of Launch servers which drive the Replicator system, and the RUAS organisations which own and run the Launch servers. Reachability probing is external to Ivip, so there would be other systems and perhaps standards for that too. Your ITRs no longer need ALT router functions, but your Map- Resolvers and Map-Servers do. Still, I think it is good, since you need a lot of ITRs and ETRs, and now they can be simpler and talk happily to a smaller number of Map-Resolvers and Map-Servers without needing to be on any stable address and without needing to be known to the ALT network. When I wrote the message you replied to, I wrongly assumed that LISP's ETRs were at the ISPs. Now I know that ETRs, and I guess most ITRs are at the end-user networks. (Proxy Tunnel Routers - PTRs - are not in end-user networks. It is not clear who would run them, but they would advertise prefixes containing lots of EIDs in the DFZ, attracting packets addressed to those EID prefixes. They would send their mapping queries to nearby Map-Resolvers, I guess.) >> My understanding of and comments on this are: >> >> Instead of ITRs and ETRs needing to act as routers in the ALT >> network, they communicate via the ordinary Internet with Map Servers, >> which are routers on the ALT network. This will greatly reduce the >> complexity and configuration difficulties of ITR and ETRs. > > Yes, that is right. ITRs send encapsulated Map-Requests to Map-Resolvers > via the Map-Resolver's RLOC address. OK. > ETRs get encapsulated Map-Requests from Map-Servers via the ETR's > RLOC address only after the ETR Map-Registers to the Map-Server. Oh - I had misunderstood this. Now I realise the Map-Server is a connection system to forward mapping requests from the ALT network to particular ETRs, which have previously securely registered themselves with the Map-Server. I understand the ETR sends the map reply straight back to the Map-Resolver via the Internet. >> These Map Server devices are implicitly local to the ITRs and ETRs in >> a given network and are intended to be used only by those ITRs and >> ETRs. They are always on RLOC (stable, globally reachable, non >> LISP-mapped) addresses. > > Don't know what you mean by local. But if you meant the Map-Server is > colocated with ITRs, that is not true. The Map-Server would typically > not be at the site but in the Internet infrastructure somewhere. Most > likely in an service provider, an interconnect provider, a RIR, or a > third-party. OK - I was assuming the ITRs and ETRs were at ISPs, which is where I assumed the Map-Resolvers and Map-Servers are. I am trying to picture this. I assume a multihomed end-user network with a bunch of ITRs and two upstream ISPs. I assume the Map- Resolvers and Map-Servers are at ISP-A and ISP-B. Each ETR and ITR in the end-user network needs to be on an RLOC address. For simplicity I will assume there are two ETRs and two ITRs: one ETR and ITR for the single IP address of RLOC address which each ISP gives to the network. Now, each ETR has an RLOC address for receiving encapsulated packets, from one ISP only. Assuming two separate ETRs A and B, then ETR-A is going to be on RLOC-IP-A and will register with ISP-A's Map-Server. The same applies to the other ETR-B, which is on RLOC-IP-B and registers itself with ISP-B's Map-Server. The Map-Replies from each ETR will go out their respective links to their "own" ISP. The reply can't very well go out the other ISP's link because the source address wouldn't match. (Alternatively, I guess both ETRs could send from both addresses: RLOC-ID-A and RLOC-ID-B, but when would an ETR receive a Map-Request from one ISP and send the reply out on the other ISP's link? Maybe it could, for outgoing load sharing or similar reasons.) This sounds OK. If ISP-B dies, the link to ISP-B dies or ETR-B dies, then I guess the ITRs in the networks of sending hosts will figure this out by some means and instead tunnel traffic packets to ETR-A on RLOC-IP-A. So in my understanding, each ETR is dedicated to the RLOC address and Map Server of its "own" ISP. ITRs would need to follow a similar pattern, at least in terms of map requests. Your I-D indicates that the ITR is configured with a single address of the Map Resolver it queries. This may be an anycast address in the ISP's network, which sounds good to me. I think each ITR is going to be similarly dedicated to its own ISP and the RLOC-IP address that ISP provides: End-user RLOC Physical ISP network addresses link ISP-A ALT router ..\ / \ ITR-A------ RLOC-IP-A ------- Map-Resolver-A....BR-A==>} DFZ } } ISP-B ALT router ..\ } / \ } ITR-B------ RLOC-IP-B ------- Map-Resolver-A....BR-A==>} DFZ I guess this is OK. You would need to ensure that within the end-user network, outgoing traffic to EID addresses was internally shared between both two ITRs in some way, as long as both links were up, to spread the outgoing load. Also, once one link dies, the corresponding ITR has to stop accepting outgoing packets and these need to go to the other ITR. I guess in many implementations, there will only really be one CE router, with links to both ISPs, and implementing the ETR-A and ETR-B functions all within itself. Likewise probably the ITR-A and ITR-B functions. >> There are two functions which may be combined in the one device: >> >> Map Resolver (MR) >> >> Accepts a mapping query from an ITR and (usually) sends the >> ITR a mapping reply. (The exception is if the MR doesn't >> have the information and sends the query verbatim to some >> other device, which will answer the query directly to the >> ITR.) > > Right, we want to experiment with Map-Resolver caching but want to do > that as a second phase in the implementation. OK. > So the Map-Resolver gets > the Map-Request from the ITR which now puts it on the LISP-ALT network. > If there is another mapping database service, it could be used. > > This way we can make the mapping database service modular and don't need > the sites to participate in it directly. Yes. >> MRs can be caching or non-caching. More on that below. >> >> ITRs are intended to be configured with a single address for >> their local MR. This would raise questions of robustness if >> not for the next item: >> >> Multiple MRs in a local network (such as an ISP network or >> I guess any end-user network which has ITRs) can be configured >> on the one anycast address. This way, the ITR's request will >> be forwarded to the nearest currently active MR. All >> communication is via single packets, not via TCP. Presumably >> the MRs will also have their own unique addresses so they can >> be managed via TCP. > > Right. > >> I think the MR is an important improvement to LISP-ALT, since > > It's not an improvement to the LISP-ALT mapping database, but a > Map-Resolver can be a LISP-ALT router/system, a NERD system, or a > CONS/DHT system. OK. It seems that NERD has been pretty much forgotten for a while now, except by Eliot, but now you are mentioning it as mapping distribution system worth considering. NERD, to date: http://tools.ietf.org/html/draft-lear-lisp-nerd-04 is defined by every ITR-getting the full mapping database, via slow push - actually, ITR initiated downloads of sections of the mapping database and/or updates to the mapping of various sections of the EID address space. But by suggesting a combination of NERD and Map Resolvers, you are now proposing a version of LISP very different from NERD and very different from any other form of LISP. You are proposing a local full-database query system, as used by APT and Ivip. APT and LISP-NERD-MR use slow push of the entire mapping database. Ivip uses fast (a few seconds) push of the entire mapping database, with instant cache updates from the full database query server to any ITR which recently (within the caching time) was sent the mapping fro this micronet (EID) in a map reply. I think CONS has been on the back burner for a while. I never did understand how it worked. Likewise Distributed Hash Tables. BTW, your reference in draft-farinacci-lisp-12 to the DHT I-D doesn't work: draft-mathy-lisp-dht-00 is not in the IETF system. Google finds a copy at: http://inl.info.ucl.ac.be/publications/lisp-dht-towards-dht-map-identifiers-locators but this is from 2008-02 and as far as I know, it has not been in the IETF system. I think ALT looks like a better idea - but like CONS it is still a global query server network and so I think it is going to be fragile and slow compared to having a full database local query server. >> it enables an ITR to be a much more casual and unstable concept >> than was the case when all ITRs needed to participate in the >> ALT network as routers (AFAIK). This means that ITRs can be >> added easily, without having to configure anything. > > True. > >> It also means (though this is my suggestion, not from the LISP >> team) that an ITR function could easily be implemented in a >> sending host, assuming it was not behind NAT. I guess the >> sending host would need to be on an RLOC address - which rules >> out this idea for sending hosts in end-user networks. Ivip's >> ITR in sending host function (ITFH) requires the host to be >> on a non-NAT address which can be and ordinary or a Scalable PI >> address - RLOC or EID in LISP parlance. > > True, however, it would increase the number of locators for a site. That > is the EID to RLOC ratio would be 1-to-1. And the mapping database would > be orders of magnitude larger! Yes. As currently defined, your ITRs must be on non-mapped (not EID) ordinary BGP-routed "RLOC" addresses. So you can't have ITRs in the sending hosts of hosts in end-user networks, because the whole idea of LISP or any other core-edge separation architecture is to have all end-user hosts on EID space. So your ITRs need to be special devices either in the end-user network, or in the ISP, with a direct link to their particular ISP link, on the one or perhaps more RLOC addresses that ISP gives them. Because you anticipate ITRs and ETRs communicating somewhat - such as an ETR receiving a Solicit-Map-Request message which it needs to pass on to the ITR, which will request fresh mapping - I guess this means the ITRs need to be in the end-user network too. Probably, if a big end-user site such as a university has 10 ITRs for ISP-A, then ISP-A needs to give the network at least 10 separate RLOC addresses, one for each ITR. >> Map Server (MS) >> >> Is a router on the ALT network and accepts secure messages from >> one or more ETRs. (Secret key pairs to secure these.) ETRs >> are (typically, or always?) the authoritative source of mapping >> information in LISP. > > Right. The ETRs are registering their EID-prefixes more so than the > mapping. Just an FYI, if that wasn't clear. Map-Servers don't answer > Map-Requests because they wouldn't be authoritative. > >> ETRs can be on any RLOC address and use ordinary packets to >> communicate with the MS. > > Yes, they send Map-Register messages from one of their local RLOCs. > >> My understanding is that the MS announces the appropriate >> prefixes on the ALT network - one for every EID the ETR >> tells it. > > Right, but if the Map-Server is at an aggregation boundary, the specific > EID-prefix won't be announced but the configured aggregate in the > Map-Server would. OK - but I don't understand how the ALT-router part of a Map-Server is going to be part of the highly aggregated ALT network. To be highly aggregated, you need a strict, upside-down tree-like splitting of the address space over more and more routers as you get to lower and lower levels. At some level 1, you have ALT routers which handle all the packets for some pretty small subset of the entire space. They only connect upwards to the level 2 routers, each of which aggregates the space of, for instance, 16 or 64 or whatever of the level 1 routers. I will write more on this in another thread. >> Ignoring MSes for a moment, I have never understood how this >> would work with two ETRs in two separate ISPs handling the same >> EID. > > Multiple ETRs reside at the same site not in the SP network. OK. I understand this now. >> Both ETRs would be routers on the ALT network and would >> announce the same prefix. So where do packets go to? I guess >> to either. > > Within their aggregation level, there are two paths for Map-Requests to > travel to the site. It's the upstream BGP routers that decide which path > to take. They would take shortest path based on AS-path hop-count. > Recall that each LISP-ALT router is doing "eBGP". OK. ISP-A and ISP-B both have Map-Servers - MS-A and MS-B. The end-user network has two ETRs: ETR-A and ETR-B. ETR-A registers with MS-A and ETR-B registers with MS-B - as they would need to, according to the RLOC address each ETR gets from one ISP or the other. Now, for simplicity, assuming the end-user network had an EID prefix 55.44.33.00/24, both ISPs MSes need to advertise this same prefix on the ALT network. I am trying to imagine the ALT network topology. By your specification it is "highly aggregated". Therefore, it does not replicate the pattern of Internet routers - physically adjacent (geographically, but bridged with fibre links, as well as being directly connected in data centres) routers having links between themselves in a pretty random-looking arrangement, with the connections bearing no relation to the addresses which the routers advertise in the DFZ. With the ALT network, the connections between routers can be of arbitrary geographic length via GRE tunnels - including having a neighbour anywhere in the world, involving a tunnel which physically travels over a dozen ASes and twice as many routers. However, due to the highly aggregated nature of the ALT network (which is essential to ensuring the shortest number of ALT routers between the ITR and the ETR, so Map-Requests get to the ETR ASAP) you don't just have ALT routers setting up GRE tunnels to a handful of other ALT routers in nearby ISPs. Since end-user EIDs are portable and can be used anywhere in the world, you can't assume any efficiency gains in the ALT network based on assumptions that EIDs of a certain address range are all going to be used in in any one geographic area. Since each ISP's Map-Servers (I guess they would have one, a few or a dozen or so) are all handling a wide, essentially random, assortment of EIDs, I think there would be little or no value in them having GRE tunnels to neighbouring ISP's Map-Servers. If there was, this would surely not be sufficient connectivity to give the shortest path for Map-Request message to reach the Map-Server. Some might come from nearby ISPs, but others would come only from whatever high level of ALT hierarchy which was fully meshed. So these messages would need to come via an ALT router at level 1 of the hierarchy. This means the one Map-Server will need to make GRE tunnels to a large number of these level 1 ALT routers, which would be distributed physically all over the Net. For your ALT network to be highly aggregated, somewhere there needs to be one ALT router which handles, for instance, 55.44.16.00/12. As far as I know, the LISP team has not explained how the ALT network can be both highly aggregated and robust against single points of failure - for a realistic large-scale deployment handling 10 million physically scattered EID prefixes, 100 million, a billion etc. I am sure what you wrote is correct. But if there was a single aggregating router for 55.44.16.00/12 - which is how I understand the network would be if it is to be highly aggregated - then that router will have GRE tunnels directly from MR-A and MR-B. The AS hop-count is going to be over the ALT network, ignoring physical DFZ routers which carry the tunnel packets. I would expect both the MS-A and MS-B to have the same AS hop count in the level 1 ALT router which handles 55.44.16.00/12, since they are direct neighbours of this level 1 aggregation router. Then, from what I recall about BGP, all the packets from that level 1 aggregation router would be sent to the MS-A ALT router or the MS-B ALT router according to which ISP has the lowest AS number. So in this example, one of the Map-Servers would get all the queries. That isn't necessarily bad. If MS-A is getting all the queries and it dies, then pretty quickly the level 1 aggregation ALT router will sense this and its BGP implementation will direct queries to the GRE tunnel which leads to MS-B. So in this failure example, I think the ability of the ALT network to continue responding to mapping requests moment-to-moment depends on the BGP implementation of this level 1 router. I know little about GRE. How does an ALT router at one end of a GRE tunnel find out quickly if the ALT router at the other end is dead or unreachable? The only way I can imagine this is with regular keep-alive packets going each way. But then, you could have a thousand GRE tunnels per ALT router, such as from the level 1 router to the Map-Servers of 500 end-user networks whose EIDs match this router's aggregation range. I guess this could be rather traffic-intensive and CPU-intensive to maintain. Does the level 1 aggregation router need to do full BGP to each of these Map-Servers? If the Map-Servers are not cross-linked to other ALT routers, but only receive packets and send them to ETRs, then I guess each Map-Server can have a single-homed link to the ALT network. Then, the BGP activity per neighbour (each of 1000 GRE tunnels) would be pretty minimal for the ALT router, and likewise minimal for each Map-Server. But then, how can the system be robust with a single level 1 ALT aggregation router? >> But then the ETRs somehow need to coordinate >> themselves, or be coordinated by something else, so they act >> in a unified manner. Then, as long as both were reachable and >> working properly, it wouldn't matter which ETR got the query. > > Right, but they don't need to coordinate. All they need is to be > consistently configured to Map-Register the same EID-prefix. As I understand LISP, the ETRs for a given end-user network definitely need to be coordinated in some way, since they need to send out the same mapping replies. Also, with locator reachability bits (or the versioning alternative) they need to send out consistent messages to ITRs in this regard too. However, now I understand the ETRs are owned by and located in the destination network, I see it is no problem to coordinate them. >> The same problem seems to apply with MSes. There would be two >> ETRs in two separate ISPs and each would presumably (for >> robustness in a multihoming situation and probably for security >> reasons) have its own MS in its own ISP network. > > No, not true. OK - the Map-Servers simply pass on queries to the ETR which registers with them for that EID range. So they don't cache mapping information or answer queries themselves. Therefore they don't need to be coordinated, except to the extent already provided for by the ETRs securely registering themselves and each MS then announcing that EID prefix on the ALT network. MS-A and MS-B can do this fine without communicating with each other or even knowing about each other. >> So now we have two ETRs and two MSes which need to be >> coordinated. The two MSes both announce the one EID prefix >> on the ALT network. Yet they are supposed to still be >> coordinated during outages. > > The 2 Map-Servers will converge into a topology that will aggregate the > site's Registered EID-prefix so we can have a smaller ALT core. Smaller > meaning, a small number of EID-prefixes needing to be stored in the core > of the ALT network. This is easy in a test network, or with a few tens of thousands of end-user networks. However you haven't described how it would work for the full-scale deployment with 100 million end-user networks. >> However this is resolved, I think it is a big improvement for >> LISP to have MSes, since it reduces the cost, complexity, >> management effort etc. for ETRs similarly to how MRs do the >> same for ITRs. >> >> Both these functions can presumably be performed quite adequately by >> software devices, such as a COTS server with suitable software. >> There doesn't have to be any hardware router FIB etc. AFAIK. > > Yep, that is true. OK. >> This would enable hardware routers to assume ITR and ETR >> responsibilities without them also needing all the software and >> configuration, stable address etc. to be an ALT router. Also, by >> decreasing the total number of ALT routers, this simplifies the ALT >> network. > > Yes, we thought so too. OK. >> I gather from this new I-D, and from what I read in: >> >> http://www.lisp4.net/docs/lisp-ausnog02.ppt >> >> that the current test network and the intention for the future is not >> to send traffic packets on the ALT network. This approach was >> initially an option, with the intention that the ALT network would >> forward the initial packet(s) to the correct ETR, which would then >> forward it to the destination network, while also recognising it as a >> map request and so would send a map reply message to the ITR. > > Right that is correct. The implementation support both sending > Map-Requests and Data-Probes on the ALT network, but we default to > Map-Requests and might possibly deprecate Data-Probes. OK. >> I recall from somewhere that the ITR typically sends out a few >> mapping requests, just in case one of them is dropped. > > Well no, we rate-limit Map-Requests but they are triggered when a source > at the site sends data. However, we can play with this to see what works > well. OK. >> When the ITR >> connects directly to the ALT network, these packets presumably >> usually traverse the entire global ALT network until they are >> delivered to one or more (probably just all to one) ETR which >> responds. I guess the ETR sends multiple replies, but maybe not. >> The reply goes to the ITR via the ordinary Internet. > > Map-Replies are rate-limited as well. OK. >> Removing these potentially long and voluminous traffic packets from >> the ALT network seems like a good idea to me. There may well be >> security benefits in doing so too. Below, I assume the ALT network >> only carries mapping requests, and that the map replies go back from >> whatever answers them (an ETR connected to ALT network, or more >> likely a Map Server) via a direct ordinary Internet packet to the >> device which made the query (perhaps a directly connected ITR or more >> likely a Map Resolver). > > Yes, this is true. OK. >> A Caching Map Resolver? >> >> If the MR caches, then it has the potential to significantly reduce >> the traffic on the ALT network. This is due to two or more ITRs in a >> given ISP network wanting the same mapping, and the second and >> subsequent ones getting it directly from the local caching MR. > > Yes, this was Noel's idea with CONS. It is worth experimenting. OK - and now with ALT. >> This also has the potential to eliminate, for the second and >> subsequent ITRs which need this mapping, the major problem of >> "LISP-ALT's initial packet delays", so much debated on the RRG in >> recent months. > > Well, I'm not so sure. If you point an ITR to an RLOC of a Map-Resolver, > you take the shortest path to it. But if you had a GRE tunnel to the > same box, the GRE tunnel destination would be the same RLOC. So the path > would be the same. But you couldn't run an anycast Map-Resolver service > because the eBGP connections that ran over the GRE tunnels would reset. > So I guess this is an improvement. What you wrote seems to me to be about something different to my intended meaning. I meant that if there are two sending hosts in some end-user network, or even in any of the end-user networks whose ITRs are using a single Map-Resolver at some ISP, then one host requests mapping for EID prefix NNN and after a second or two or whatever, hopefully less (the "long path" problem) the Map Resolver gets the mapping response and nearly instantly sends a mapping response with the same information to the ITR. Now, assuming the Map-Resolver caches this mapping, some other ITR requests from it mapping for the same EID. Now the Map Resolver doesn't need to generate a Map-Request and wait for it to traverse the ALT network. It has the cached mapping and sends the reply back to the second ITR within a few milliseconds. This second ITR therefore has no significant delay in getting the mapping. Ideally - and I don't know whether your ITRs are meant to do this - that second ITR would buffer the first traffic packet, rather than drop it (as I understand your ITRs do at present) and then tunnel it to the ETR within the few milliseconds it takes to get the mapping reply from the Map Resolver. So for the second ITR, there would be no significant delay in traffic packets at all - and no dropped traffic packets in this instance at least. (Of course, if your LISP network Map-Resolvers all used NERD rather than ALT or CONS - joining the local full-database query server throng with APT and Ivip - all your ITRs would be be configured to buffering their initial traffic packets for 100ms or so, awaiting the Map-Reply. Unless something goes wrong, this would involve no significant initial packet delays whatsoever, the few milliseconds it takes to get the mapping from the nearby full database query server = Map-Resolver is not, I think, significant.) >> There is nothing in draft-fuller-lisp-ms-00 to describe this caching >> behavior. >> >> The caching time of map replies is specified in units of one minute: >> >> draft-farinacci-lisp-12: >> >> Record TTL: The time in minutes the recipient of the Map-Reply >> will store the mapping. > > That detail will come in a later draft. OK. >> Let's say at time T = 0 minutes, ITR-A sends a map request to MR-1, >> which has no mapping for the EID prefix which matches the EID address >> in the request message. MR-1 sends its own map request message (with >> its own nonce) onto the ALT network which forwards it to either the > > Well, that's not the way it works. The ITR sends an encapsulated > Map-Request to the Map-Resolver. The Map-Resolver strips the outer > header and then forwards the Map-Request on the ALT. The source address > is the ITR RLOC address and the destination address is the EID that > caused the map-cache fault on the ITR. OK - this is a Map-Resolver without caching. As long as you have no caching, then the Map-Resolver doesn't contribute to the resolution of the "long path" problem. LISP-ALT's long path problem yet again 2008-12-24 http://www.ietf.org/mail-archive/web/rrg/current/msg04097.html >> single Map Server which advertises the matching EID prefix on the ALT >> network, or to one of the multiple such Map Serves, or perhaps to the >> directly ALT-connected ETR(s) which do the same. > > Correct. OK. >> That device sends the mapping reply back to MR-1 directly via the >> Internet. The reply is secured by returning MR-1's nonce. > > No, it would go to the ITR because in the Map-Request payload there is > an "ITR RLOC" field. This is quite important because if that Map-Request > was an IPv6 Map-Request with an IPv6 outer header, and since the > LISP-ALT network we have deployed is dual-stack, the IPv6 Map-Request is > forwarded on the ALT, but the ETR may not (and probably not) have a IPv6 > path back to the ITR. So if the "ITR RLOC" field is encoded with an IPv4 > RLOC, the ETR sends a Map-Reply back with an IPv4 header. > > In the entire LISP design we treat IPv4 and IPv6 equally and try to > enhance IPv6 connectivity by using IPv4 outer headers or IPv4 RLOCs when > encapsulating. > > Today, two IPv6-only sites can open an IPv6 TCP connection to each other > if they run LISP and use IPv4 locators. My discussion assumes a caching role for the Map-Resolver. Without that, its contribution is mainly to make it easier to get a lot of ITRs working without each one being a part of the ALT network. This is good, but it does nothing to reduce the "long path" delay problem. >> Let's say the mapping reply comes back with a 90 minute caching time. >> >> MR-1 sends to ITR-A a map reply, with ITR-A's request's nonce, with >> the fresh mapping information and a caching time of 90 minutes. Now >> MR-1 can encapsulate packets to its choice of ETRs, based on the >> fresh mapping it has received and whatever it has determined about >> reachability of those ETRs, and of the ETRs' ability to get packets >> to the destination network. > > No, no, no. The Map-Resolver does not encapsulate any packets. Remember > the ALT has no data going over it. OK - I meant to write "ITR-A" can encapsulate packets to ..." > If the Map-Resolver is caching Map-Replies and the ITR sends a > Map-Request with A=0, then the Map-Resolver can respond with a > Map-Reply. If the ITR sends a Map-Request with A=1, the Map-Resolver > must forward the Map-Request over the ALT so an authoritative Map-Reply > can be returned by the ETR. OK. This is the Authoritative bit in the Map-Request message: http://tools.ietf.org/html/draft-farinacci-lisp-12#section-6.1.2 In my example I am assuming the ITR trusts the caching ability of the Map Resolver and would prefer a quick reply (and no more burden on the ALT network, the Map Server or the ETR) to waiting longer for an authoritative reply from the ETR. So the ITR would set the A bit to zero. The authoritative reply would be fresh with the full length of caching time, but I figure that in most instances, whatever remained of the caching time in the Map Resolver's cached mapping would be sufficient for the ITR. >> Later, at T = 85 minutes, ITR-B sends a mapping request to MR-1 for >> an address which matches this same EID prefix. MR-1 can use its >> cached information and send a reply within a few milliseconds. This >> means ITR-B's traffic will not be delayed by any significant amount. >> >> What caching time will be in that reply to ITR-B? I assume it will >> be 5 minutes. If it would be 90 minutes, ITR-B could be running for >> a long time to come on stale mapping information. > > We haven't figure that out yet. We don't want to create an impression > that a cacher of a Map-Reply can use any TTL it wants. We want to make > it mandatory to respect the ETR's value. OK. >> Assuming ITR-A no longer needs this EID's mapping, but ITR-B keeps >> needing to tunnel packets addressed to this EID, then at T=90 >> minutes, ITR-B will want mapping information again. >> >> Should ITR-B request the mapping again at at T = 88 minutes, in >> readiness for probably needing it in 1 minute's time? > > It could, but the reasons to time out the map-cache entry is to keep the > cache small and to be resilient, to some extent for locator-set changes > at the ETR site. OK. >> This would seem like a generally reasonable approach if it prompted >> MR-1 to get fresh mapping information, but why should MR-1 do this? >> Would MR-1 need to look at the original caching time and how much >> has expired to decide whether it should, by some algorithm, request >> fresh mapping? But what if the mapping hadn't changed in the distant >> Map Server, but the ETR was going to change it two minutes later? > > One of the problems I see with caching in the Map-Resolver is if the > map-cache entry does have a locator-set change and the ETR asks all > cachers to send Map-Requests (it does this by setting the SMR-bit for > active flows), the Map-Resolvers cannot get updated because they are not > seeing data. > However, I have a solution for this because, it will be the ITR that > sends A=1 Map-Requests with an SMR-bit set. That can tell the > Map-Resolver to ask for the Map-Reply back to update it cache. I know > there are security issues with this but it's one way of doing it. OK. I have just written a message about the Versioning approach working in all circumstances, but Solicit-Map-Request (SMR) not working when the sending host is not on an EID address: LISP Versioning vs. Solicit-Map-Request http://www.ietf.org/mail-archive/web/rrg/current/msg04585.html quoting this part of your reply. > There are also details how a Map-Resolver asks to get the Map-Reply > back. We want to do this in a stateless manner in the Map-Resolver. So > we might have to preserve the ITR RLOC's address in the Map-Request but > instruct the ETR where to send the Map-Reply. We have some ideas and > what to think about it before changing packet formats. By "stateless" do you mean you don't want the Map-Resolver to have to remember which ITR to reply to when it gets some Map-Reply back? Then, I guess, if the Map-Reply came back from the ETR to the Map-Resolver with the ITR's address embedded, the Map-Resolver could figure out from that Map-Reply, without any state, to send the mapping on to that ITR. >> If ITR-B waited until T = 90 or a little later before requesting >> fresh mapping, then unless MR-1 had already got fresh mapping in the >> last minute or two, then there would presumably be a delay in the ITR >> being able to handle traffic for this EID, since it would take some >> time for MR-1's second mapping request to traverse the ALT network >> and generate a reply to MR-1. >> >> There are various scenarios, but I think there are potential >> difficulties with caching times running out in three locations now >> rather than one. > > Yeah, we can't get too tricky about manipulating TTLs. DNS has been > fraught with problems due to TTL issues. If anyone has advice about > this, it would be nice to hear about it. OK. >> Previously, it was simple (despite the scaling problems of lots of >> ITRs peppering an ETR for mapping, not to mention them all trying to >> decide reachability for this and other ETRs): >> >> ITR query -----------> ETR >> <----------- reply >> cache >> >> >> Now we have: >> >> ITR query -----> Map query -----> Map >> <----- reply Resolver <----- reply Server <--Register- ETR >> >> Cache Cache Cached, in a sense, >> controlled by messages >> from the ETR(s) whenever >> they can reach the >> >> Map Server and decide >> to send a Map Register >> message. > > Right, but what if we used for first case and have the ETR schedule an > update to the Map-Resolver? Or what if the ITR updated the Map-Resolver? > Not sure yet. And not even sure how much RTT will buy us with > Map-Resolver caching. OK. >> I think this raises more complex problems with: >> >> 1 - How to avoid cache times running out at ITRs >> which are going to be tunneling packets addressed >> to this EID after the cache time expires. >> >> Such a situation will cause a traffic delay unless >> the local Map Resolver has recently got fresh mapping. > > But I think this is issue has continually been exaggerated. The > Map-Request delay is not for a lot of packets and will be relatively > rare I imagine. I and others still think it is a serious problem. If people had the choice between two routers, one of which occasionally delayed new sessions by a second or two and one that didn't, then there would need to be compelling reasons to buy the first one. End-users who can only get PA space, without multihoming now, might be attracted to LISP-ALT space, despite the delays. However any larger end-user network would definitely not want to switch their BGP-managed PI prefixes over to LISP-ALT management if it resulted in this inferior behavior. It is not just a TCP session being delayed by a fraction of a second, or a second or two (or several seconds if the lone request and response packet is lost in the global ALT network). The delays will sometimes affect initial attempts to reach a DNS server, since end-user networks will be running their won DNS servers and they will be on EID spaces, not necessarily the same EID prefix as the host whose address is being looked up. Likewise, the delay could be two delays, not counting DNS. Firstly a delay in getting a packet from host X to host Y (on an EID address). Then, if X is also on and EID address, Y's ITR could have a delay in getting the mapping for X. The delays are not necessarily simply bounded by the response time of the ALT network. If the ITR buffers the packet and waits, and if the response arrives before the sending host tries again, this would be optimal. However, if the ITR drops the packet, figuring the response will come too late to be worth sending the original packet, then the delay time is more likely to be a function of how long it takes the sending host to time out and try again. Sending a delayed packet around the time of the second packet would probably cause confusion and unwanted responses, an argument for ITRs dropping all packets they have no mapping for. But with a caching Map-Resolver, maybe the ITR can get the mapping in a few milliseconds - so it should buffer the packet and send it when the mapping arrives. It cannot be assured the sending host will retry. It might just try the communication to a different host, in a different EID, and so be subject to the same potential delay problems which could easily outlast the host's time-out value. If something like LISP-ALT was widely implemented, sending hosts might be tempted to generate a flurry of closely spaced packets, in order that one or more of them would be sent as soon as the mapping arrives in the ITR. Since the sending host can't anticipate whether the ITR has the mapping, could get it in a few milliseconds, or might have to wait for it for fractions of a seconds or more (or forever, if the request or reply is lost) then I think this scenario might encourage undesirable host behavior trying to milk the fastest performance out of the uncertain ITR mapping situation. >> 2 - How to minimise unnecessary map requests by Map >> Resolvers trying to anticipate ITRs making such >> requests, but actually requesting fresh mapping from >> the distant Map Server when the ITR doesn't need it. > > Right, Map-Resolver caching could be more trouble than it is worth. I wasn't suggesting this was necessarily the case. If you could contemplate converting LISP to a local full database query system with NERD-like full push to Map Resolvers, I think the much lesser change from ALT of having caching in the map resolvers (local caching query servers) is worth contemplating. >> Without further complications, the Map Resolver can't know whether >> the one or more ITRs which requested the mapping for an EID are still >> handling traffic for that EID. So it can't very well request fresh >> mapping towards the end of its expiry, just in case an ITR wants it. >> To do so would approximately double the volume of map requests >> traversing the ALT network, since it is reasonable to assume, with >> longish caching times, that the original caching time will generally >> suffice for the needs of the one or more ITRs served by the Map >> Resolver. (This would not be true with a busy Map Resolver and >> popular EIDs many ITRs are sending packets to.) >> >> Without some elaboration of the request protocol, ITR-B at T = 85 >> minutes can't ask the Map Resolver to get fresh mapping and send it a >> new reply - unless there is some algorithm in the Map Resolver such >> as: "If the cached mapping is 90% of the way to its expiry time, do >> not answer the new request from the cache, but send a fresh map >> request and then answer the query if and when the new reply arrives." >> >> To do so would effectively shorten all the caching times. > > Well, it the mappings don't change, longer TTLs will help the > Map-Request load on the ALT. If there are frequent changes and you want > fast convergence to them, then you use more resources. > That is the tradeoff. OK. >> At present, there is only one kind of map request message from an ITR >> to a Map Server - implicitly an urgent request. >> >> If there was a second kind: >> >> "This ITR has mapping for this EID which will expire in some >> time period (specified) soon, and requests the Map Resolver >> to get fresh mapping from the Map Server now, and to send >> a reply once this arrives." > > There is no reason why the ITR cannot send a Map-Request directly to the > RLOC of the ETR. It does have a set of them he can try. And the nonce > will protect against ETR spoof attacks. OK - but that wouldn't help update the cache of a caching Map-Resolver. >> then I think these problems would be resolvable with less trouble and >> less need for choices based on limited information. >> >> - Robin > > Thanks again for your comments Robin, > Dino Thanks for responding - in detail! - Robin From pfrejborg@gmail.com Mon Mar 9 02:36:53 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471CE3A6BF3 for ; Mon, 9 Mar 2009 02:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY3rTRHMjlAS for ; Mon, 9 Mar 2009 02:36:52 -0700 (PDT) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 9445B3A69E5 for ; Mon, 9 Mar 2009 02:36:49 -0700 (PDT) Received: by bwz26 with SMTP id 26so1110491bwz.37 for ; Mon, 09 Mar 2009 02:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nvbAsDlpV4s5DtDv3YL0UFasc6vgbcMIrrQmg5TuDYs=; b=JlavEBDntg1kab4joXDjLKncVZKpoYZeW7914XcsOKfscF3HU0RXYez27qTGclAUBx /wHdmDhywn1bhASoSFX1yUmwG0HGmDO/DcxX/1aXu9FJgCjCsUdT05GoIqfddOEgcqGV VfOdsCppxpTC8cHNQRjD3OR+YZvZwV2PeWNVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NygQf04oWTeCTrIXKXzzoP7Zf2x3Ski3+4q0FzKo5XB/71anpg1NIViqDclxm7KB6W 8TgoesxTnwomtdxjchhTCmdzObGdfyaPHCt0FBRVAg/gMGOGL8CwbadGtkikYchq/8gi gU6xjAanYxMfOp8psxug/8uNU6UuV6ve6s3NU= MIME-Version: 1.0 Received: by 10.181.148.3 with SMTP id a3mr1976968bko.131.1236591442539; Mon, 09 Mar 2009 02:37:22 -0700 (PDT) In-Reply-To: References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> Date: Mon, 9 Mar 2009 11:37:22 +0200 Message-ID: <5bc37fd40903090237h1989137bg92eba17b00f17a9d@mail.gmail.com> From: Patrick Frejborg To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: RRG , lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 09:36:53 -0000 On Sun, Mar 8, 2009 at 10:22 PM, Dino Farinacci wrote: > Well, we did think people would get this reaction to the registration > services. But that is not what was intended. The registration service is > used so an ETRs at a site can tell the database mapping system that they = are > available to answer Map-Requests. They are not really registering mapping= s. > They are registering the EID-prefixes they are authoriatively going to > answer for. The list of RLOCs in a Map-Register message don't have to be = all > the RLOCs used to encapsulate data to the site. It's just a list of RLOCs > willing to answer Map-Requests for the site. > >> ITR/ETRs, if they have "subscribed" for that specific EID during the >> last , e.g. 24 hours. The update churn is not "flat" anymore, all MS >> will be influenced but not all ITR/ETR, except if they have been using >> the affected EID. >> Or have I misunderstood something? > > No, it's not that dynamic. We are not claiming you Register and timeout f= or > achieving EID mobility. > Aah, I think I got it. LISP is similar to SIP, setting up data connections instead of sessions over the IPv4 backbone and the main target is enterprises that are looking for multihomed solutions and a transition to IPv6, right? >> Then we have the exhaustion of the IPv4 address space, when that >> occurs we have to upgrade the hosts anyway and my draft is trying to >> address that issue. I'm little bit early with my proposal but now I >> can see both fitting together on a high level. Then a commercial: >> draft 01 is on its way through the process - the LSR can be removed in >> the future and also "session based" multihoming can be achieved >> without the need to implement =A0AS border routing. > > Well, I'll use this opportunity to say, that once the ISPs get back PA > blocks from the sites that move to LISP and decide to get PI blocks, the > ISPs can now assign RLOCs to many more sites and those sites can run > IPv6-only and use IPv6 addresses as EIDs. > > So the fact that IPv4 addresses become available is not to keep IPv4 livi= ng > longer, but to accelerate the adoption of IPv6. > > Dino Ok, I don't want to start a debate here, but some comments on that topic anyway. I have recently been working with enterprises helping them with their IT projects. If you have a proposal for them you have to have an answer to "how will this support your business better" and "what's the return of investment" - if you don't have something supporting those questions then the CIO starts to throw shoes on you. That's why IPv6 has been in a catch-22 situation for about ten years...IPv4 had a lot of answers to those questions and that's why it got so successful. -- patte From dmm@1-4-5.net Mon Mar 9 08:08:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519943A69BD; Mon, 9 Mar 2009 08:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHNvsdZJGy4i; Mon, 9 Mar 2009 08:08:38 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id CC1EF3A6C95; Mon, 9 Mar 2009 08:08:27 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n29F8qtD016957; Mon, 9 Mar 2009 08:08:52 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n29F8q89016956; Mon, 9 Mar 2009 08:08:52 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 9 Mar 2009 08:08:52 -0700 From: David Meyer To: Patrick Frejborg Message-ID: <20090309150852.GA16770@1-4-5.net> References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> <20090306162441.GA25825@1-4-5.net> <5bc37fd40903061159q62464ca2y478f212a5342fa8b@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <5bc37fd40903061159q62464ca2y478f212a5342fa8b@mail.gmail.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: RRG , lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:08:39 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Patrick, > On Fri, Mar 6, 2009 at 6:24 PM, David Meyer wrote: > >> The ISP would still have in their RIB > >> all prefixes attached to the SP's network and the RIB also need to > >> carry all global RLOC identifiers. But overall the growth of the > >> entries in the routers' RIB and FIB would be reduced for each AS. > >> When a client resolves a destination and found out the destination IP > >> address it is forwarded to the network, if the destination is not > >> found in the RIB/FIB it is forwarded to the closest ITR upon the > >> default route. The ITR make a lookup from the MS and once the RLOC is > >> found the packets are encapsulated and forwarded to the ETR. The ETR > >> updates its cache on the information in the packet. Most likely the > >> ETR has to inform the adjacent MS that it is dealing with this new EID > >> entry. > > > > =A0 =A0 =A0 =A0I'm not sure I understand. The map-server connects to the > > =A0 =A0 =A0 =A0ALT, which of course has a RIB, but it seems you're > > =A0 =A0 =A0 =A0talking about the DFZ RIB (RLOCs and all). Which one are > > =A0 =A0 =A0 =A0you talking about? >=20 > I got a little bit carried away here... > I had my first architecture (that haven't been published) in mind > which is close with the MS -except that instead of a MS I had a DNS > server. It got complicated and after some discussions I decided to go > after the host stack instead. Ok, gotcha, thnx. > So I'll try to explain what I have in mind. If you have a B-RAS with a > very good IP-subnetting plan in place you will have only one IP subnet > on the B-RAS. So applying ITR/ETR on that B-RAS will not reduce the > size of the DFZ - we are mapping a subnet/RLOC 1-to-1. Also if you > have very good aggregation in place LISP will not help that much. Right now, right? Since its a BRAS I'm assuming what's behind it is dynamically addressed (and readdressed at some regular interval). Right? If so, then the things behind the BRAS might someday be (naturally) renumber into some EID space, the the BRAS could play xTR (and hence have a few RLOCs). Or do you see it differently? > So I thought that the RLOC should be connected to the AS (or actually > an area) somehow, let say you assign a block /23 to an AS (or > geographical area) and the ISP are taking its RLOC identifiers from > that block for its ITR/ETR. The ITR/ETR are located in the ISP network > but not necessary at the edge routers - if you have ITR/ETR on the > edge routers you need a lot of IP addresses and you need to replace a > lot of hardware (costs have to be covered somehow). Instead you place > them on strategic places in the network so you can have several edge > routers behind one ITR/ETR. Sure, you could do it that way. > And to the ALT network you just advertise on prefix, the /23 and not > the individual RLOC host prefixes. This becomes a sort of super > aggregate, the AS or an area is shown behind one /23 RLOC prefix. You lost me (you don't advertise RLOCs into the ALT). > LISP-ALT will be the global directory, which IP prefix is connected to > which RLOC identifier for time being and this directory will grow but > it is disconnected from the forwarding plane so the FIB doesn't need > to be upgraded - only in the AS that grows too big. But that is then > up to the service provider, split the AS to two AS or buy new hardware > - the ISP have a choice. Again, I think we're mangling a few things here. There are no RLOCs in the ALT. > One question for you, how are you going to deal with portsweep on the ITR? > I have seen ISP using NAT on the B-RAS (along time ago), an end user > could easily saturate the NAT table so that all customer behind that > B-RAS lost connectivity. What is portsweep? Do you mean scanning? If so, yeah, its a problem for everyone on the big bad Internet. > I think we should design LISP and LISP-ALT so that later on the > functionality can be taken to the hosts, both options are needed so > that the enterprise and service providers do have a choice.=20 I couldn't follow that. Can you try to rephrase it? Thnx.=20 > Also much can be improved by going after the hosts, e.g. mobility and > UDT features can be interesting for the enterprises and a good reason > to upgrade. Sure, I agree that lots can be done in the hosts. dAVE --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1MQQACgkQORgD1qCZ2KfqBgCfQS5y9teGL/Spbj2dgpEVkpiD mgUAn3ca5hTPtHYF7JoY2jn1XYqLGBDL =NERc -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From dmm@1-4-5.net Mon Mar 9 08:28:30 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FFE3A6843; Mon, 9 Mar 2009 08:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0bhjp8HE6AI; Mon, 9 Mar 2009 08:28:29 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 9931D3A67B3; Mon, 9 Mar 2009 08:28:29 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n29FT0fE017313; Mon, 9 Mar 2009 08:29:00 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n29FSxAD017312; Mon, 9 Mar 2009 08:28:59 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 9 Mar 2009 08:28:59 -0700 From: David Meyer To: Robin Whittle Message-ID: <20090309152859.GB16770@1-4-5.net> References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <49B4D641.9090803@firstpr.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50" Content-Disposition: inline In-Reply-To: <49B4D641.9090803@firstpr.com.au> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: RRG , lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:28:30 -0000 --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Robin, > Map-Servers needing to make GRE tunnels to a large > number (hundreds, thousands) of level 1 ALT > aggregation routers - and likewise those routers > needing to make GRE tunnels to large numbers of > Map-Servers. Actually, those numbers (100s, 1000s) are speculation. There are many ways folks might deploy this technology (e.g, with hierarchy of some kind, as one example). So lets see what how people actually deploy stuff before speculating on what they might do (and I would strike the not-so-parenthetical comment from future discussions).=20 BTW, the RRG (or IETF, or ITU-T, or ATIS, ...) can specify any technology they want. However, SPs if deploy it, they will deploy it in the way that makes most business sense for their particular predicament, and that may or may not bear any relationship to what is said in SDO deliberations. And unfortunately, we have precious little input from those folks our (SDO) fora. > Two Map-Servers for an end-user network's two ETRs > will generally link directly (via a GRE tunnel) to > the same level 1 ALT aggregation router. There, > the router will (I guess) send packets for this > network's EID prefix only to one of these, since they > both have the same AS hop count of 1. Which will > depend on the AS number of the ISP. I don't know what level 1 ALT means. The ALT doesn't carry level identifiers (we thought about this in CONS but discarded it for various reasons). And again, just like everything else, you build scalability with hierarchy. Like every hierarchy, there will be a "top level", but not everyone will or needs to connect to such a top level. > How can an ALT router, such as this busy level 1 > aggregation router, detect the failure or > unreachability of a Map-Server? I guess it would > find out when it tries to send a Map-Request message > to the Map-Server via the GRE tunnel. But is there > a keepalive arrangement so the level 1 router could > detect the disappearance of this Map-Server before > it sends a Map-Request? >=20 > More on potential problems with caching Map-Resolvers. Regarding "upness": You can make the same argument for BGP peers in the DFZ (or DNS if you like). In the case of BGP, we use BGP keepalives, BFD (if you like), and the existence of the route in the RIB/FIB as basically a bunch of heuristics, which work pretty well (when was the last time you couldn't get to Google because of a routing problem on the Internet?). Hence we don't need to calculate some exact value of "upness" (which is a good thing). BTW, the question "is entity X up" really reduces to Zeno's paradox (think: what is the granularity of "upness", and how often do I need to ask?). And we know what it took to solve Zeno's paradox. But as mentioned above, we can do a fine job (within our engineering constraints) with clever heuristics. The operational Internet is pretty much an existence proof of that. Dave =09 --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1NbsACgkQORgD1qCZ2Ke5mwCePqc30rUfbsZd8myyzwEBV8rl fYMAn2Q++3e25DIBquD1vm6TqX/EeWLA =NIsl -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50-- From dmm@1-4-5.net Mon Mar 9 10:52:36 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0423A68A9 for ; Mon, 9 Mar 2009 10:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUUeqcRBiwHd for ; Mon, 9 Mar 2009 10:52:36 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id E5E3128C236 for ; Mon, 9 Mar 2009 10:52:27 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n29Hr2dS024656 for ; Mon, 9 Mar 2009 10:53:02 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n29Hr2fG024655 for lisp@ietf.org; Mon, 9 Mar 2009 10:53:02 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 9 Mar 2009 10:53:02 -0700 From: David Meyer To: lisp@ietf.org Message-ID: <20090309175302.GA24622@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [lisp] Draft LISP WG agenda for IETF 74 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:52:37 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable See below. Questions, comments, additions please. Dave --- Locator/ID Separation Protocol WG Wednesday, 25 Mar 2009, 0900-1015 (Morning Session I) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D CHAIR(s): Darrel Lewis (darlewis@cisco.com) TBD AGENDA o Administriva 5 minutes - Mailing list: lisp@ietf.org http://www.ietf.org/mail-archive/web/lisp/current/maillist.html - Scribe(s)? Jabber Other=20 - Blue Sheets o Agenda Bashing 5 minutes Lewis o Charter Review 10 minutes Meyer o Review and status of work items =20 Active Drafts ------------- draft-farinacci-lisp-12.txt 15 minutes Farinacci draft-fuller-lisp-alt-05.txt 20 minutes Fuller draft-fuller-lisp-ms-00.txt 20 minutes Fuller Wednesday, 25 Mar 2009, 1030-1130 (Morning Session II) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D o Review and status of work items, cont Active Drafts ------------- draft-lewis-lisp-interworking-02.txt 15 minutes Lewis draft-farinacci-lisp-multicast-01.txt 15 minutes Farinacci =20 Potential New WG Items ---------------------- draft-iannone-lisp-mapping-versioning-00.txt 15 minutes Iannone Next Steps 15 minutes ---------- Lewis/All --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1V34ACgkQORgD1qCZ2KcSKwCfZCLMVFdEKZzOB/Y0uggr62iz pQwAn3IS+DUiKyMGgWOUbdyTqyqBzbNO =e4de -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From dmm@1-4-5.net Mon Mar 9 11:08:24 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A6128C231 for ; Mon, 9 Mar 2009 11:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h3YopQvo1IJ for ; Mon, 9 Mar 2009 11:08:23 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id A6FED28C229 for ; Mon, 9 Mar 2009 11:08:23 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n29I8vQ8026448 for ; Mon, 9 Mar 2009 11:08:57 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n29I8vEE026447 for lisp@ietf.org; Mon, 9 Mar 2009 11:08:57 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 9 Mar 2009 11:08:57 -0700 From: David Meyer To: lisp@ietf.org Message-ID: <20090309180857.GA26423@1-4-5.net> References: <20090309175302.GA24622@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20090309175302.GA24622@1-4-5.net> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [lisp] Updated [Draft LISP WG agenda for IETF 74] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:08:24 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Added a section for unassigned work items from the charter. Thnx, Dave --- Locator/ID Separation Protocol (LISP) WG Wednesday, 25 Mar 2009, 0900-1015 (Morning Session I) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D CHAIR(s): Darrel Lewis (darlewis@cisco.com) TBD AGENDA o Administriva 5 minutes - Mailing list: lisp@ietf.org http://www.ietf.org/mail-archive/web/lisp/current/maillist.html - Scribe(s)? Jabber Other=20 - Blue Sheets o Agenda Bashing 5 minutes Lewis o Charter Review 10 minutes Meyer o Review and status of work items =20 Active Drafts ------------- draft-farinacci-lisp-12.txt 15 minutes Farinacci draft-fuller-lisp-alt-05.txt 20 minutes Fuller draft-fuller-lisp-ms-00.txt 20 minutes Fuller Wednesday, 25 Mar 2009, 1030-1130 (Morning Session II) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D o Review and status of work items, cont Active Drafts ------------- draft-lewis-lisp-interworking-02.txt 10 minutes Lewis draft-farinacci-lisp-multicast-01.txt 15 minutes Farinacci =20 Unassigned Work Items -------------------- Lewis 10 minutes - Securing the LISP Mapping System - Preliminary Analysis Potential New WG Items ---------------------- draft-iannone-lisp-mapping-versioning-00.txt 15 minutes Iannone Next Steps 10 minutes ---------- Lewis/All --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1WzkACgkQORgD1qCZ2KciJwCfV86+gvR3n00fyB96JmQZXkV1 mW0AnjXTaT+lDXPozQXYpRAJ5lqLo+TU =42gJ -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From dmm@1-4-5.net Mon Mar 9 13:26:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513D93A6BE2 for ; Mon, 9 Mar 2009 13:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDE8YzhODnk7 for ; Mon, 9 Mar 2009 13:26:42 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 4CA723A69A8 for ; Mon, 9 Mar 2009 13:26:42 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n29KRGnK028354 for ; Mon, 9 Mar 2009 13:27:16 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n29KRGrv028353 for lisp@ietf.org; Mon, 9 Mar 2009 13:27:16 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 9 Mar 2009 13:27:16 -0700 From: David Meyer To: lisp@ietf.org Message-ID: <20090309202716.GA28330@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [lisp] working LISP WG charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 20:26:43 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As edited by Jari. Questions/comments to the list. Thanks, Dave --- LISP (Locator/ID Separation Protocol) Last Modified: 2009-03-05 Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Secretary: TBD Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation" (frequently referred to as Loc/ID split). The basic idea behind the Loc/ID split that the Internet architecture combines two functions, Routing Locators, or RLOCs (where you are attached to the network) and Endpoint Identifiers, or EIDs (who you are) in one number space: The IP address. Proponents of the Loc/ID split postulate that splitting these functions apart with yield several advantages, including improved scalability for the routing system. The Loc/ID split aims to decouple location and identity, thus allowing for efficient aggregation of the RLOC space and providing persistent identity in the EID space. The LISP protocol is an instantiation of the separation of Internet address space into Endpoint Identifiers and Routing Locators designed by means of a network-based map-and-encap scheme. A number of other instantiations of the same general concept are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are generally NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the EID-to-RLOC mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to be able to develop concrete protocol specifications and build equipment that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the design on the LISP base protocol [1], the LISP+ALT mapping system [2], LISP Interworking [4], LISP Map Server [8], and LISP multicast [6] for these purposes, with the given references a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its documents are Experimental and labeled with the suitable disclaimers about their limitations and not fully understood implications for Internet traffic. Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG for Experimental. Mar 2010 Submit base ALT specification to the IESG for Experimental. Mar 2010 Submit the LISP Interworking specification to the IESG for Experimental. June 2010 Submit the LISP Map Server specification to the IESG for Experimental. June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG for Experimental. Jul 2010 Submit LISP for Multicast Environments to the IESG for Experimental. Jul 2010 Submit a preliminary analysis of how the LISP protocols (LISP base protocol, LISP+ALT mapping system, and LISP multicast) address the Design Goals for Scalable Internet Routing [7]. Aug 2010 Re-charter or close. Internet-Drafts: draft-farinacci-lisp-12.txt draft-farinacci-lisp-multicast-01.txt draft-fuller-lisp-alt-05.txt draft-fuller-lisp-ms-00.txt draft-lewis-lisp-interworking-02.txt Request For Comments: None References ---------- [1] Farinacci, D. et. al., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-12.txt.=20 [2] Fuller, V., et. al., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-05.txt=20 [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-01.txt.=20 [4] Lewis, D., et. al., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-02.txt.=20 [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt. =09 [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt. =20 [7] T. Li, Ed., "Design Goals for Scalable Internet Routing", draft-irtf-rrg-design-goals-01, IRTF, July 2007.=20 [8] Farinacci, D. and V. Fuller, "LISP Map Server", draft-fuller-lisp-ms-00.txt.=20 --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1e6QACgkQORgD1qCZ2KfPbACfZYyHloZbpfbn9qCDUqdP/4mY HvUAn3zLQWxT7B45T7n7VFe0iNgOJ20b =hhvm -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From swb@employees.org Mon Mar 9 14:18:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8733A6CAD for ; Mon, 9 Mar 2009 14:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.294 X-Spam-Level: X-Spam-Status: No, score=-6.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HU0AafKm+pw for ; Mon, 9 Mar 2009 14:18:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5D6E43A6C5B for ; Mon, 9 Mar 2009 14:18:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,331,1233532800"; d="scan'208";a="153132255" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2009 21:18:39 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n29LIdbs001398; Mon, 9 Mar 2009 17:18:39 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n29LIdoB025635; Mon, 9 Mar 2009 21:18:39 GMT Date: Mon, 9 Mar 2009 17:18:30 -0400 From: Scott Brim To: David Meyer Message-ID: <20090309211829.GO37980@cisco.com> Mail-Followup-To: Scott Brim , David Meyer , lisp@ietf.org References: <20090309202716.GA28330@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MAH+hnPXVZWQ5cD/" Content-Disposition: inline In-Reply-To: <20090309202716.GA28330@1-4-5.net> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: lisp@ietf.org Subject: Re: [lisp] working LISP WG charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:18:25 -0000 --MAH+hnPXVZWQ5cD/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Excerpts from David Meyer on Mon, Mar 09, 2009 01:27:16PM -0700: > The basic idea behind the Loc/ID split that the Internet > architecture combines two functions, Routing Locators, or RLOCs > (where you are attached to the network) and Endpoint Identifiers, > or EIDs (who you are) in one number space: The IP > address. Proponents of the Loc/ID split postulate that splitting > these functions apart with yield several advantages, including > improved scalability for the routing system. The Loc/ID split > aims to decouple location and identity, thus allowing for s/identity/identifier/ ... "identity" brings in other baggage. > efficient aggregation of the RLOC space and providing persistent > identity in the EID space. identification=20 > However, despite these issues it would be valuable to be able to > develop concrete protocol specifications and build equipment that > can be used to understand the characteristics of these > designs. The LISP WG is chartered to work on the design on the design of --MAH+hnPXVZWQ5cD/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkm1h6UACgkQF0TR2hENFARevACg+kGRj0pxEy5nk0Cu9JjfflDM LCkAnRb3l2762HeF0Vz7p/CF9+aKyGsk =TtCV -----END PGP SIGNATURE----- --MAH+hnPXVZWQ5cD/-- From dmm@1-4-5.net Mon Mar 9 14:31:48 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A833A69DE for ; Mon, 9 Mar 2009 14:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i6gza1n3TpB for ; Mon, 9 Mar 2009 14:31:47 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id D9E7F3A6C74 for ; Mon, 9 Mar 2009 14:31:42 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n29LWGqA031249; Mon, 9 Mar 2009 14:32:16 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n29LWG6q031248; Mon, 9 Mar 2009 14:32:16 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 9 Mar 2009 14:32:16 -0700 From: David Meyer To: Scott Brim , lisp@ietf.org Message-ID: <20090309213216.GA31213@1-4-5.net> References: <20090309202716.GA28330@1-4-5.net> <20090309211829.GO37980@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <20090309211829.GO37980@cisco.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [lisp] working LISP WG charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:31:48 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 09, 2009 at 05:18:30PM -0400, Scott Brim wrote: > Excerpts from David Meyer on Mon, Mar 09, 2009 01:27:16PM -0700: > > The basic idea behind the Loc/ID split that the Internet > > architecture combines two functions, Routing Locators, or RLOCs > > (where you are attached to the network) and Endpoint Identifiers, > > or EIDs (who you are) in one number space: The IP > > address. Proponents of the Loc/ID split postulate that splitting > > these functions apart with yield several advantages, including > > improved scalability for the routing system. The Loc/ID split > > aims to decouple location and identity, thus allowing for >=20 > s/identity/identifier/ ... "identity" brings in other baggage. >=20 > > efficient aggregation of the RLOC space and providing persistent > > identity in the EID space. >=20 > identification=20 >=20 > > However, despite these issues it would be valuable to be able to > > develop concrete protocol specifications and build equipment that > > can be used to understand the characteristics of these > > designs. The LISP WG is chartered to work on the design on the >=20 > design of >=20 Fixed, thnx. Dave --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1iuAACgkQORgD1qCZ2KeVYACeOzPPNX2apEkvbzVI5Vxl9pnv xGQAn3AmYwscS5rFWmr3IToKHQh+pik6 =+WGr -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From dmm@1-4-5.net Mon Mar 9 15:00:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10BB73A6BC6 for ; Mon, 9 Mar 2009 15:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OD-ZZtZ2yDl for ; Mon, 9 Mar 2009 15:00:51 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 2D3133A6CB3 for ; Mon, 9 Mar 2009 15:00:51 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n29M1JDl032716; Mon, 9 Mar 2009 15:01:19 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n29M1J1J032715; Mon, 9 Mar 2009 15:01:19 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 9 Mar 2009 15:01:19 -0700 From: David Meyer To: jari.arkko@piuha.net Message-ID: <20090309220118.GA32626@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: lisp@ietf.org Subject: [lisp] Jari, can you handle this one (LISP BOF v. WG, and the published IETF agenda) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 22:00:52 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jari, As Dimitri correctly points out, there is confusion over the WG vs. BOF status of the LISP slot in SF. The IETF agenda (https://datatracker.ietf.org/meeting/74/agenda.html) says Continental 4 INT lisp Locator/ID Separation Protocol BOF=20 Thnx, Dave =20 ----- Forwarded message from PAPADIMITRIOU Dimitri ----- > From: PAPADIMITRIOU Dimitri > To: David Meyer > Subject: RE: [lisp] Updated [Draft LISP WG agenda for IETF 74] > Date: Mon, 9 Mar 2009 22:35:07 +0100 >=20 > Dave: on the IETF agenda for IETF74, LISP is mentioned as a BoF here as > a WG. So, it would be good to clarify the actual situation because I do > not think anyone outside inner circles is able to follow progress. >=20 > Thanks, > -dimtri.=20 --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1ka4ACgkQORgD1qCZ2KcDMACcD+jCfMpchPcuU4FmNxxUmuaJ q5IAn0n736FEnXrgIbmORAs100W4J1OL =/rqS -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From dmm@1-4-5.net Mon Mar 9 20:17:18 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1B33A6988; Mon, 9 Mar 2009 20:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfqntHmneOW7; Mon, 9 Mar 2009 20:17:17 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 8C85A3A6961; Mon, 9 Mar 2009 20:17:17 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n2A3HnFe006562; Mon, 9 Mar 2009 20:17:49 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n2A3Hn0B006561; Mon, 9 Mar 2009 20:17:49 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 9 Mar 2009 20:17:49 -0700 From: David Meyer To: Robin Whittle Message-ID: <20090310031749.GA6501@1-4-5.net> References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <49B4D641.9090803@firstpr.com.au> <20090309152859.GB16770@1-4-5.net> <49B5D8AB.3000104@firstpr.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <49B5D8AB.3000104@firstpr.com.au> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: RRG , lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 03:17:18 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 10, 2009 at 02:04:11PM +1100, Robin Whittle wrote: > Hi Dave, >=20 > I have replied to part of your message in another thread on LISP-ALT > scaling. "Level 1" means an ALT router at the lowest level of the > highly aggregated inverted tree ALT hierarchy. >=20 > You wrote, in part: >=20 > >> How can an ALT router, such as this busy level 1 > >> aggregation router, detect the failure or > >> unreachability of a Map-Server? I guess it would > >> find out when it tries to send a Map-Request message > >> to the Map-Server via the GRE tunnel. But is there > >> a keepalive arrangement so the level 1 router could > >> detect the disappearance of this Map-Server before > >> it sends a Map-Request? > >> > >> More on potential problems with caching Map-Resolvers. > >=20 > >=20 > > Regarding "upness": You can make the same argument for > > BGP peers in the DFZ (or DNS if you like). In the case of > > BGP, we use BGP keepalives, BFD (if you like), and the > > existence of the route in the RIB/FIB as basically a > > bunch of heuristics, which work pretty well (when was the > > last time you couldn't get to Google because of a routing > > problem on the Internet?). Hence we don't need to > > calculate some exact value of "upness" (which is a good thing). > >=20 > > BTW, the question "is entity X up" really reduces to > > Zeno's paradox (think: what is the granularity of > > "upness", and how often do I need to ask?). And we know > > what it took to solve Zeno's paradox. But as mentioned > > above, we can do a fine job (within our engineering > > constraints) with clever heuristics. The operational > > Internet is pretty much an existence proof of that. >=20 > Your answer is pretty general and doesn't seem to apply to the > specific situation of the Map-Server and ETR. You didn't ask a question. I was just noting that the question as to whether or not something is "up" is not well formed. Dave =09 --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkm1290ACgkQORgD1qCZ2KccOACdGnD9Bnt398C+m1JnEQrjm/PY HbUAnjK0WwfUuX71Cs9+EBzdwXOF7H4c =Jlbr -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From rw@firstpr.com.au Mon Mar 9 20:31:50 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F094A3A6B29 for ; Mon, 9 Mar 2009 20:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHhovdqpSJd4 for ; Mon, 9 Mar 2009 20:31:50 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 144AB3A6A90 for ; Mon, 9 Mar 2009 20:31:50 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 9EBA5175E0E; Tue, 10 Mar 2009 14:32:23 +1100 (EST) Message-ID: <49B5DED0.7010108@firstpr.com.au> Date: Tue, 10 Mar 2009 14:30:24 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: RRG References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <49B4D641.9090803@firstpr.com.au> <20090309152859.GB16770@1-4-5.net> <49B5D8AB.3000104@firstpr.com.au> <20090310031749.GA6501@1-4-5.net> In-Reply-To: <20090310031749.GA6501@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 03:31:51 -0000 Hi Dave, You wrote: > You didn't ask a question. I was just noting that the > question as to whether or not something is "up" is not > well formed. I did ask a question: >>>> How can an ALT router, such as this busy level 1 >>>> aggregation router, detect the failure or >>>> unreachability of a Map-Server? I guess it would >>>> find out when it tries to send a Map-Request message >>>> to the Map-Server via the GRE tunnel. But is there >>>> a keepalive arrangement so the level 1 router could >>>> detect the disappearance of this Map-Server before >>>> it sends a Map-Request? My question relates to how an ALT router can detect a Map-Server (also an ALT Router, I assume) being "down". You answered this, in part, with your mention of BGP keep-alives in the GRE tunnel between the two devices. I also intended to ask more clearly the same question about how a Map-Server can detect when an ETR is "down". In both cases, "down" means not "up" enough to justify the upstream device continuing to advertise the downstream device's EID on the ALT network. My previous message addressed difficulties I perceive with the Map-Server detecting an ETR being down. I won't repeat that, but there is no GRE tunnel, no TCP-BGP session and so far no protocol for the Map-Server sensing the "down"ness of an ETR and making decisions about when to stop advertising that ETR's EID(s). - Robin From rw@firstpr.com.au Mon Mar 9 21:07:07 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0753A6C84 for ; Mon, 9 Mar 2009 21:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXHCewdCvQGD for ; Mon, 9 Mar 2009 21:07:06 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 3954F3A6405 for ; Mon, 9 Mar 2009 21:07:06 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 8A608175C55; Tue, 10 Mar 2009 14:06:10 +1100 (EST) Message-ID: <49B5D8AB.3000104@firstpr.com.au> Date: Tue, 10 Mar 2009 14:04:11 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: RRG References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <49B4D641.9090803@firstpr.com.au> <20090309152859.GB16770@1-4-5.net> In-Reply-To: <20090309152859.GB16770@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 04:07:07 -0000 Hi Dave, I have replied to part of your message in another thread on LISP-ALT scaling. "Level 1" means an ALT router at the lowest level of the highly aggregated inverted tree ALT hierarchy. You wrote, in part: >> How can an ALT router, such as this busy level 1 >> aggregation router, detect the failure or >> unreachability of a Map-Server? I guess it would >> find out when it tries to send a Map-Request message >> to the Map-Server via the GRE tunnel. But is there >> a keepalive arrangement so the level 1 router could >> detect the disappearance of this Map-Server before >> it sends a Map-Request? >> >> More on potential problems with caching Map-Resolvers. > > > Regarding "upness": You can make the same argument for > BGP peers in the DFZ (or DNS if you like). In the case of > BGP, we use BGP keepalives, BFD (if you like), and the > existence of the route in the RIB/FIB as basically a > bunch of heuristics, which work pretty well (when was the > last time you couldn't get to Google because of a routing > problem on the Internet?). Hence we don't need to > calculate some exact value of "upness" (which is a good thing). > > BTW, the question "is entity X up" really reduces to > Zeno's paradox (think: what is the granularity of > "upness", and how often do I need to ask?). And we know > what it took to solve Zeno's paradox. But as mentioned > above, we can do a fine job (within our engineering > constraints) with clever heuristics. The operational > Internet is pretty much an existence proof of that. Your answer is pretty general and doesn't seem to apply to the specific situation of the Map-Server and ETR. Can you be more specific about how you would handle this? I understand that routers with physical connections can often use the physical layer to detect a failure of the link - and perhaps the failure of the router at the other end of the link. A Map-Server is just a host with some IP address which has made an arrangement with an ETR on some other IP address to send it Map-Requests. Leaving aside the lack of acknowledgement in the current Map-Register protocol, how does the Map-Server detect that the ETR is dead? The Map-Request packets are UDP and require no acknowledgement. The replies don't come back through the Map-Server, so it can't tell whether the ETR is alive or not. As far as I can see, you will need some kind of protocol to ensure the Map-Server can quickly and easily detect a failed or unreachable ETR. Then, I think it needs to withdraw the advertisement of that ETR's EIDs into the ALT BGP, according to some LISP-specified or locally determined algorithm about how long the outage has been so far. - Robin From tony.li@tony.li Mon Mar 9 21:36:57 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C5E28C11C for ; Mon, 9 Mar 2009 21:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvtqbuIb0e3K for ; Mon, 9 Mar 2009 21:36:56 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 818F128C111 for ; Mon, 9 Mar 2009 21:36:56 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id R8Wa1b02h1GXsucA1GcS2r; Tue, 10 Mar 2009 04:36:26 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id RGcV1b00E3L8a8Q8TGcWrL; Tue, 10 Mar 2009 04:36:31 +0000 Message-ID: <49B5EE29.5060608@tony.li> Date: Mon, 09 Mar 2009 21:35:53 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: rrg@irtf.org, lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Please, no more crossposting... X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 04:36:57 -0000 Hi folks, Now that we have a LISP WG, could we please stop cross posting to the RRG mailing list? Folks who are interested in both can easily subscribe to both... Thanks, Tony From dino@cisco.com Mon Mar 9 22:57:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D163A6A0A for ; Mon, 9 Mar 2009 22:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV-HbcP5qdEn for ; Mon, 9 Mar 2009 22:57:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D2C5D3A6A37 for ; Mon, 9 Mar 2009 22:57:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,334,1233532800"; d="scan'208";a="264441808" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Mar 2009 05:58:03 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2A5w3Io012393; Mon, 9 Mar 2009 22:58:03 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2A5w3xZ017485; Tue, 10 Mar 2009 05:58:03 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 22:58:03 -0700 Received: from [192.168.1.5] ([10.21.122.184]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 22:58:03 -0700 Message-Id: From: Dino Farinacci To: Robin Whittle In-Reply-To: <49B5DF43.7090401@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 22:58:03 -0700 References: <49B5DF43.7090401@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 10 Mar 2009 05:58:03.0124 (UTC) FILETIME=[2CAED340:01C9A145] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=783; t=1236664683; x=1237528683; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20LISP-NERD-Map-Resolver=20~=3D=2 0APT=20&=20Ivip |Sender:=20; bh=snICcIsqPrMqHeq9PH26oMTTQcKf3hweoxQedAz/5gc=; b=HUQ+3+rJ4h1srTEUSryUWW4I+LEpJlHtsw+97nSCBYfjvCVHRFHx1Joxfk +6E/LS5MwRa/zKaLxQDaaesyJGy0NxvwgvMRVCr6HhZC6m356EIaNSyVvxlP h8Vsg0ZfoN; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] [rrg] LISP-NERD-Map-Resolver ~= APT & Ivip X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 05:57:29 -0000 Changing to lisp@ietf.org list. > Perhaps the LISP team is contemplating using NERD full push mapping > distribution to Map-Resolvers, instead of ALT or CONS. > > LISP Map Server (and Map-Resolvers) 2009-03-03 > http://tools.ietf.org/html/draft-fuller-lisp-ms-00 > > http://www.ietf.org/mail-archive/web/rrg/current/msg04575.html > > Dino wrote: "... a Map-Resolver can be a LISP-ALT > router/system, a NERD system, or a > CONS/DHT system." No, we are not contemplating. We are just saying that we *can* use any database mapping system. We still think the most robust, proven, and one with decent management tools is LISP-ALT. And the fact you can use off-the-shelf routers is a huge plus as well. Dino From pfrejborg@gmail.com Tue Mar 10 01:03:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287AF3A6C42 for ; Tue, 10 Mar 2009 01:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.736 X-Spam-Level: X-Spam-Status: No, score=0.736 tagged_above=-999 required=5 tests=[AWL=-3.253, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaHJhOoCX1IW for ; Tue, 10 Mar 2009 01:03:24 -0700 (PDT) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id B6A383A6963 for ; Tue, 10 Mar 2009 01:03:23 -0700 (PDT) Received: by fxm24 with SMTP id 24so1520220fxm.37 for ; Tue, 10 Mar 2009 01:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Heh9oHXjSP6BqPg1X/wu8TCdefa8+sV+Y0yOBQr8kik=; b=wsCZHLQ4LWFGN3q/iKo4cxtr3Irmf3Grf0ul4dynr4wjwDbf6dKp4M4kaDVPMfvbTm mfma/YMNPL6/nCdJN/Tg7/Q3ZuBSoG5SpDzEsSbV6EYaVbOHOHN+mpHFTT3aWI824hDI yYYQ/6DyRRHwoV55vCNaNYKqd3YWYbVI+F2ks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MpIuRHgJLHWR+eqHu1KKncEUQ55p590QphRVorW91QRykoNgVDGl21i59sbjLgvKc4 JK7ReKG4JYC5IEN4XU+38Buq0unyhGsAcqRHyxLWdGC/PHzshLmMQWE49VIXrJpSRoac zntGPSFEOnJ4fFInQzgo2cfn5TC2Wezser8N4= MIME-Version: 1.0 Received: by 10.86.82.16 with SMTP id f16mr4769701fgb.26.1236672237741; Tue, 10 Mar 2009 01:03:57 -0700 (PDT) In-Reply-To: <20090309150852.GA16770@1-4-5.net> References: <49AEBC00.9070306@firstpr.com.au> <673472F6-3BEB-4DD0-A1F6-66AA9E90EE41@cisco.com> <5bc37fd40903060207p1d2dbe10u8dbe80412d9b3979@mail.gmail.com> <20090306162441.GA25825@1-4-5.net> <5bc37fd40903061159q62464ca2y478f212a5342fa8b@mail.gmail.com> <20090309150852.GA16770@1-4-5.net> Date: Tue, 10 Mar 2009 10:03:57 +0200 Message-ID: <5bc37fd40903100103i7676047aq8c714075c90fb732@mail.gmail.com> From: Patrick Frejborg To: David Meyer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: RRG , lisp@ietf.org Subject: Re: [lisp] [rrg] LISP Map Server I-D & updated draft-farinacci-lisp - 2 stages of caching mapping X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 08:03:25 -0000 Hi Dave, as per request, I suggest we continue on the lisp-list, if further discussions are needed. Comments inline On Mon, Mar 9, 2009 at 5:08 PM, David Meyer wrote: > =A0 =A0 =A0 =A0Right now, right? Since its a BRAS I'm assuming what's > =A0 =A0 =A0 =A0behind it is dynamically addressed (and readdressed at > =A0 =A0 =A0 =A0some regular interval). Right? If so, then the things > =A0 =A0 =A0 =A0behind the BRAS might someday be (naturally) renumber > =A0 =A0 =A0 =A0into some EID space, the the BRAS could play xTR (and > =A0 =A0 =A0 =A0hence have a few RLOCs). > > =A0 =A0 =A0 =A0Or do you see it differently? Not much but little. When you design the B-RAS you usually reserve as much IP-addresses as needed for the residential users but after a while this goes broken when a connection that needs static IP-addresses for, e.g. IPsec connectivity - usually a SME subscribing for a xDSL line. This can be avoided if you have separate residential and enterprise B-RAS but guess this is not common. So you are right, after a while there will be more prefixes on the B-RAS. But most of them are PA addresses and aggregated further up in the network. And having ITR/ETR on the B-RAS might break the aggregate - this is a design and not a technology issue. . > >> And to the ALT network you just advertise on prefix, the /23 and not >> the individual RLOC host prefixes. This becomes a sort of super >> aggregate, the AS or an area is shown behind one /23 RLOC prefix. > > =A0 =A0 =A0 =A0You lost me (you don't advertise RLOCs into the ALT). > >> LISP-ALT will be the global directory, which IP prefix is connected to >> which RLOC identifier for time being and this directory will grow but >> it is disconnected from the forwarding plane so the FIB doesn't need >> to be upgraded - only in the AS that grows too big. But that is then >> up to the service provider, split the AS to two AS or buy new hardware >> - the ISP have a choice. > > =A0 =A0 =A0 =A0Again, I think we're mangling a few things here. There > =A0 =A0 =A0 =A0are no RLOCs in the ALT. I was lost here until Dino's reply yesterday. I now understand that there are no RLOCs in the ALT network, it is like a SIP architecture where you (might) have a separate path to setup the session and the RTP streams take another path. Or the old Ipsilon solution where the routers (in LISP, the ALT) were bypassed and a flow was created through the ATM network (in LISP, the current Internet). But LISP + ALT scales better since no signaling and path reservation is needed in the core, only on the affected edges. I hope I got it right now, please correct me if I'm wrong. > >> One question for you, how are you going to deal with portsweep on the IT= R? >> I have seen ISP using NAT on the B-RAS (along time ago), an end user >> could easily saturate the NAT table so that all customer behind that >> B-RAS lost connectivity. > > =A0 =A0 =A0 =A0What is portsweep? Do you mean scanning? If so, yeah, its > =A0 =A0 =A0 =A0a problem for everyone on the big bad Internet. I think port scanning is when you are trying to find a back door on a certain host, portsweep is when you are scanning for a certain port on multiple hosts. So the portsweep traffic will end up on the ALT network. Then, as with Ipsilon solution, how to deal with the housekeeping of the cache? If a lot of cache entries are created by portsweep is there a risk that the cache entries are exhausted due to portsweep and what then? In the 90s route-cache was replaced by CEF and stabilized the backbone routers - now putting a route-cache solution back in the network gets me uncomfortable. Don't get me wrong here, this is not against LISP - I'm curious if the technology have improved that much that a cache solution could be used closer to the core. There is a reason why I'm asking this, see below. > >> I think we should design LISP and LISP-ALT so that later on the >> functionality can be taken to the hosts, both options are needed so >> that the enterprise and service providers do have a choice. > > =A0 =A0 =A0 =A0I couldn't follow that. Can you try to rephrase it? > =A0 =A0 =A0 =A0Thnx. Forget the previous, this was when I thought that the ALT and MS contains both RLOC and EID information - and this is not the case. If there would have been RLOC information in the MS I would have been keen to get "hands-on" that solution. Why? My proposal requires upgrades to the hosts and being realistic, every host on the Internet will not be upgraded within e.g. two years (backend hosts doesn't need to be upgraded either) so there will be an interim phase where a hIPv4 proxy is needed in front of the legacy hosts. Only way to do this is to apply DNS spoofing and to have a cache in the proxy. This is doable in enterprise environments, you have to install the hIPv4 proxy between the clients and the DNS server. That is, the proxy is on the very edge of the network and if portsweep exhaust the cache it is only the enterprise that suffers, nobody else. But when you have to implement a hIPv4 proxy for residential users the most logical place is to install it on the B-RAS, then it will be located between the clients and the DNS server so DNS spoofing and caching can be applied. Another place would be the DSLAM that should apply/remove the LISP header to the IP header and creating the hIPv4 header in Layer 2 mode. Scales better but a lot of hardware needs to be upgraded... And then we have the 1000$ question, how to deal with the cache housekeeping?? Can a portsweep exhaust the cache and will end users loose connectivity due to portsweep or bad cache housekeeping? That's the reason why I dropped the proxy solution from my draft at this moment and headed for the hosts instead, the network is kept free from cache solutions - have seen enough problems with route-cache and NAT caches in the forwarding plane, the closer to the core the more vulnerable the caches become. But has the technology improved?? -- patte From tony.li@tony.li Tue Mar 10 21:15:11 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF893A68A8 for ; Tue, 10 Mar 2009 21:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8G5U56161dei for ; Tue, 10 Mar 2009 21:15:10 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 50EFF3A68CB for ; Tue, 10 Mar 2009 21:15:10 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id RZ051b0020S2fkCA5gFn4P; Wed, 11 Mar 2009 04:15:47 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id RgFk1b00K3L8a8Q8VgFlJ6; Wed, 11 Mar 2009 04:15:46 +0000 Message-ID: <49B6968E.6090302@tony.li> Date: Tue, 10 Mar 2009 09:34:22 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Scott Brim , Tony Li , rrg@irtf.org, lisp@ietf.org References: <49B5EE29.5060608@tony.li> <20090310123339.GE90404@cisco.com> In-Reply-To: <20090310123339.GE90404@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Please, no more crossposting... X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 04:15:11 -0000 Scott Brim wrote: > Excerpts from Tony Li on Mon, Mar 09, 2009 09:35:53PM -0700: >> Hi folks, >> >> Now that we have a LISP WG, could we please stop cross posting to the >> RRG mailing list? >> >> Folks who are interested in both can easily subscribe to both... > > Some issues are exemplified by LISP but may impact other approaches > and are still open to research-like discussion. I would like to be > able to discuss those on RRG. Some overlap is unavoidable. > If it's that important, then a separate thread seems eminently reasonable. Tony From jari.arkko@piuha.net Fri Mar 13 06:21:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C77528C0DF for ; Fri, 13 Mar 2009 06:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loUi11we4Z4K for ; Fri, 13 Mar 2009 06:21:50 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AD7403A6892 for ; Fri, 13 Mar 2009 06:21:49 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id BE230198723; Fri, 13 Mar 2009 15:22:25 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 54010198671; Fri, 13 Mar 2009 15:22:25 +0200 (EET) Message-ID: <49BA5DF7.3070802@piuha.net> Date: Fri, 13 Mar 2009 15:21:59 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [lisp] LISP, San Francisco, and WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 13:21:58 -0000 All, After considering the input from the various lists, IESG, IAB, etc, I have decided that the best course of action with regards to LISP is to create a tightly scoped WG. The scoping relates to truth in advertising about the readiness of the technology for wide deployment and how the results of the WG will be used. The specifications coming out of the WG will be Experimental RFCs. Please see the charter text below; comments appreciated. And I see that we've already received feedback from Margaret, thanks for that. The group is expected to work on one specific solution, converting that solution to something else is not within the plan. The RRG obviously needs to continue their work with a number of other solutions and analysis of the design space. I plan to keep the door open for other proposals as well (some could argue that 6AI is another solution; that might become a WG too in San Francisco). I don't think anyone believes that either LISP or the other solutions from RRG are ready for prime time; there are significant remaining problems even at the conceptual and incentive levels, let alone protocol bits. But before we get to a final solution, it is very useful to test various designs, to understand their implications. A formal call for IETF-wide comments on the proposed working group and charter will be made in the next few days. You can send input on this list or say something at the meeting. The final approval will happen after San Francisco. At the end of the day we will decide this based on the community feedback, but my expectation is that there is support for letting the LISP folks work on their design in the IETF. Sam Hartman and Darrel Lewis have agreed to chair the group -- thank you! Please talk to the chairs about agenda; we are obviously doing this quite late before the meeting, so a lot of preparation has to happen in a short amount of time. Other than the opportunity for feedback on the WG creation and the charter, I think we should run the meeting as if it were a WG meeting. Jari -------- LISP (Locator/ID Separation Protocol) Last Modified: 2009-03-12 21:01:40 Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Mailing Lists: General Discussion: https://www.ietf.org/mailman/listinfo/lisp Description of Working Group: The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation". The basic idea behind the separation that the Internet architecture combines two functions, Routing Locators, or RLOCs (where you are attached to the network) and Endpoint Identifiers, or EIDs (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple location and identity, thus allowing for efficient aggregation of the RLOC space and providing persistent identity in the EID space. LISP supports the separation of the Internet address space into Endpoint Identifiers and Routing Locators following a network-based map-and-encap scheme (RFC 1955). It employs EIDs that represent a mixture of locators and identifiers; it could also be classified as a multi-level locator scheme. A number of other approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the EID-to-RLOC mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications). Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG as Experimental Mar 2010 Submit base ALT specification to the IESG as Experimental Mar 2010 Submit the LISP Interworking specification to the IESG as Experimental June 2010 Submit the LISP Map Server specification to the IESG as Experimental June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 Submit a preliminary analysis as Informational Dec 2010 Re-charter or close. From hartmans@mit.edu Fri Mar 13 08:13:41 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29E528C12E for ; Fri, 13 Mar 2009 08:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0unk82nQMC9 for ; Fri, 13 Mar 2009 08:13:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 02F8A3A6991 for ; Fri, 13 Mar 2009 08:13:34 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D3BB64244; Fri, 13 Mar 2009 11:13:48 -0400 (EDT) From: Sam Hartman To: lisp@ietf.org Date: Fri, 13 Mar 2009 11:13:48 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] A brief introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 15:13:41 -0000 Hi, folks. I'm looking forward to working with all of you. I haven't been that visible in the internet area so I'd like to briefly introduce myself. I'm a software consultant, mostly working on infrastructure software, although one of my current clients is looking at IPV6 security issues. Up until last year, I was at MIT as the chief technologist for the MIT Kerberos Consortium. (I'm still using an MIT email address for IETF issues.) I've been participating in the IETF since 1998. Most of my work has been in the security space. I was on the IESG for three years as a security AD. In that role, I had the pleasure of working with a lot of folks from the internet area, reviewing specifications. I've been very interested in the ID/locator split problem since I became aware of it. I've been following (although not actively participating) HIP, SHIM6, MULTI6, and some of the public IAB discussions on the issues including the ID/LOC BOF. I'm a strong advocate of a fair process. I want to make sure everyone gets heard and understood; we're not done until we've understood the positions of stakeholders who want to work with us and have come to an informed rough consensus. I can be strongly spoken, but I'm not afraid to change my mind. I do come from a security background. One of my jobs as chair will be to make sure we accurately describe the security implications of LISP. While I'd be delighted if we find ways of making LISP's security better, that cannot come at the expense of completing our work. Documenting the security properties of LISP, on the other hand, is not optional. Also, security is only "better" if it is balanced against security; a great security system that no one uses is worse than a balanced security tradeoff that provides reasonable security and improves productivity. I look forward to working with all of you! From hartmans@mit.edu Fri Mar 13 08:16:23 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE0E3A6B69 for ; Fri, 13 Mar 2009 08:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw0wN7naPXQu for ; Fri, 13 Mar 2009 08:16:17 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 35FC03A6B3B for ; Fri, 13 Mar 2009 08:16:17 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3485E4244; Fri, 13 Mar 2009 11:16:35 -0400 (EDT) From: Sam Hartman To: lisp@ietf.org Date: Fri, 13 Mar 2009 11:16:35 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: mrw@lilacglade.org Subject: [lisp] Architectural concerns about the nature of LISP identifiers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 15:16:23 -0000 --=-=-= The chairs have recieved comments from Margaret Wasserman and from at least one IAB member regarding a lack of clarity about the architecture of LISP in the charter. Margaret's posting is held in moderation; I don't yet have access to approve it so I'm forwarding. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Thu, 12 Mar 2009 20:08:16 -0400 X-Sieve: CMU Sieve 2.2 Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suchdamage.org (Postfix) with ESMTP id 492BC20205 for ; Thu, 12 Mar 2009 20:08:10 -0400 (EDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n2D082sm027452 for ; Thu, 12 Mar 2009 19:08:02 -0500 (EST) Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n2D07tE0029210 for ; Thu, 12 Mar 2009 20:07:55 -0400 (EDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 6F4CCEA94A8 for ; Thu, 12 Mar 2009 20:07:50 -0400 (EDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mit.edu with ESMTP id U0TyDjeEV6CrFyxI for ; Thu, 12 Mar 2009 20:07:50 -0400 (EDT) X-Barracuda-Envelope-From: mrw@lilacglade.org Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id SMyk1b0090FhH24AEQ7rYf; Fri, 13 Mar 2009 00:07:51 +0000 Received: from [10.36.0.45] ([76.119.58.152]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id SQ7k1b00D3H3vh08UQ7pct; Fri, 13 Mar 2009 00:07:50 +0000 Message-Id: <71A89A4C-D86A-4E66-B237-237545F65346@lilacglade.org> From: Margaret Wasserman To: Sam Hartman Subject: Fwd: [ipdir] LISP WG Date: Thu, 12 Mar 2009 20:07:42 -0400 References: <1368441D-65C6-40E6-82FA-964E193C826B@lilacglade.org> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Mar 12 20:08:16 2009 X-DSPAM-Confidence: 0.9987 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,49b9a3f096711324614094 X-DSPAM-Factors: 27, From*Margaret Wasserman , 0.00010, From*, 0.00018, Subject*WG, 0.00024, To*Sam+Hartman, 0.00026, To*Hartman++On, 0.00084, References*lilacglade.org>, 0.00094, wrote+>>, 0.00108, >+>>, 0.00126, >+>>, 0.00126, and+>>, 0.00126, >>+The, 0.00151, >>+The, 0.00151, X-Spam-Score*0.00, 0.00160, >+To, 0.00188, >+Subject, 0.00188, >+this, 0.00188, >+From, 0.00188, can+>>, 0.00188, >+It, 0.00251, other+>>, 0.00251, in+>>, 0.00251, locator, 0.00251 MIME-Version: 1.0 Well, I tried to send it to LISP, but it is being held for moderator approval. I guess I'm not subscribed. Margaret Begin forwarded message: > From: Margaret Wasserman > Date: March 12, 2009 8:01:46 PM EDT > To: Jari Arkko > Cc: IESG IESG , ipdir@ietf.org, lisp@ietf.org > Subject: Re: [ipdir] LISP WG > > > Hi Jari, > > I have some significant concerns about some of the wording in the > LISP charter (and in the LISP drafts), which I will try to explain > here... > > Please note that I am not arguing against creation of this WG or > against publication of the mechanisms described in the LISP > drafts. Specifically, I am concerned about the accuracy of calling > this mechanism an ID/Locator split mechanism and/or conflating the > concept of IDs (in the ID/Loc sense) with the LISP concept of an > EID, as EIDs serve as both a topological locator and an identifier. > > This input is meant to be constructive and not simply pedantic/ > argumentative. I am concerned that our lack of accuracy in the > terminology we are using to discuss this mechanism may reflect a > lack of clairy in how we are thinking about this technology, and a > lack of understanding of what benefits it could provide. In > particular, we may be attributing architectural merit, or even > operational benefits, to this technology that it doesn't actually > provide, because it does not actually separate IDs and Locators > within the edge network. As just one small example, if we had a > true ID/Loc split mechanism, a host could maintain a constant ID as > it moved throughout the network, somehow updating the ID/locator > mapping as it moved. However, that is not a property of LISP EIDs. > > On Mar 5, 2009, at 10:53 AM, Jari Arkko wrote: >> LISP (Locator/ID Separation Protocol) > > I think that the name of the group is somewhat inaccurate, because > the LISP specification (as currently written) does not describe a > complete ID/Locator split mechanism. >> >> The IAB's October 2006 workshop on Routing and Addressing Workshop >> (RFC 4984) rekindled interest in scalable routing and addressing >> architectures for the Internet. Among the many issues driving this >> renewed interest are concerns about the scalability of the routing >> system and the impending exhaustion of the IPv4 address space. Since >> the IAB workshop, several proposals have emerged which attempt to >> address the concerns expressed there and elsewhere. In general, these >> proposals are based on the "Locator/Identifier >> separation" (frequently >> referred to as Loc/ID split). > > I would not personally put this historical information in the > charter unless there are specific documents from the IAB workshop > that you want WG members to read. Citing this meeting without > giving a pointer to any minutes, notes or output is just an appeal > to authority. >> >> The basic idea behind the Loc/ID split that the Internet architecture >> combines two functions, Routing Locators, or RLOCs (where you are >> attached to the network) and Endpoint Identifiers, or EIDs (who you >> are) in one number space: The IP address. > > This part of the second paragraph conflates the ideal concept behind > ID/Locator split with the LISP terminology (RLOC and EID) in a way > that isn't quite accurate. While the classic "Locator" is analogous > to a LISP RLOC, a LISP EID is not a pure identifier, as it is also > used as a topological locator within the edge network. > > It is also stylistically awkward that the introduction of the RLOC > and EID terms comes before LISP has been introduced. > >> Proponents of the Loc/ID >> split postulate that splitting these functions apart with yield >> several advantages, including improved scalability for the routing >> system. > > Proponents ... postulate? I'd remove this sentence unless you can > cite a reference or something. > >> The Loc/ID split aims to decouple location and identity, thus >> allowing for efficient aggregation of the RLOC space and providing >> persistent identity in the EID space. > > Again, the charter is conflating the ID/Loc separation concept with > EIDs and RLOCs. >> >> >> The LISP protocol is an instantiation of the separation of Internet >> address space into Endpoint Identifiers and Routing Locators designed >> by means of a network-based map-and-encap scheme. > > While it is clear that LISP separates the Internet address space > into RLOCs and EIDs, I think this sentence is trying to say that > LISP is performing an ID/Locator split, which it isn't completely. > LISP is really a tiered-routing mechanism that uses pure locators at > the center (RLOCs) that are de-aggregated/transposed at a defined > threshold into ID/Locators for use in the edge network (EIDs). > > I don't think that "map-and-encaps" is a universally well-understood > term. It should be defined here, or a reference should be cited. > >> A number of other >> instantiations of the same general concept are being looked at in >> parallel in the IRTF and IETF. At this time, these proposals are at >> an early stage. All proposals (including LISP) have potentially >> harmful side-effects to Internet traffic carried by the involved >> routers, have parts where deployment incentives may be lacking, and >> are generally NOT RECOMMENDED for deployment beyond experimental >> situations at this stage. Many of the proposals have components (such >> as the EID-to-RLOC mapping system) where it is not yet known what >> kind >> of design alternative is the best one among many. >> >> However, despite these issues it would be valuable to be able to >> develop concrete protocol specifications and build equipment that can >> be used to understand the characteristics of these designs. The LISP >> WG is chartered to work on the design on the LISP base protocol [1], > > Typo: s/design on/design of > > The rest of the charter from this point forward looks fine to me. > > Margaret --=-=-=-- From mrw@lilacglade.org Thu Mar 12 17:01:13 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A813A6BD8 for ; Thu, 12 Mar 2009 17:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPHikZ8cQ+9Y for ; Thu, 12 Mar 2009 17:01:12 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 817973A6B2F for ; Thu, 12 Mar 2009 17:01:12 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id SHgb1b00617UAYkA2Q1r3E; Fri, 13 Mar 2009 00:01:51 +0000 Received: from [10.36.0.45] ([76.119.58.152]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id SQ1n1b00c3H3vh08ZQ1pf1; Fri, 13 Mar 2009 00:01:50 +0000 Message-Id: <1368441D-65C6-40E6-82FA-964E193C826B@lilacglade.org> From: Margaret Wasserman To: Jari Arkko In-Reply-To: <49AFF574.6090805@piuha.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Mar 2009 20:01:46 -0400 References: <49AFF574.6090805@piuha.net> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Fri, 13 Mar 2009 09:01:13 -0700 Cc: ipdir@ietf.org, IESG IESG , lisp@ietf.org Subject: Re: [lisp] [ipdir] LISP WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 00:01:13 -0000 Hi Jari, I have some significant concerns about some of the wording in the LISP charter (and in the LISP drafts), which I will try to explain here... Please note that I am not arguing against creation of this WG or against publication of the mechanisms described in the LISP drafts. Specifically, I am concerned about the accuracy of calling this mechanism an ID/Locator split mechanism and/or conflating the concept of IDs (in the ID/Loc sense) with the LISP concept of an EID, as EIDs serve as both a topological locator and an identifier. This input is meant to be constructive and not simply pedantic/ argumentative. I am concerned that our lack of accuracy in the terminology we are using to discuss this mechanism may reflect a lack of clairy in how we are thinking about this technology, and a lack of understanding of what benefits it could provide. In particular, we may be attributing architectural merit, or even operational benefits, to this technology that it doesn't actually provide, because it does not actually separate IDs and Locators within the edge network. As just one small example, if we had a true ID/Loc split mechanism, a host could maintain a constant ID as it moved throughout the network, somehow updating the ID/locator mapping as it moved. However, that is not a property of LISP EIDs. On Mar 5, 2009, at 10:53 AM, Jari Arkko wrote: > LISP (Locator/ID Separation Protocol) I think that the name of the group is somewhat inaccurate, because the LISP specification (as currently written) does not describe a complete ID/Locator split mechanism. > > The IAB's October 2006 workshop on Routing and Addressing Workshop > (RFC 4984) rekindled interest in scalable routing and addressing > architectures for the Internet. Among the many issues driving this > renewed interest are concerns about the scalability of the routing > system and the impending exhaustion of the IPv4 address space. Since > the IAB workshop, several proposals have emerged which attempt to > address the concerns expressed there and elsewhere. In general, these > proposals are based on the "Locator/Identifier separation" (frequently > referred to as Loc/ID split). I would not personally put this historical information in the charter unless there are specific documents from the IAB workshop that you want WG members to read. Citing this meeting without giving a pointer to any minutes, notes or output is just an appeal to authority. > > The basic idea behind the Loc/ID split that the Internet architecture > combines two functions, Routing Locators, or RLOCs (where you are > attached to the network) and Endpoint Identifiers, or EIDs (who you > are) in one number space: The IP address. This part of the second paragraph conflates the ideal concept behind ID/Locator split with the LISP terminology (RLOC and EID) in a way that isn't quite accurate. While the classic "Locator" is analogous to a LISP RLOC, a LISP EID is not a pure identifier, as it is also used as a topological locator within the edge network. It is also stylistically awkward that the introduction of the RLOC and EID terms comes before LISP has been introduced. > Proponents of the Loc/ID > split postulate that splitting these functions apart with yield > several advantages, including improved scalability for the routing > system. Proponents ... postulate? I'd remove this sentence unless you can cite a reference or something. > The Loc/ID split aims to decouple location and identity, thus > allowing for efficient aggregation of the RLOC space and providing > persistent identity in the EID space. Again, the charter is conflating the ID/Loc separation concept with EIDs and RLOCs. > > > The LISP protocol is an instantiation of the separation of Internet > address space into Endpoint Identifiers and Routing Locators designed > by means of a network-based map-and-encap scheme. While it is clear that LISP separates the Internet address space into RLOCs and EIDs, I think this sentence is trying to say that LISP is performing an ID/Locator split, which it isn't completely. LISP is really a tiered-routing mechanism that uses pure locators at the center (RLOCs) that are de-aggregated/transposed at a defined threshold into ID/Locators for use in the edge network (EIDs). I don't think that "map-and-encaps" is a universally well-understood term. It should be defined here, or a reference should be cited. > A number of other > instantiations of the same general concept are being looked at in > parallel in the IRTF and IETF. At this time, these proposals are at > an early stage. All proposals (including LISP) have potentially > harmful side-effects to Internet traffic carried by the involved > routers, have parts where deployment incentives may be lacking, and > are generally NOT RECOMMENDED for deployment beyond experimental > situations at this stage. Many of the proposals have components (such > as the EID-to-RLOC mapping system) where it is not yet known what kind > of design alternative is the best one among many. > > However, despite these issues it would be valuable to be able to > develop concrete protocol specifications and build equipment that can > be used to understand the characteristics of these designs. The LISP > WG is chartered to work on the design on the LISP base protocol [1], Typo: s/design on/design of The rest of the charter from this point forward looks fine to me. Margaret From Fred.L.Templin@boeing.com Fri Mar 13 09:18:24 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B7B3A687F; Fri, 13 Mar 2009 09:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.01 X-Spam-Level: X-Spam-Status: No, score=-6.01 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fp+vnAa4ZyX; Fri, 13 Mar 2009 09:18:23 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id BFFA23A65A5; Fri, 13 Mar 2009 09:18:23 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2DGIlKO001323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Mar 2009 11:18:47 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2DGIknV009246; Fri, 13 Mar 2009 11:18:47 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2DGIfYQ008968; Fri, 13 Mar 2009 11:18:46 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Mar 2009 09:18:43 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 13 Mar 2009 09:18:42 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105B0AB7D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <1368441D-65C6-40E6-82FA-964E193C826B@lilacglade.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] [ipdir] LISP WG Thread-Index: Acmj9V5DKfoTHtPwTEWkotwVAPgs/QAAHOeQ References: <49AFF574.6090805@piuha.net> <1368441D-65C6-40E6-82FA-964E193C826B@lilacglade.org> From: "Templin, Fred L" To: "Margaret Wasserman" , "Jari Arkko" X-OriginalArrivalTime: 13 Mar 2009 16:18:43.0864 (UTC) FILETIME=[61220980:01C9A3F7] Cc: ipdir@ietf.org, IESG IESG , lisp@ietf.org Subject: Re: [lisp] [ipdir] LISP WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:18:24 -0000 Margaret, =20 > Please note that I am not arguing against creation of this WG or =20 > against publication of the mechanisms described in the LISP drafts. > Specifically, I am concerned about the accuracy of calling this =20 > mechanism an ID/Locator split mechanism and/or conflating the concept > of IDs (in the ID/Loc sense) with the LISP concept of an EID, as EIDs > serve as both a topological locator and an identifier. I agree, and this is a point that I have raised several times also. A *true* endpoint identifier would not be routable within any scope, whereas the LISP EID is routable within the scope of an edge network (i.e., even if that scope is only node-local). Conversely, HIP provides an example of a true endpoint identifier. An EID *does* identify an endpoint's interface, however. Therefore, I believe a more accurate expansion of the term is Endpoint *Interface* iDentifier (EID). Fred fred.l.templin@boeing.com From hartmans@mit.edu Fri Mar 13 09:47:28 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE5428C207; Fri, 13 Mar 2009 09:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7w6lvxg9RIO; Fri, 13 Mar 2009 09:47:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 2310828C1E2; Fri, 13 Mar 2009 09:47:28 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 145424245; Fri, 13 Mar 2009 12:47:41 -0400 (EDT) From: Sam Hartman To: "Templin, Fred L" References: <49AFF574.6090805@piuha.net> <1368441D-65C6-40E6-82FA-964E193C826B@lilacglade.org> <39C363776A4E8C4A94691D2BD9D1C9A105B0AB7D@XCH-NW-7V2.nw.nos.boeing.com> Date: Fri, 13 Mar 2009 12:47:41 -0400 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105B0AB7D@XCH-NW-7V2.nw.nos.boeing.com> (Fred L. Templin's message of "Fri, 13 Mar 2009 09:18:42 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Margaret Wasserman , ipdir@ietf.org, IESG IESG , lisp@ietf.org Subject: Re: [lisp] [ipdir] LISP WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:47:29 -0000 Folks, it's my understanding that we have stumbled onto a long-running terminology discussion within the RRG. I submit that we'll make faster progress if we focus on what we want to convey, second on how to say it, and only when all other options are exausted trying to get people to change terminology they have been using for a while. So, I'd like to ask people to refocus their discussion around what we want to convey. I'm hearing multiple people who want the charter to do a better job of conveying what LISP identifiers are and of conveying what separation is actually achieved. From jnc@mercury.lcs.mit.edu Fri Mar 13 10:35:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7544C3A6AD6 for ; Fri, 13 Mar 2009 10:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4a4UFWDfGw70 for ; Fri, 13 Mar 2009 10:35:44 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id B9D553A6909 for ; Fri, 13 Mar 2009 10:35:44 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6975B6BE60B; Fri, 13 Mar 2009 13:36:22 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090313173622.6975B6BE60B@mercury.lcs.mit.edu> Date: Fri, 13 Mar 2009 13:36:22 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [ipdir] LISP WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 17:35:45 -0000 > From: "Templin, Fred L" > An EID *does* identify an endpoint's interface, however. Therefore, I > believe a more accurate expansion of the term is Endpoint *Interface* > iDentifier (EID). When you say "An EID", you mean a LISP EID, right? Since there are 'LISP EIDs' and 'Classic EIDs' (sorry, couldn't resist :-), we need to be careful with use of the term 'EID', lest more confusion reign. I think I personally will start using the acronym LEID in the future, to be very explicit. (It's only one more keystrokem, and to me seems well worth the work to make confusion on this point impossible.) After thinking about it briefly, I guess an LEID does _currently_ name an interface, not a stack - especially in an un-modified host. I say "_currently_" because I can also see a future in which i) the LISP 'boundary' is the first-hop router everywhere, and the LEID no longer holds any location semantics, and ii) _some_ hosts have therefore been modified so that they have only a single IPv4 'address', which explicitly names the stack. (Remember that in my mind LISP is not just what is in the current documents, but also a long-term development path of which the current stuff is only step 1 of about 5 - or more.) Although maybe that's not such a good idea... I think you want to be able to name specific interfaces. Although now that I think about it briefly, it would be cleaner/more correct to do that in a new 'locator' namespace (step 2 or 3 of the aforementioned 5 or so). Noel From Fred.L.Templin@boeing.com Fri Mar 13 11:00:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769593A6978 for ; Fri, 13 Mar 2009 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.094 X-Spam-Level: X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PzQjpJF7sNR for ; Fri, 13 Mar 2009 11:00:05 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id B38F13A6855 for ; Fri, 13 Mar 2009 11:00:05 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2DI0Sp1011247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Mar 2009 11:00:33 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2DI0S5H006672; Fri, 13 Mar 2009 11:00:28 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2DI0R6B006641; Fri, 13 Mar 2009 11:00:28 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Mar 2009 11:00:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2009 11:00:24 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105B0AC71@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090313173622.6975B6BE60B@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] [ipdir] LISP WG Thread-Index: AcmkAkV05JhWJ1C8S1SEOppqhqGNfAAAIpPg References: <20090313173622.6975B6BE60B@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 13 Mar 2009 18:00:25.0730 (UTC) FILETIME=[9620E620:01C9A405] Subject: Re: [lisp] [ipdir] LISP WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 18:00:06 -0000 Noel, > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Friday, March 13, 2009 10:36 AM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [lisp] [ipdir] LISP WG >=20 >=20 > > From: "Templin, Fred L" >=20 > > An EID *does* identify an endpoint's interface, however. Therefore, I > > believe a more accurate expansion of the term is Endpoint *Interface* > > iDentifier (EID). >=20 > When you say "An EID", you mean a LISP EID, right? >=20 > Since there are 'LISP EIDs' and 'Classic EIDs' (sorry, couldn't resist :-), > we need to be careful with use of the term 'EID', lest more confusion reign. > I think I personally will start using the acronym LEID in the future, to be > very explicit. (It's only one more keystrokem, and to me seems well worth the > work to make confusion on this point impossible.) >=20 > After thinking about it briefly, I guess an LEID does _currently_ name an > interface, not a stack - especially in an un-modified host. Agree for an unmodified host. > I say "_currently_" because I can also see a future in which i) the LISP > 'boundary' is the first-hop router everywhere, and the LEID no longer holds > any location semantics, and ii) _some_ hosts have therefore been modified so > that they have only a single IPv4 'address', which explicitly names the stack. > (Remember that in my mind LISP is not just what is in the current documents, > but also a long-term development path of which the current stuff is only step > 1 of about 5 - or more.) IP addresses (of which the LISP EID is an example) name interfaces. If you assign a LISP EID to a loopback interface of an xTR, then in some sense it also names the stack. But, the address still has location semantics of a sort (maybe call it node-local scope) and it only names one of the xTR's stacks, which may in fact have many. Fred fred.l.templin@boeing.com > Although maybe that's not such a good idea... I think you want to be able to > name specific interfaces. Although now that I think about it briefly, it would > be cleaner/more correct to do that in a new 'locator' namespace (step 2 or 3 > of the aforementioned 5 or so). >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From swb@employees.org Fri Mar 13 11:00:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08CEF3A6B0C; Fri, 13 Mar 2009 11:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGTy0VdAyKuU; Fri, 13 Mar 2009 11:00:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5BB993A6AF9; Fri, 13 Mar 2009 11:00:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,358,1233532800"; d="scan'208";a="155515526" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 13 Mar 2009 18:00:53 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2DI0qqP026466; Fri, 13 Mar 2009 11:00:52 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2DI0TrO004567; Fri, 13 Mar 2009 18:00:52 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 14:00:51 -0400 Received: from cisco.com ([10.86.242.151]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 14:00:50 -0400 Date: Fri, 13 Mar 2009 14:00:45 -0400 From: Scott Brim To: "Templin, Fred L" Message-ID: <20090313180045.GR50052@cisco.com> Mail-Followup-To: Scott Brim , "Templin, Fred L" , Margaret Wasserman , Jari Arkko , ipdir@ietf.org, IESG IESG , lisp@ietf.org References: <49AFF574.6090805@piuha.net> <1368441D-65C6-40E6-82FA-964E193C826B@lilacglade.org> <39C363776A4E8C4A94691D2BD9D1C9A105B0AB7D@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105B0AB7D@XCH-NW-7V2.nw.nos.boeing.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 13 Mar 2009 18:00:50.0324 (UTC) FILETIME=[A4C9A540:01C9A405] Authentication-Results: sj-dkim-3; header.From=swb@employees.org; dkim=neutral Cc: Margaret Wasserman , ipdir@ietf.org, IESG IESG , lisp@ietf.org Subject: Re: [lisp] [ipdir] LISP WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 18:00:15 -0000 Excerpts from Templin, Fred L on Fri, Mar 13, 2009 09:18:42AM -0700: > A *true* endpoint identifier would not be routable within any scope This isn't LISP-specific but the key attribute of an identifier is that it is not dependent on topological connection. Routing/forwarding functions can use anything they want, anywhere, as long as that's true. Scott From jnc@mercury.lcs.mit.edu Fri Mar 13 11:11:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137683A687E; Fri, 13 Mar 2009 11:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXucldWE0O-U; Fri, 13 Mar 2009 11:11:44 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 274E83A6878; Fri, 13 Mar 2009 11:11:43 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 06F906BE60D; Fri, 13 Mar 2009 14:12:21 -0400 (EDT) To: iesg@ietf.org, ipdir@ietf.org, lisp@ietf.org Message-Id: <20090313181222.06F906BE60D@mercury.lcs.mit.edu> Date: Fri, 13 Mar 2009 14:12:21 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [ipdir] LISP WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 18:11:45 -0000 > From: Margaret Wasserman > I am concerned about the accuracy of calling this mechanism an > ID/Locator split mechanism Well, if it is not intended to separate location and identity, what's the point of creating a mapping database, to maintain maps from one namespace to another? And two of the capabilities it explicitly provides/supports are provider independence and multi-homing - two things for which separation of location and identity are generally held to be fairly crucial. If one has to pick one _short_ phrase to describe the goals and point of LISP, it is indeed 'separate location and identity'. Only when one gets to a longer description does one have the room to add the complex caveats of 'not complete separation _in the initial stages_, because initially LISP EIDs still retain some location semantics, and also name interfaces as opposed to stacks'. Yes, it is not absolute separation of location and identity (at least in the short term), but that is because LISP made the strategic choice to support _unmodified hosts and site-local routers_ - and since conflation between the two concepts is deeply embedded into the code in those classes of devices, it's therefore inevitable that one won't get a perfect split (at least, in the short term). I do think it's a good idea to carefully point out those limitations clearly, and fairly early on in any writing about LISP, but at the same time, what other _short_ description of the goals and mechanism of LISP is appropriate? > it does not actually separate IDs and Locators within the edge network. Not initially, no (and it would be good to say so clearly). However, as the boundary between the mapped/un-mapped portion of the network gets closer to the host, the location semantics leaches out of the LISP EID, and when the boundary reaches the host's first-hop router, it's entirely gone. Getting rid of the interface naming semantics will be harder - that can't really be done without host changes. However, it is a possible long-term evolutionary step. > As just one small example, if we had a true ID/Loc split mechanism, a > host could maintain a constant ID as it moved throughout the network, > somehow updating the ID/locator mapping as it moved. However, that is > not a property of LISP EIDs. If things get to the point where LISP mapping happens at all first-hop routers within domains (as posited above), this capability would in fact be available _without any host changes_ (assuming, as you point out, that the mapping could somehow be updated), or indeed _without any changes to LISP itself_. I would therefore argue that to the extent such movement _anywhere_ is not possible (because some domains haven't converted internally), then that limitation is in fact a deployment issue, and not an _architectural_ limitation of LISP itself. Noel From wwwrun@core3.amsl.com Tue Mar 17 17:30:00 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 264213A6A6C; Tue, 17 Mar 2009 17:29:59 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090318003000.264213A6A6C@core3.amsl.com> Date: Tue, 17 Mar 2009 17:30:00 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@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: Wed, 18 Mar 2009 00:30:00 -0000 A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, March 24, 2009. Locator/ID Separation Protocol (lisp) -------------------------------------------------- Last Modified: 2009-03-12 Current status: Proposed Working Group Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Mailing Lists: General Discussion: https://www.ietf.org/mailman/listinfo/lisp Description of Working Group: The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation". The basic idea behind the separation that the Internet architecture combines two functions, Routing Locators, or RLOCs (where you are attached to the network) and Endpoint Identifiers, or EIDs (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple location and identity, thus allowing for efficient aggregation of the RLOC space and providing persistent identity in the EID space. LISP supports the separation of the Internet address space into Endpoint Identifiers and Routing Locators following a network-based map-and-encap scheme (RFC 1955). It employs EIDs that represent a mixture of locators and identifiers; it could also be classified as a multi-level locator scheme. A number of other approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the EID-to-RLOC mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications). Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG as Experimental Mar 2010 Submit base ALT specification to the IESG as Experimental Mar 2010 Submit the LISP Interworking specification to the IESG as Experimental June 2010 Submit the LISP Map Server specification to the IESG as Experimental June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 Submit a preliminary analysis as Informational Dec 2010 Re-charter or close. From rw@firstpr.com.au Tue Mar 17 17:55:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0E23A6822; Tue, 17 Mar 2009 17:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6eeDBUb50gw; Tue, 17 Mar 2009 17:55:36 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 5C63D3A681D; Tue, 17 Mar 2009 17:55:35 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 31D76175BA2; Wed, 18 Mar 2009 11:56:18 +1100 (EST) Message-ID: <49C0472F.9060304@firstpr.com.au> Date: Wed, 18 Mar 2009 11:58:23 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lisp@ietf.org References: <20090313181222.06F906BE60D@mercury.lcs.mit.edu> In-Reply-To: <20090313181222.06F906BE60D@mercury.lcs.mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: ipdir@ietf.org, Noel Chiappa , iesg@ietf.org Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 00:55:37 -0000 (I am replying to Noel's "Re: [lisp] [ipdir] LISP WG" message.) Short version: Neither LISP nor any of the other core-edge separation approaches to the routing and addressing scaling problem involve separate namespaces for "locators" and "identifiers". The nature of the "split" is operational. While the proposed LISP charter does not mention namespaces, there is a danger that without clarification, the erroneous notion of separate namespaces in LISP etc. will be propagated. This is especially the case since several LISP-ALT documents explicitly claim that there are separate namespaces. I raised this critique in March 2008 and still people are mentioning separate namespaces for EIDs and RLOCs as if this is an accepted truth. Noel wrote, in part: >> From: Margaret Wasserman > >> I am concerned about the accuracy of calling this mechanism an >> ID/Locator split mechanism > > Well, if it is not intended to separate location and identity, what's the > point of creating a mapping database, to maintain maps from one namespace to > another? In LISP, RLOC addresses and EID addresses are not in separate namespaces. Assuming IPv4 for the discussion, both RLOC and EID addresses are within the 32 bit IPv4 namespace. I am unable to find an authoritative definition of the term "namespace" but these strike me as pretty good: http://en.wiktionary.org/wiki/namespace (computing) A conceptual space that groups classes, identifiers, etc. to avoid conflicts with items in unrelated code that have the same names. http://en.wikipedia.org/wiki/Namespace ... an abstract container providing context for the items (names, or technical terms, or words) it holds and allowing disambiguation of items having the same name (residing in different namespaces). ... The "split" referred to in LISP's name involves classifying some IPv4 addresses into "EID" addresses and others (the remainder?) into "RLOC" addresses. I think this is fine, but I agree with the critique that other approaches, such as HIP, have a stronger claim to being a system which truly splits Locator and Identifier addresses. LISP's "split" is an operational matter. An ITR will recognise some addresses as being RLOCs and others as EIDs. (Ordinary routers or hosts need make no such distinctions.) EIDs and RLOCs are still within the single IPv4 namespace. Arguably, a true split would be a conceptual one - which HIP certainly does - into two separate namespaces for RLOC and EID addresses. In principle, it would be possible for both RLOC and EID addresses to be in separate namespaces while both being 32 bit integers. However, then each such address would need to come with sufficient context for the device to know which namespace to interpret these bits within. If IPv4 LISP really had separate namespaces for EID and RLOC, then the number 1.2.3.4 would mean one thing in the EID namespace and another in the RLOC namespace. It is probably too late to change LISP's name. However, I think there should be a truth in labelling notice in all LISP documents that the "split" referred to is an operational matter within the IPvN namespace, and not the creation of two separate namespaces. Furthermore, I think it would be good to note that HIP and I guess other proposals really do split addressing into two separate namespaces for identifier and locator. Below my signature are some links to prominent items which appear when searching for: LISP split EID RLOC namespace These include some I-Ds and other material from the LISP-ALT team which erroneously state that LISP involves two separate namespaces. - Robin http://www.firstpr.com.au/ip/ivip/ http://www.google.com/search?hl=en&as_q=LISP+split+EID+RLOC+namespace LISP documents referring to 2 namespaces ---------------------------------------- http://tools.ietf.org/html/draft-farinacci-lisp-12 Another approach is to have the ITR not encapsulate a multicast packet and allow the the host built packet to flow into the core even if the source address is allocated out of the EID namespace. http://tools.ietf.org/html/draft-lewis-lisp-interworking-02 EID Sub Namespace: A power-of-two block of aggregatable locators set aside for LISP interworking. PTRs (Proxy Tunnel Routers) attract traffic by announcing the LISP EID namespace into parts of the non-LISP-speaking global routing system. http://www.isoc.org/tools/blogs/ietfjournal/?p=158 http://www.isoc.org/tools/blogs/ietfjournal/wp-content/uploads/2007/10/IETFJournal0302.pdf IETF Journal Vol 3 Issue 2 2007-10 David Meyer Most of the existing routing and addressing proposals leverage the one or more levels of indirection inherent in the ID/Locator separation idea to create one or more new namespaces. In most cases, two namespaces are utilised. One namespace-the End-point Identifiers (or EIDs)-is used to address hosts. The other space, known as Routing Locators (or RLOCs), is used for packet routing across a transit domain. http://www.nanog.org/mtg-0710/presentations/LISP-cons.pdf What is LISP? * Locator/ID Separation Protocol (LISP) – draft-farinacci-lisp-03.txt * Creates two namespaces: IDs and Locators ... Mailing list message from LISP-ALT team referring to 2 namespaces ------------------------------------------------------------------- http://www.ietf.org/mail-archive/web/rrg/current/msg01293.html Dino: Well an EID/RLOC split adds one new namespace to address systems out of. That gives you more addresses on the order of the total addressable address space of the namespace's address family (IPv4 or IPv6). You could iterate to build multiple levels of hierarchy. Just like people have done with multi-level NAT. Critiques of the notion that LISP provides separate namespaces -------------------------------------------------------------- None of the three core-edge separation techniques which are documented in I-Ds provide separate namespaces for "locators" and "identifiers": http://www.lisp4.net http://tools.ietf.org/html/draft-jen-apt-01 http://www.firstpr.com.au/ip/ivip/ This question of namespaces has been discussed before, including: http://www.ops.ietf.org/lists/rrg/2008/msg00797.html RW 2008-03-16 Hi Tony (Li), You wrote, in part: > We've also accepted as axiomatic that we would like to separate > this functionality into two independent namespaces. I want to > stress here that for the architectural result to be in any way > clean, independence is mandatory. Any linkage whatsoever would > be a clearly suboptimal result. ... I don't think any of the map-encap approaches - LISP, APT, Ivip or TRRP - involves the creation of a completely independent namespace. I can't imagine any incrementally deployable solution which would. (Tony's response strikes me as quite abstract and doesn't really tackle the critique that for LISP etc. these are not separate namespaces: http://www.ops.ietf.org/lists/rrg/2008/msg00817.html) http://www.ops.ietf.org/lists/rrg/2008/msg00829.html RW 2008-03-18 [On "jack-down" models - independent namespaces] http://www.ops.ietf.org/lists/rrg/2008/msg01637.html RW 2008-06-27 [Not separate namespaces: Loc-ID-separation, map-encap etc.] From jnc@mercury.lcs.mit.edu Tue Mar 17 19:44:11 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433393A67BD; Tue, 17 Mar 2009 19:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km5PutVku+me; Tue, 17 Mar 2009 19:44:10 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 6D4193A6783; Tue, 17 Mar 2009 19:44:10 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DD3CA6BE556; Tue, 17 Mar 2009 22:44:49 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> Date: Tue, 17 Mar 2009 22:44:49 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 02:44:11 -0000 > From: Robin Whittle > The "split" referred to in LISP's name involves classifying some IPv4 > addresses into "EID" addresses and others (the remainder?) into "RLOC" > addresses. > ... > EIDs and RLOCs are still within the single IPv4 namespace. If you look at the LISP Map-Reply packet format, you'll notice a field called "Loc-AFI". (The documentation doesn't really talk about it.) Ever notice that field, and wonder what it was there for? Any guesses as to why it is there? To repeat yet again something I said a while back in email to the LISP list, to many of the people working on LISP, LISP is not just what is in the current documents, but also a long-term development path of which the current stuff is only step 1 of about 5 - or more. Many of the current documents contain small 'hooks' intended to be used (or necessary) at some of these later stages - such as the one I just pointed out above. No, it's not all written down; neither was all of TCP/IP, when we started that, either. With limited time/energy, don't expect documents that describe things that won't be used for years to get written now. Also, deploying a new namespace can be a major job of work, _especially_ if it needs to be a _structured_ namespace, which is what a new locator namespace would need to be. (Unique identifiers picked singly and probabilistically out of a large identifier range are a whole different, and much simpler, kettle of fish.) Try planning all the pieces you'd need to be able to deploy a new locator namespace - starting with agreement on the politics of how they'd be allocated. (Note that politics has just driven the allocation of IPv6 PI addresses - a completely non-sensensical decision from the routing engineering point of view.) For the initial stages of deployment, deploying a new namespace is just a major, and unnecessary, distraction. As the old joke goes, how do you get down off an elephant? Noel From dino@cisco.com Tue Mar 17 20:59:34 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03A493A69B8 for ; Tue, 17 Mar 2009 20:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oDljNYClEnB for ; Tue, 17 Mar 2009 20:59:33 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 445E83A6AA6 for ; Tue, 17 Mar 2009 20:59:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,382,1233532800"; d="scan'208";a="143719032" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 18 Mar 2009 04:00:17 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2I40H9j029896; Tue, 17 Mar 2009 21:00:17 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2I40HqM025120; Wed, 18 Mar 2009 04:00:17 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 21:00:17 -0700 Received: from [192.168.1.5] ([10.21.95.110]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 21:00:16 -0700 Message-Id: From: Dino Farinacci To: Noel Chiappa In-Reply-To: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Mar 2009 21:00:15 -0700 References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 18 Mar 2009 04:00:16.0536 (UTC) FILETIME=[0BF91180:01C9A77E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1031; t=1237348817; x=1238212817; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[ipdir]=20LISP=20WG=3A=20Loc/I D=20separation=20-=20not=20separate=20namespaces |Sender:=20; bh=oPqgTHqg+lBmI615uHGQsxV71n7MSs8E5w/UAsfNC5o=; b=XoEdamoATiqaSb7kzrD+YHc0PG1CCISC4S8E8s5NAnt8I4cr0wlkK8SF/8 9BY+bq33N/3Qiea6rsJTx33g4YJJ96sBgEgT7FMlT2paMXR2vSHeUs9yUuh5 5IrC5uAvzS; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 03:59:34 -0000 > If you look at the LISP Map-Reply packet format, you'll notice a > field called > "Loc-AFI". (The documentation doesn't really talk about it.) Ever > notice that > field, and wonder what it was there for? Any guesses as to why it is > there? Noel, the Loc-AFI is describe during the 'Locator' description is made: Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR or router acting as a proxy replier for the EID-prefix. Note that the destination RLOC address MAY be an anycast address. A source RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router), and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID. Dino From lars.eggert@nokia.com Tue Mar 17 21:30:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5F33A6B34; Tue, 17 Mar 2009 21:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTQUIc0Fr-Q6; Tue, 17 Mar 2009 21:30:09 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id E3EE13A6800; Tue, 17 Mar 2009 21:30:08 -0700 (PDT) Received: from 12-187-233-228.att-inc.com (12-187-233-228.att-inc.com [12.187.233.228] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n2I4Uhsb039430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Mar 2009 06:30:45 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <75F61228-332B-4303-974A-19C0309A8826@nokia.com> From: Lars Eggert To: Brian E Carpenter In-Reply-To: <49C0569C.1080702@gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-91--802077964; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Mar 2009 21:30:43 -0700 References: <20090318003000.264213A6A6C@core3.amsl.com> <49C0569C.1080702@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Wed, 18 Mar 2009 06:30:47 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9126/Wed Mar 18 01:07:14 2009 on fit.nokia.com X-Virus-Status: Clean Cc: "iesg@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 04:30:10 -0000 --Apple-Mail-91--802077964 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2009-3-17, at 19:04, Brian E Carpenter wrote: > Probably for the last time, I want to object to LISP's basic > terminology. The entity that LISP calls an EID is in fact a > locator; it's simply a locator of limited routeability. > > I believe it should be called a LLOC (local locator), with > consequent changes to the charter text. I realise that this > would spoil a neat acronym, but the risk in the current > terminology is that people will be confused for ever. Let's call it an "iddress" :-) Lars --Apple-Mail-91--802077964 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTAzMTgwNDMwNDNaMCMGCSqGSIb3DQEJBDEWBBS5sWP2WepWiT/M GgwV9+txouzVbzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAP/4pCQCZwur40vHnPI0+I0qyQq2FWzvePc7N8JlOJoM+xu5hUo6V z4YWpdAeqFJc6giXvOpxQw9EyiAyOwFSdv57mzxmgZKZnFMuauZFA3LeWGrfpHHkeNYw5WC1E0vc lkdNxHaImMZPJo1+7/Z4Q20EcsYmYOLa8nQ983hewuElwlxA9zuT1m+DFV0uNVEncTnV6fC4cbYE uZuEeFbocAzDY5wMrRJ7hHXINUiBNRYm9iXT0Mn1aTbX331oc08K9oWBY09mNQrNcPLU101gRkx/ EpsXC0LSTIwS9NEX2LuHq60kWKNdceJ0IV0DDAx4Te7fnfhdyIvT2+Bqac+WfwAAAAAAAA== --Apple-Mail-91--802077964-- From jnc@mercury.lcs.mit.edu Tue Mar 17 22:13:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2E63A6B45; Tue, 17 Mar 2009 22:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5Y7AwhLX8C3; Tue, 17 Mar 2009 22:13:25 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 95A3D3A6847; Tue, 17 Mar 2009 22:13:25 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 271326BE55C; Wed, 18 Mar 2009 01:14:08 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090318051408.271326BE55C@mercury.lcs.mit.edu> Date: Wed, 18 Mar 2009 01:14:08 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 05:13:26 -0000 > On 2009-3-17, at 19:04, Brian E Carpenter wrote: > The entity that LISP calls an EID is in fact a locator; it's simply a > locator of limited routeability. Calling it a "locator" is even 'wronger' than calling it an EID, alas. If the mapping-encapsulation takes place at the first-hop router (which I expect to be an eventual evolutionary step), _at the internetworking level_ the properties of the LISP EID are extremely similar to an IEEE Interface ID, which nobody would call a locator. All they both do is identify (in a globally unique way) an interface. It certainly would have no more inherent location information in it than an IEEE IID does. And that doesn't even touch on the possibility that the interface naming functionality would _also_ be leached out of the LISP EID, leaving it as purely a location-less identifier for a stack (which is, exactly, an EID...) Please see my previous length message to the RRG list (sigh, too many lists): http://www.irtf.org/mail-archive/web/rrg/current/msg04612.html which discusses at more length the issue of the changing semantics of the LISP EID over time, and in particular how the 'location' functionality is incrementally leached out of it. > I believe it should be called a LLOC (local locator), with > consequent changes to the charter text. ... the risk in the current > terminology is that people will be confused for ever. I don't know why the original LISP team decided to call it an EID. (I wasn't involved in the project at that point.) The problem now with changing it is that, as a LISP term, it has been used for a long time now, and I'm not sure it's really plausible to change it. (People will keep saying 'LISP EID', I suspect.) But if it is changed, it needs to be an _entirely new term_, since _any_ existing term is at best an inexact fit to the particular, detailed (and probably not constant over time) semantics of the LISP EID. Noel From lear@cisco.com Wed Mar 18 03:46:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118953A6929 for ; Wed, 18 Mar 2009 03:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.049 X-Spam-Level: X-Spam-Status: No, score=-8.049 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kD8P0aPgSGPR for ; Wed, 18 Mar 2009 03:46:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2A5C83A67FD for ; Wed, 18 Mar 2009 03:46:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,383,1233532800"; d="scan'208";a="157524694" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-1.cisco.com with ESMTP; 18 Mar 2009 10:47:22 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2IAlMYK027378 for ; Wed, 18 Mar 2009 11:47:22 +0100 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp6791.cisco.com [10.61.90.134]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2IAlMEI002550 for ; Wed, 18 Mar 2009 10:47:22 GMT Message-ID: <49C0D139.8000108@cisco.com> Date: Wed, 18 Mar 2009 11:47:21 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090316 Shredder/3.0b3pre MIME-Version: 1.0 To: lisp@ietf.org References: <20090318051408.271326BE55C@mercury.lcs.mit.edu> In-Reply-To: <20090318051408.271326BE55C@mercury.lcs.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=296; t=1237373242; x=1238237242; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[lisp]=20WG=20Review=3A=20Locator/ID=20 Separation=20Protocol=20(lisp) |Sender:=20; bh=LT61oiVDmwp3V0+FphBf1SXJBLWGvYr6cccxXotzhT8=; b=P9nSKNBfPdPuKmgn9kwGcnieRihugzoviR/q1Ry5k/Q1NmSSUUqxcl88/f NPbAOsD1ihl1KCTB9szAjwLi9F9BYF5xLltKY2yB3J+R9E/DZzLOjTpM3LXI 1MnEkBm/Er; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 10:46:40 -0000 To Robin's and Brian's points, I think the charter makes it very clear that there can be no perfect use of terminology just because the function of the IP address is overloaded. As such, can we not accept this fact and move on? The real work lies elsewhere, wouldn't you agree? Eliot From hartmans@mit.edu Wed Mar 18 04:35:31 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692EA3A6A17; Wed, 18 Mar 2009 04:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTQwRkGyFoyq; Wed, 18 Mar 2009 04:35:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 9F9B33A67FD; Wed, 18 Mar 2009 04:35:30 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EFDD4424A; Wed, 18 Mar 2009 07:36:07 -0400 (EDT) From: Sam Hartman To: Eliot Lear References: <20090318051408.271326BE55C@mercury.lcs.mit.edu> <49C0D139.8000108@cisco.com> Date: Wed, 18 Mar 2009 07:36:07 -0400 In-Reply-To: <49C0D139.8000108@cisco.com> (Eliot Lear's message of "Wed, 18 Mar 2009 11:47:21 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ipdir@ietf.org, lisp@ietf.org, iesg@ietf.org Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 11:35:31 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> To Robin's and Brian's points, I think the charter makes it Eliot> very clear that there can be no perfect use of terminology Eliot> just because the function of the IP address is overloaded. Eliot> As such, can we not accept this fact and move on? The real Eliot> work lies elsewhere, wouldn't you agree? I'm going to push back very strongly on terminology arguments. They tend not to be productive. Instead, I'd like people to describe what is unclear about the charter and we can work on fixing that. That may or may not involve changing terminology, but I have high confidence that we'll at least have a more constructive discussion than if we fight first about the terminology. Bryan, Margaret and Lixia have all identified what I believe is roughly the same issue: EIDs have local topology and are locally routable. They contain three portions: a part that identifies an organization. That part really does seem to be an identifier. They contain a portion that identifies a subnet within an organization and a portion that identifies an interface. How large each of these portions is may change as LISP deployment changes. The chairs are aware that the chartar does not currently describe this issue accurately enough[1] and will propose resolution. [1] I understand that until the WG is created it is more what Jari thinks than what the chairs think that matter. Robin has identified a similar issue that is not entirely the same: we need to clarify that EIDs are IP addresses. I don't want to argue about whether they are or are not the same namespace. Are ULAs in the same namespace as PA IPV6 addresses? What about 6-to-4 address? That doesn't seem productive. It does seem productive to point out that EIDs are IP addresses and that there will definitely be cases where an end-system cannot tell whether an address is an EID or an RLOC. There may be cases where an end system can tell that something is an EID, for example, if EIDs are allocated from well-known IPV6 prefixes. I'd appreciate comments on whether this level of detail belongs in the charter. From lear@cisco.com Wed Mar 18 06:27:22 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC9D28C1F6; Wed, 18 Mar 2009 06:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.68 X-Spam-Level: X-Spam-Status: No, score=-9.68 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpX8cz5R7+dV; Wed, 18 Mar 2009 06:27:21 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 73BCC28C168; Wed, 18 Mar 2009 06:27:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,384,1233532800"; d="scan'208";a="36344237" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2009 13:28:03 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2IDS3Pn000381; Wed, 18 Mar 2009 14:28:03 +0100 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp6791.cisco.com [10.61.90.134]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2IDS2TY012406; Wed, 18 Mar 2009 13:28:03 GMT Message-ID: <49C0F6E2.4040206@cisco.com> Date: Wed, 18 Mar 2009 14:28:02 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090316 Shredder/3.0b3pre MIME-Version: 1.0 To: Sam Hartman References: <20090318051408.271326BE55C@mercury.lcs.mit.edu> <49C0D139.8000108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2149; t=1237382883; x=1238246883; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[lisp]=20WG=20Review=3A=20Locator/ID=20 Separation=20Protocol=20(lisp) |Sender:=20; bh=SjFnvsGvbLmE2yU/3Db3GjURFw6SQMBjfgwa+7ZMXUg=; b=KbSzHhkpVW2QnIHqDvfrQ8KYryN+U6u4t3aZymvD0AMSUjBLCACH4k3y/C 7fEtS0P9nsUrGuT//7YTGYzGOsQjcvw8Js4uKPyZLlE4eOnCpcfey6yMHHxV qVYJ7Xxe5B; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ipdir@ietf.org, lisp@ietf.org, iesg@ietf.org Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 13:27:22 -0000 On 3/18/09 12:36 PM, Sam Hartman wrote: > Bryan, Margaret and Lixia have all identified what I believe is > roughly the same issue: EIDs have local topology and are locally > routable. They contain three portions: a part that identifies an > organization. That part really does seem to be an identifier. In the context of LISP it is the only identifier bound by the mapping system. > The chairs are aware that the chartar does not currently describe this > issue accurately enough[1] and will propose resolution. > > [1] I understand that until the WG is created it is more what Jari > thinks than what the chairs think that matter. > Tweak if you must, but I stand by my original statement, that the real work lies elsewhere. > > Robin has identified a similar issue that is not entirely the same: we > need to clarify that EIDs are IP addresses. I don't want to argue > about whether they are or are not the same namespace. Are ULAs in the > same namespace as PA IPV6 addresses? What about 6-to-4 address? That > doesn't seem productive. I agree. > It does seem productive to point out that > EIDs are IP addresses and that there will definitely be cases where an > end-system cannot tell whether an address is an EID or an RLOC. > There > may be cases where an end system can tell that something is an EID, > for example, if EIDs are allocated from well-known IPV6 prefixes. I'd > appreciate comments on whether this level of detail belongs in the > charter. > > If you're looking for text to add, from my point of view it would be this: unchanged semantics of an IP address from the end host's perspective meets a design goal of not requiring end host changes. That's a big deal. Anything that tweaks that goal should be met with great skepticism because of the potential costs. I myself have one nit with the charter. LISP and the similar map-encap proposals are about as potentially harmful as any other L3VPN mechanism, and it seems excessive to label LISP any more harmful than those. It seems sufficient to label the work experimental for now. Eliot From jnc@mercury.lcs.mit.edu Wed Mar 18 08:43:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9D33A6837; Wed, 18 Mar 2009 08:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAZH2vDZ5jCX; Wed, 18 Mar 2009 08:43:14 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 7F40F3A6403; Wed, 18 Mar 2009 08:43:14 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id F15446BE578; Wed, 18 Mar 2009 11:43:56 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090318154356.F15446BE578@mercury.lcs.mit.edu> Date: Wed, 18 Mar 2009 11:43:56 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 15:43:15 -0000 > From: Sam Hartman > EIDs have local topology and are locally routable. They contain three > portions: a part that identifies an organization. That part really does > seem to be an identifier. They contain a portion that identifies a > subnet within an organization and a portion that identifies an > interface. It's probably worth also noting (in addition to the caveats about the semantics changing over time) that "organization" != "portion of network". I.e. a chunk of namespace might be allocated to an organization, but it might further subdivide that chunk, and allocate one part to an office in one location, and another part to an office elsewhere. In general, the Internet has a long history of taking layers of binding and using them in, ah, 'creative' ways. Look at ARP and ARP subnetting, and DNS and load sharing, etc, etc. So no doubt the layer of binding available here will also be utilized in 'creative' ways we don't currently visualize. Noel From Fred.L.Templin@boeing.com Wed Mar 18 08:52:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6893A68F0 for ; Wed, 18 Mar 2009 08:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7PDVcYtKP-2 for ; Wed, 18 Mar 2009 08:52:32 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 849593A68D3 for ; Wed, 18 Mar 2009 08:52:32 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2IFrDDL020802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Mar 2009 08:53:14 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2IFrDO8016427; Wed, 18 Mar 2009 08:53:13 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2IFrDXZ016420; Wed, 18 Mar 2009 08:53:13 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Mar 2009 08:53:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Mar 2009 08:53:10 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105B48C50@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090318051408.271326BE55C@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] WG Review: Locator/ID Separation Protocol (lisp) Thread-Index: AcmniGCZ87hbqbrkRiCdH041S+LiLQAVeoTQ References: <20090318051408.271326BE55C@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 18 Mar 2009 15:53:10.0573 (UTC) FILETIME=[A34925D0:01C9A7E1] Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 15:52:33 -0000 Noel, > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Tuesday, March 17, 2009 10:14 PM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) >=20 >=20 > > On 2009-3-17, at 19:04, Brian E Carpenter wrote: >=20 > > The entity that LISP calls an EID is in fact a locator; it's simply a > > locator of limited routeability. >=20 > Calling it a "locator" is even 'wronger' than calling it an EID, alas. >=20 > If the mapping-encapsulation takes place at the first-hop router (which I > expect to be an eventual evolutionary step), _at the internetworking level_ > the properties of the LISP EID are extremely similar to an IEEE Interface ID, > which nobody would call a locator. All they both do is identify (in a > globally unique way) an interface. It certainly would have no more inherent > location information in it than an IEEE IID does. I'm not sure about the analogy. If I assign the same interface ID on multiple interfaces of the same node, it works fine (as long as they're not attached to the same link). But, if I assign the same IP address on multiple interfaces of the same node (i.e., if the system even let me do that), the behavior might be more difficult to predict. I think there is no way around acknowledging that the LISP "EID" is actually an IP address that is routable within a limited scope - even if only node-local. As has been said before then, if you really want a *true* endpoint identifier, HIP provides an example. > And that doesn't even touch on the possibility that the interface naming > functionality would _also_ be leached out of the LISP EID, leaving it as > purely a location-less identifier for a stack (which is, exactly, an EID...) >=20 > Please see my previous length message to the RRG list (sigh, too many lists): >=20 > http://www.irtf.org/mail-archive/web/rrg/current/msg04612.html >=20 > which discusses at more length the issue of the changing semantics of the > LISP EID over time, and in particular how the 'location' functionality is > incrementally leached out of it. >=20 >=20 > > I believe it should be called a LLOC (local locator), with > > consequent changes to the charter text. ... the risk in the current > > terminology is that people will be confused for ever. >=20 > I don't know why the original LISP team decided to call it an EID. (I wasn't > involved in the project at that point.) The problem now with changing it is > that, as a LISP term, it has been used for a long time now, and I'm not sure > it's really plausible to change it. (People will keep saying 'LISP EID', > I suspect.) >=20 > But if it is changed, it needs to be an _entirely new term_, since _any_ > existing term is at best an inexact fit to the particular, detailed (and > probably not constant over time) semantics of the LISP EID. I am still offering Endpoint Interface iDentifeir (EID); wouldn't take much of a tweak to the documents. Fred fred.l.templin@boeing.com >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Wed Mar 18 12:51:53 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936EA28C0CE for ; Wed, 18 Mar 2009 12:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.13 X-Spam-Level: X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0eO7k+53gGq for ; Wed, 18 Mar 2009 12:51:52 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id BF8613A6960 for ; Wed, 18 Mar 2009 12:51:52 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 419226BE574; Wed, 18 Mar 2009 15:52:36 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090318195236.419226BE574@mercury.lcs.mit.edu> Date: Wed, 18 Mar 2009 15:52:36 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 19:51:53 -0000 > From: "Templin, Fred L" > I'm not sure about the analogy. If I assign the same interface ID on > multiple interfaces of the same node, it works fine ... But, if I > assign the same IP address on multiple interfaces of the same node Which is part of why I said "the properties of the LISP EID are extremely similar to an IEEE Interface ID" - not 'identical to'! The problem you point out was one of the differences I identified, in thinking about it. To be exact, even if mapping-encapsulation functionality is in first-hop routers at a site, if an ETR is connected to multiple physical networks at such a site, then when a packet arrives either: - i) the ETR has to have a table, identifying which physical network each LISP EID is on; or - ii) something in the LISP EID must identify which physical network the host the packet is for is attached to; or - iii) something in the RLOC must identify said network. i) isn't exactly infeasible - that's basically what bridges do already. ii) is what the current scheme is - and it means that LISP EIDs have to retain some location semantics. iii) would need some support, probably through assignment of a new RLOC AFI to carry a tuple (the ETR's locator, plus a destination physical network selector), plus some information in the encapsulation header(to carry the destination physical network selector). Not sure which is best - or perhaps all might be used, in different situations. > I am still offering Endpoint Interface iDentifeir (EID) I like it, but... if LISP evolves to the point where LISP EIDs become purely stack identifiers (which is what I would like to see, long-term), and interfaces are named from a new locator namespace (yes, I know this requires host changes), then LISP EIDs would not in fact name interfaces any more. The only piece of functionality that _cannot_ be leached out of an IPvN address, _if interoperability with unmodified hosts is to be maintained_, is their identification of stacks. (Note that having interfaces named from a new locator namespace is perfectly feasible, because that would only be visible _locally_ - the host on the far end of e.g. a TCP connection would not necessarily be aware that that was happening on the other end.) Noel From Fred.L.Templin@boeing.com Wed Mar 18 15:43:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8909F3A6A89 for ; Wed, 18 Mar 2009 15:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.305 X-Spam-Level: X-Spam-Status: No, score=-6.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOhdq4BHHiDx for ; Wed, 18 Mar 2009 15:43:34 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id DB1BB3A6AA7 for ; Wed, 18 Mar 2009 15:43:34 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2IMiH0c022872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Mar 2009 15:44:17 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2IMiGxQ008054; Wed, 18 Mar 2009 15:44:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2IMiEQ3008003; Wed, 18 Mar 2009 15:44:16 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Mar 2009 15:44:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Mar 2009 15:44:15 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105B4906E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090318195236.419226BE574@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] WG Review: Locator/ID Separation Protocol (lisp) Thread-Index: AcmoAy7CIx41yfXQQc+m4DM5OFC+cAAF0NYQ References: <20090318195236.419226BE574@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 18 Mar 2009 22:44:16.0688 (UTC) FILETIME=[116F9B00:01C9A81B] Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 22:43:35 -0000 > I like it, but... if LISP evolves to the point where LISP EIDs become purely > stack identifiers (which is what I would like to see, long-term), and > interfaces are named from a new locator namespace (yes, I know this requires > host changes), then LISP EIDs would not in fact name interfaces any more. Why would you like to see a stack identifier when you could have a true host identifier (e.g., HIP)? No EID-morphing necessary. Fred fred.l.templin@boeing.com From jnc@mercury.lcs.mit.edu Wed Mar 18 15:53:19 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C3928C11D for ; Wed, 18 Mar 2009 15:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQk-npg0Zvor for ; Wed, 18 Mar 2009 15:53:18 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id C55E228C0F9 for ; Wed, 18 Mar 2009 15:53:18 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9CE096BE599; Wed, 18 Mar 2009 18:54:02 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090318225402.9CE096BE599@mercury.lcs.mit.edu> Date: Wed, 18 Mar 2009 18:54:02 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 22:53:19 -0000 > From: "Templin, Fred L" > Why would you like to see a stack identifier when you could have a true > host identifier Because I don't want to have the upgrade the software on every host on the entire Internet. Noel From rw@firstpr.com.au Wed Mar 18 17:09:18 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13493A6965; Wed, 18 Mar 2009 17:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wAnJ-SIKx7c; Wed, 18 Mar 2009 17:09:18 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id B06B83A68CD; Wed, 18 Mar 2009 17:09:17 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id C965017572F; Thu, 19 Mar 2009 11:10:00 +1100 (EST) Message-ID: <49C18DD6.1020800@firstpr.com.au> Date: Thu, 19 Mar 2009 11:12:06 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: iesg@ietf.org References: <20090318003000.264213A6A6C@core3.amsl.com> In-Reply-To: <20090318003000.264213A6A6C@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 00:09:18 -0000 I propose changed and additional text for the LISP WG charter in response to two types of concern: 1 - LISP's name and claim to implementing true Loc/Id separation is problematic, in that other systems such as HIP implement truly separate Locator and Identifier addressing systems (AKA namespaces) while LISP does not. [1] [2] 2 - That the charter should be unambiguous for readers who know nothing about the RRG, LISP etc. and should provide greater clarity about the nature of LISP's "separation". This is especially important considering the false claims made in some LISP I-Ds, presentations and mailing list messages [3] that LISP involves separate namespaces for Locators and Identifiers. - Robin Replace the first 2 sentences of paragraph 3 with the following text (perhaps as one or two paragraphs, rather than the three below) and leave the remaining sentences as a separate paragraph. This new text also explicitly states that EID space is for end-user networks and lists the benefits it provides in a scalable manner. LISP supports the separation of the Internet address space (IPv4 or IPv6) into multiple regions, each of which contains only EIDs or RLOCs. EID addresses are intended to be attractive for end-user networks and to enable the provision of multihoming, portability of the EID addresses between ISPs and inbound traffic engineering to large numbers of these networks in a scalable manner. LISP Ingress Tunnel Routers (ITRs) handle packets addressed to EID regions of the address space via global "map-and-encap" system (RFC 1955) in which a mapping system is used to determine the RLOC address of an Egress Tunnel Router (ETR) to which the packet will be tunneled. The ETR decapsulates the packet and forwards it to the destination network. Hosts and conventional routers make no distinction between addresses in the EID or RLOC regions of the address space. No separate namespaces are created. While it may be possible to use an IPv4 RLOC to tunnel a packet addressed to an IPv6 EID address or vice-versa, IPv4(6) RLOCs and EIDs share the same IPv4(6) namespace. Optionally, at this point, add a mention of HIP as involving separate namespaces for Locator and Identifier. I also propose modifying the last sentence of para 1 to include mention of the proper term which covers LISP, APT, Ivip, TRRP and Six/One Router: "core-edge separation schemes" [4]: In general, these proposals are core-edge separation schemes and were initially known by the term "Locator/Identifier separation". [1] Margaret Wasserman 2009-03-12 http://www.ietf.org/mail-archive/web/lisp/current/msg00265.html [2] Fred Templin 2009-03-13 http://www.ietf.org/mail-archive/web/lisp/current/msg00266.html [3] Robin Whittle 2009-03-18 http://www.ietf.org/mail-archive/web/lisp/current/msg00273.html [4] Towards a Future Internet Architecture: Arguments for Separating Edges from Transit Core Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf From Fred.L.Templin@boeing.com Wed Mar 18 17:14:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0936B3A6B3E for ; Wed, 18 Mar 2009 17:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgX05AbUWx0v for ; Wed, 18 Mar 2009 17:14:34 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 4E1993A698C for ; Wed, 18 Mar 2009 17:14:34 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2J0FDiW002204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Mar 2009 17:15:14 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2J0FD7J026227; Wed, 18 Mar 2009 19:15:13 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2J0F9FE026187; Wed, 18 Mar 2009 19:15:13 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Mar 2009 17:15:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Mar 2009 17:15:11 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105B49105@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090318225402.9CE096BE599@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] WG Review: Locator/ID Separation Protocol (lisp) Thread-Index: AcmoHHM1kr36BtWgQVWOu7Ur/vS3MAACml6g References: <20090318225402.9CE096BE599@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 19 Mar 2009 00:15:12.0050 (UTC) FILETIME=[C515C920:01C9A827] Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 00:14:35 -0000 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Wednesday, March 18, 2009 3:54 PM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) >=20 >=20 > > From: "Templin, Fred L" >=20 > > Why would you like to see a stack identifier when you could have a true > > host identifier >=20 > Because I don't want to have the upgrade the software on every host on the > entire Internet. If you want unmodified hosts, then you are still dealing with IP addresses, and they still name interfaces. Looping back again, a loopback interface can in some sense be considered as a "handle" for a stack. But, that is different than being a handle for a host. Fred fred.l.templin@boeing.com =20 >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From rw@firstpr.com.au Wed Mar 18 17:39:17 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E2E3A69B8 for ; Wed, 18 Mar 2009 17:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dX3sEJGmT7K for ; Wed, 18 Mar 2009 17:39:16 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 1CAA03A6848 for ; Wed, 18 Mar 2009 17:39:16 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id BD234175C19; Thu, 19 Mar 2009 11:39:59 +1100 (EST) Message-ID: <49C194DE.6060502@firstpr.com.au> Date: Thu, 19 Mar 2009 11:42:06 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lisp@ietf.org References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> In-Reply-To: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Noel Chiappa Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 00:39:17 -0000 Hi Noel, I am absolutely certain that LISP as currently defined does not involve new namespaces for Locators or Identifiers. You wrote, in part: >> The "split" referred to in LISP's name involves classifying some IPv4 >> addresses into "EID" addresses and others (the remainder?) into "RLOC" >> addresses. >> ... >> EIDs and RLOCs are still within the single IPv4 namespace. > > If you look at the LISP Map-Reply packet format, you'll notice a field called > "Loc-AFI". (The documentation doesn't really talk about it.) Ever notice that > field, and wonder what it was there for? Any guesses as to why it is there? Loc-AFI is a 16 bit field with two currently defined options: IPv4 or IPv6. If LISP is encapsulating IPv4 EIDs to an IPv6 RLOC or vice-versa then the EID and RLOC addresses are in separate namespaces. However this has nothing to do with LISP - it is because IPv4 and IPv6 addresses use different namespaces. > To repeat yet again something I said a while back in email to the LISP list, > to many of the people working on LISP, LISP is not just what is in the current > documents, but also a long-term development path of which the current stuff is > only step 1 of about 5 - or more. My critique cites I-Ds, presentations and mailing list messages from the LISP designers. I can't anticipate or comment on whatever you might think of in the future. > Also, deploying a new namespace can be a major job of work, ... One does not deploy a new namespace. I think you are using the term "namespace" at times when "addressing system", "routing system" or similar would be more appropriate. Anyone can invent a new namespace, simply by defining the types of names which it encompasses and supplying a definition of how each individual name is to be interpreted. For example, here is a new namespace IPvBTFUSD: IPvBTFUSD names are 32 bit binary numbers. An IPvBTFUSD name is interpreted by reversing the order of the bits and inverting their state. The resulting 32 bits are interpreted according to their accepted meaning in the IPv4 namespace). In the future, LISP *could* define a new namespace for RLOCs which by prohibition or impracticality was never used for EIDs. This would indeed be a true case of Loc/ID separation. To be useful in a scalable routing solution, EIDs must remain in the namespaces recognised by hosts (IPv4 or IPv6). You could define IPvCP [1] as an RLOC namespace, but it would be no use in a scalable routing solution until there was firstly a global network between ITRs and ETRs which delivered packets whose destination addresses were specified according to the IPvCP namespace and secondly until most end-user networks were happy with this new network's delay and reliability. - Robin [1] IPvCP is an 84 bit addressing scheme using a namespace in which the bits are interpreted to provide centimetre accurate geographic location: 32 bits for latitude, 32 bits for longitude and 20 bits for elevation. While a scalable electronic global routing system is under development, initial deployment of the network involves carrier pigeons trained to respond to signals from skull-mounted GPS devices. This may be practical if all ETRs and ITRs could be located in pigeon-accessible sites. Hosts in general cannot be pigeon-accessible and are frequently mobile, so any network which relies on the IPvCP namespace for addressing is unsuitable for use by hosts and therefore for carrying EID packets. From dino@cisco.com Wed Mar 18 17:45:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B45D3A6B30 for ; Wed, 18 Mar 2009 17:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY9nX3uC-3Nm for ; Wed, 18 Mar 2009 17:45:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 39E7B3A6975 for ; Wed, 18 Mar 2009 17:45:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,386,1233532800"; d="scan'208";a="269954589" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2009 00:46:21 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2J0kLbN027157; Wed, 18 Mar 2009 17:46:21 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2J0kLgi029879; Thu, 19 Mar 2009 00:46:21 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Mar 2009 17:46:20 -0700 Received: from dhcp-171-70-249-217.cisco.com ([171.70.249.217]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Mar 2009 17:46:20 -0700 Message-Id: <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> From: Dino Farinacci To: Robin Whittle In-Reply-To: <49C194DE.6060502@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Mar 2009 17:46:20 -0700 References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 19 Mar 2009 00:46:20.0505 (UTC) FILETIME=[1EC56490:01C9A82C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=235; t=1237423581; x=1238287581; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[ipdir]=20LISP=20WG=3A=20Loc/I D=20separation=20-=20not=20separate=09namespaces |Sender:=20; bh=L4ZddcwLjSv1OcJ2RaSDs+CuTleQjvShaMPaJ9N2oM0=; b=Wdr6QzPdsX5/GRsWRvQO7F3yTbIVkfkJv5Re/JvsiZ6pkLdskRTvf+3SPL na3q8buLawhLDAs+dIf3jcoJqdlzWX1VXRiy8xjlbX0C9FYIcAtJJbdEDktx yvquhlluJk4JPQbE2VsyVjdpxunkREcHjUnBhiltbDpYf6ljKUEGs=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org, Noel Chiappa Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 00:45:37 -0000 > Loc-AFI is a 16 bit field with two currently defined options: IPv4 > or IPv6. Robin, you can have n namespaces with the same AFI value. RFC 2547 VPNs is an example of this. And there are plenty more examples as well. Dino From rw@firstpr.com.au Wed Mar 18 18:08:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153973A6B9C for ; Wed, 18 Mar 2009 18:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AOxjvkR25AS for ; Wed, 18 Mar 2009 18:08:57 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 473843A6B8E for ; Wed, 18 Mar 2009 18:08:57 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 00E92175D22; Thu, 19 Mar 2009 12:09:40 +1100 (EST) Message-ID: <49C19BD2.7090800@firstpr.com.au> Date: Thu, 19 Mar 2009 12:11:46 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lisp@ietf.org References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> In-Reply-To: <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Noel Chiappa Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 01:08:58 -0000 Hi Dino, You wrote: > Robin, you can have n namespaces with the same AFI value. RFC 2547 VPNs > is an example of this. And there are plenty more examples as well. Maybe so, but this is nothing to do with LISP. I stand by my critique: http://www.ietf.org/mail-archive/web/lisp/current/msg00273.html http://www.ietf.org/mail-archive/web/lisp/current/msg00288.html - Robin From dino@cisco.com Wed Mar 18 18:16:31 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9D03A6B88 for ; Wed, 18 Mar 2009 18:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfTfd9T8xsJR for ; Wed, 18 Mar 2009 18:16:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7BC223A6B6A for ; Wed, 18 Mar 2009 18:16:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,386,1233532800"; d="scan'208";a="269967720" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2009 01:17:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2J1HF68031554; Wed, 18 Mar 2009 18:17:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2J1HEjE018161; Thu, 19 Mar 2009 01:17:14 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Mar 2009 18:17:14 -0700 Received: from dhcp-171-70-249-217.cisco.com ([171.70.249.217]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Mar 2009 18:17:14 -0700 Message-Id: From: Dino Farinacci To: Robin Whittle In-Reply-To: <49C19BD2.7090800@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Mar 2009 18:17:14 -0700 References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> <49C19BD2.7090800@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 19 Mar 2009 01:17:14.0568 (UTC) FILETIME=[6FE0F480:01C9A830] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=745; t=1237425435; x=1238289435; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[ipdir]=20LISP=20WG=3A=20Loc/I D=20separation=20-=20not=09separate=09namespaces |Sender:=20; bh=SEb6cwZ1+O+t1SBjdAyCjbofFfA7q4ZEUtLrSvBDDOI=; b=A0qbM2WI/UMSyffpPIP74hENMOsYQFxbtB/Sxodw1w2/d2Y0P2o8mSomr4 1QGwH/wGuzc46xJ7VYChCujyQ9gUIS73rsUzc6fq3FkRD6+hhfRxbBFe1SVj llzc2PmH4hEo2dSdhz4ZcS75XIauXWpSvtsRV08uODGp75pBSqkDQ=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org, Noel Chiappa Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 01:16:31 -0000 > You wrote: > >> Robin, you can have n namespaces with the same AFI value. RFC 2547 >> VPNs >> is an example of this. And there are plenty more examples as well. > > Maybe so, but this is nothing to do with LISP. But that is how you'd implement an EID namespace that doesn't overlap with an RLOC namespace. You could use, say 10.1.1.1 in both namespaces to mean two different things. That is, an address used as an endpoint TCP connection identifier and the other to number a CE/PE link from a PA-block on a CPE router. Dino > > > I stand by my critique: > > http://www.ietf.org/mail-archive/web/lisp/current/msg00273.html > http://www.ietf.org/mail-archive/web/lisp/current/msg00288.html > > - Robin From rw@firstpr.com.au Wed Mar 18 19:58:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016283A6BAD for ; Wed, 18 Mar 2009 19:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsczU822ik2Y for ; Wed, 18 Mar 2009 19:58:15 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 8B7373A6A79 for ; Wed, 18 Mar 2009 19:58:14 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 45CA7175BD0; Thu, 19 Mar 2009 13:58:58 +1100 (EST) Message-ID: <49C1B570.5030203@firstpr.com.au> Date: Thu, 19 Mar 2009 14:01:04 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lisp@ietf.org References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> <49C19BD2.7090800@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Noel Chiappa Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 02:58:16 -0000 Short version: I think these I-Ds contain incorrect usage of the term "namespace": http://tools.ietf.org/html/draft-farinacci-lisp-12 http://tools.ietf.org/html/draft-lewis-lisp-interworking-02 Maybe "address range" would be better. A NANOG presentation, IETF Journal article and a mailing list message contain incorrect statements about LISP creating separate namespaces for RLOC and EID addresses - but they can't be updated. Hi Dino, You wrote: >>> Robin, you can have n namespaces with the same AFI value. RFC 2547 VPNs >>> is an example of this. And there are plenty more examples as well. >> >> Maybe so, but this is nothing to do with LISP. > > But that is how you'd implement an EID namespace that doesn't overlap > with an RLOC namespace. > > You could use, say 10.1.1.1 in both namespaces to mean two different > things. That is, an address used as an endpoint TCP connection > identifier and the other to number a CE/PE link from a PA-block on a CPE > router. Within the IPv4 namespace, which encompasses 0.0.0.0 to 255.255.255.255, there are RFC 1918 regions 10/8, 172.16/12 and 192.168/16 which do provide a separate namespace for every private network which uses such space. I think what you wrote: 1 - Has nothing to do with anything I have ever read about LISP. 2 - Is of no practical value since LISP is intended to be a scalable routing solution and since EID addresses must be globally unique - as must RLOC addresses. 3 - Wouldn't work anyway, even within an ISP, ignoring the rest of the Net, since internal routers can't tell anything about which namespace context you might intend for a packet whose destination address is within 10/8. You are using the same address range for two namespaces, which is fine in principle, but can't work without modified routers and an extra bit in the IPv4 header to communicate which namespace the address should be interpreted according to. Your example would allow traffic packets from one host being sent to a second host with a destination (EID) address of 10.1.1.1 and packets being tunneled by an ITR to an ETR where the ETR has an "RLOC" address of 10.1.1.1. (Also, an ITR having 10.1.1.1 and an ETR sending it a packet.) Ordinary routers and hosts wouldn't know or care. But you can't make ITRs work. ITRs advertise EID prefixes, in this case 10/8. An ITR would accept any packet addressed to a 10/8 address as a traffic packet with a destination address which matches an EID prefix. The ITR would therefore look up the mapping for 10.1.1.1 and encapsulate it to a 10/8 address in an effort to tunnel it to an ETR. Then the emitted packet, if it ever left the ITR, would be routed straight back to the ITR and be encapsulated again because it matches the EID prefix which the ITR advertises! I think you and your colleagues were mistaken in the use of the term "namespace" in the I-Ds, presentation and mailing list message I cited and quoted: LISP WG: Loc/ID separation - not separate namespaces http://www.ietf.org/mail-archive/web/lisp/current/msg00273.html It is too late to change the mailing list messages and the presentation. In those, there were explicit statements about LISP creating separate namespaces for RLOCs and EIDs. I think you should correct the two I-Ds I cite: http://tools.ietf.org/html/draft-farinacci-lisp-12 Versions 08, 09, 10, 11 and 12 since I first pointed out this LISP "namespace" problem on 2008-06-27. http://tools.ietf.org/html/draft-lewis-lisp-interworking-02 Versions 01 and 02 since 2008-06-27. In neither of these I-Ds is there a statement that two separate namespaces are being created. I think the problem is that you are using the word "namespace" when something like "address range" would be the correct term. So these are simple corrections. But first, I think you would need to agree with me that LISP, if it is to be useful on a global basis as a routing scaling solution, cannot create separate namespaces for RLOCs and EIDs, because both types of address need to be part of the existing namespaces of IPv4 or IPv6 in order for them to be: Useful to unmodified hosts as EID addresses. Useful as RLOC addresses, which requires that the existing global routing system be able to carry carry packets with such source and destination addresses to and from all the world's ITRs and ETRs. With LISP (and likewise with APT, Ivip and TRRP) "separation" is creating separate regions of the existing address space, which only ITRs and ETRs need to know about. Ordinary routers and hosts treat packets with these addresses as they always have. All these architectures are core-edge separation architectures, with the new kind of address space for end-user networks (EID space for LISP, Scalable PI micronet space for Ivip) being in specific prefixes known to all ITRs and the mapping system. The remaining addresses are "core" addresses, known in LISP as "RLOC" addresses. In June 2007, I mistakenly using "anycast" as part of Ivip's "Anycast ITRs in the core". One of the LISP team mentioned this to me several times and I finally got it, renaming them "Open ITRs in the DFZ" in March 2008. I appreciate his efforts to improve Ivip. Now I am returning the favour for LISP. - Robin From jzwiebel@cisco.com Wed Mar 18 20:42:36 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD633A6BBD for ; Wed, 18 Mar 2009 20:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d++37Y4tVYf for ; Wed, 18 Mar 2009 20:42:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 53F3A3A689F for ; Wed, 18 Mar 2009 20:42:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,386,1233532800"; d="scan'208,217";a="270016802" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2009 03:43:20 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2J3hKOp022390; Wed, 18 Mar 2009 20:43:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n2J3hKSw004843; Thu, 19 Mar 2009 03:43:20 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Mar 2009 20:43:20 -0700 Received: from [10.0.1.4] ([10.21.88.178]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Mar 2009 20:43:19 -0700 In-Reply-To: <49C1B570.5030203@firstpr.com.au> References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> <49C19BD2.7090800@firstpr.com.au> <49C1B570.5030203@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-6--718522755 Message-Id: <2138CF16-2CBC-40D4-80F6-C5D58563C9FD@cisco.com> From: John Zwiebel Date: Wed, 18 Mar 2009 17:43:18 -1000 To: Robin Whittle X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 19 Mar 2009 03:43:19.0981 (UTC) FILETIME=[D878D5D0:01C9A844] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2417; t=1237434200; x=1238298200; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[lisp]=20[ipdir]=20LISP=20WG=3A=20Loc/I D=20separation=20-=09not=09separate=09namespaces |Sender:=20; bh=7xA24A8S7q/S+ZGXLPzx3UbCLnTLWiYWf/KjRMlqIVI=; b=ORYskDPx3oXYYlNq9zT0Rps/FKbHE2q1QzlSVggpbKVOvoNLXZzfN6B1Ny aOK4Ite6wfm0L7VU37ei6SU1V1VLAJc2PGJr+xcAgFVWtK54uYYiBW6bvesH DK5/YW6RcD; Authentication-Results: sj-dkim-2; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org, Noel Chiappa Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 03:42:36 -0000 --Apple-Mail-6--718522755 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 18, 2009, at 5:01 PM, Robin Whittle wrote: > Maybe "address range" would be better. The problem is the address range for the RLOCs is every possible IP address (caveat, of course, special address spaces) And the address range for the EIDs is exactly the same. EIDs must be globally unique only in the EID-space. RLOCS must be globally unique only in the DFZ (which is equivalent to the RLOC-space) There are, of course, exceptions to this simple understanding. That happens when you try to send packets from EID-space into RLOC-space and visa versa. At that point, then the address must, of course, be globally unique in both spaces. Maybe we could call it "inner space" and "outer space". :-) --Apple-Mail-6--718522755 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Mar 18, 2009, at 5:01 PM, Robin Whittle wrote:

=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 Maybe "address range" would be = better.


The problem is the = address range for the RLOCs is every possible IP = address
(caveat, of course, special address = spaces)

And the address range for the EIDs is = exactly the same.

EIDs must be globally unique = only in the EID-space.

RLOCS must be globally = unique only in the DFZ (which is equivalent to the = RLOC-space)

There are, of course, exceptions to = this simple understanding. =A0That happens
when you try to = send packets from EID-space into RLOC-space and visa = versa.

At that point, then the address must, of = course, be globally unique in both = spaces.


Maybe we could call it = "inner space" and "outer space". =A0:-)
= --Apple-Mail-6--718522755-- From hartmans@mit.edu Thu Mar 19 06:09:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88F928C269 for ; Thu, 19 Mar 2009 06:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPBu4owGud0h for ; Thu, 19 Mar 2009 06:09:10 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id C170828C14B for ; Thu, 19 Mar 2009 06:09:09 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BF9DE4249; Thu, 19 Mar 2009 09:09:47 -0400 (EDT) From: Sam Hartman To: Robin Whittle References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> <49C19BD2.7090800@firstpr.com.au> <49C1B570.5030203@firstpr.com.au> Date: Thu, 19 Mar 2009 09:09:47 -0400 In-Reply-To: <49C1B570.5030203@firstpr.com.au> (Robin Whittle's message of "Thu, 19 Mar 2009 14:01:04 +1100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org, Noel Chiappa Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 13:09:10 -0000 >>>>> "Robin" == Robin Whittle writes: Robin> Short version: I think these I-Ds contain incorrect usage Robin> of the term "namespace": At least to the extent that you copy the lisp@ietf.org list can you please state your concern about the use of terminology in terms of the affect of that concern? After multiple readings of your message, I'm still somewhat confused about your point. You seem to be saying that the Namespace is a really generic term that can mean a lot of different things. You seem to be concerned about some lack of clarity in the drafts. I think your main point is that you do not believe that a single IP address can stand as both an RLOC and an EID. I agree there are definitions of namespace where saying that EIDs and RLOCs are in the same namespace means this and no more. There are other reasonable definitions of namespace, for example definitions under which ULAs and PA IPV6 addresses are in different namespaces, for which saying that EIDs and RLOCs are in the same namespace says far more than you need to if I've captured your point above. So, let's step past the terminology argument and examine your point. First, have I got your point right? Am I missing part of it? It does not seem absolutely true that the same bit pattern cannot be an EID and an RLOC. Here are ways in which this may be false: 1) As discussed in section 4 of the interworking draft, you can announce an EID as an RLOC. This is meaningful if the address would reach the same entity regardless of whether you treat it as an EID or RLOC. That section discusses disadvantages of doing so, but does not forbid the practice. (Clearly, if new EIDs are announced as RLOCs, we are making the routing problem worse. It's not clear to me that using something as both an EID and RLOC that is already announced in the DFZ actually makes things significantly worse.) 2) The RFC 2547 VPN case is actually important. You discuss some of the conditions that would be necessary for this to be done within an ISP as an argument that it couldn't work. For example, routers would need to keep track of which 10.1.0.1 they were dealing with. You propose that a bit would be needed in the IPV4 header. It turns out that this practice is quite common today. Typically MPLS labels are used to distinguish what addressing plan an address is drawn from in cases where there are multiple valid addressing plans for an interface. (It's a bit more complicated than this in actuality). However in a number of cases (particularly the CE interfaces), only one addressing plan is valid. The routers definitely do support maintaining separate routing tables and keeping the routing separate. If you had a mapping function local to an ISP, you absolutely could return EID->RLOC mappings local to the addressing plan of that ISP. If the EIDs are not globally unique, then you'll only be able to reach that EID from within the scope where it is unique. However non-unique RLOCs don't seem like they would cause any significant problem. If the EID was outside the ISP, then the mapping service could give you the RLOC of a router that would decapsulate-and-reencapsulate your packet with a new RLOC. Is this useful? I don't know. Will it be permitted by our eventual specs? Who knows. Will it be technically possibly regardless of anything we do? Almost certainly yes. However, I think there is a core of your concern that is an important clarification to the drafts. In many cases, you cannot use the same number as an EID and an RLOC. I'd ask us all to focus on figuring out how to explain that, rather than telling people that they have incorrectly used the term namespace, or their identifiers are not "true identifiers" (whatever truth is),or complaining that we cannot go back and change mailing list messages. From hartmans@mit.edu Thu Mar 19 06:11:05 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3117728C26F; Thu, 19 Mar 2009 06:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TouLxFBJfIyM; Thu, 19 Mar 2009 06:11:04 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 7FF6128C26B; Thu, 19 Mar 2009 06:11:04 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CD2054249; Thu, 19 Mar 2009 09:11:46 -0400 (EDT) From: Sam Hartman To: Robin Whittle References: <20090318003000.264213A6A6C@core3.amsl.com> <49C18DD6.1020800@firstpr.com.au> Date: Thu, 19 Mar 2009 09:11:46 -0400 In-Reply-To: <49C18DD6.1020800@firstpr.com.au> (Robin Whittle's message of "Thu, 19 Mar 2009 11:12:06 +1100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: iesg@ietf.org, lisp@ietf.org Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 13:11:05 -0000 Thanks for taking a stab at improved charter text! As I discussed in my other message, it does not seem like an absolute requirement that the same address can never be used both as an EID and RLOC. Any chance you could work on clarifications to your text that do not strictly forbid this? Also, could I get feedback from the rest of the list on the text? Do we want to adopt it? If not, what do we want to fix about it? From swb@employees.org Thu Mar 19 06:33:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F313A6B15; Thu, 19 Mar 2009 06:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyyZNIr0X5M8; Thu, 19 Mar 2009 06:33:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4A2EC3A67ED; Thu, 19 Mar 2009 06:33:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,389,1233532800"; d="scan'208";a="143775314" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-2.cisco.com with ESMTP; 19 Mar 2009 13:34:24 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2JDYOOm006108; Thu, 19 Mar 2009 09:34:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2JDYOXw017582; Thu, 19 Mar 2009 13:34:24 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 09:34:24 -0400 Received: from cisco.com ([10.86.245.243]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 09:34:23 -0400 Date: Thu, 19 Mar 2009 09:34:19 -0400 From: Scott Brim To: Sam Hartman Message-ID: <20090319133419.GW44014@cisco.com> Mail-Followup-To: Scott Brim , Sam Hartman , Robin Whittle , iesg@ietf.org, lisp@ietf.org References: <20090318003000.264213A6A6C@core3.amsl.com> <49C18DD6.1020800@firstpr.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 19 Mar 2009 13:34:23.0506 (UTC) FILETIME=[6A614F20:01C9A897] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: lisp@ietf.org, Robin Whittle , iesg@ietf.org Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 13:33:40 -0000 Excerpts from Sam Hartman on Thu, Mar 19, 2009 09:11:46AM -0400: > As I discussed in my other message, it does not seem like an absolute > requirement that the same address can never be used both as an EID and > RLOC. A field itself cannot be purely for routing/forwarding or for identifying -- you cannot control what functions will use to do their jobs, and they will take anything they can get. You can assert that a field "is" a locator or an identifier, but you should understand that someone will always do something to break your theoretical purity. > Also, could I get feedback from the rest of the list on the text? > Do we want to adopt it? If not, what do we want to fix about it? I say we all know what we're talking about, so go with what we have, do the work, and conduct the terminology war in our spare time. From hartmans@mit.edu Thu Mar 19 06:56:23 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1C528C164; Thu, 19 Mar 2009 06:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WG5U9LTCnqV; Thu, 19 Mar 2009 06:56:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id C311128C27D; Thu, 19 Mar 2009 06:56:20 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 63F514249; Thu, 19 Mar 2009 09:56:57 -0400 (EDT) From: Sam Hartman To: Scott Brim References: <20090318003000.264213A6A6C@core3.amsl.com> <49C18DD6.1020800@firstpr.com.au> <20090319133419.GW44014@cisco.com> Date: Thu, 19 Mar 2009 09:56:57 -0400 In-Reply-To: <20090319133419.GW44014@cisco.com> (Scott Brim's message of "Thu, 19 Mar 2009 09:34:19 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org, Robin Whittle , iesg@ietf.org Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 13:56:23 -0000 >>>>> "Scott" == Scott Brim writes: Scott> I say we all know what we're talking about, so go with what Scott> we have, do the work, and conduct the terminology war in Scott> our spare time. So, the discussion so far is fairly strongly supporting the claim that the clarity problem needs to be fixed in the charter. I was more trying to gather comments on whether Robin's solution was a step forward than on whether the problem needs to be solved. I want to stress that I think the discussionsupports improving the clarity of the charter; that is not the same as changing the terminology we use. At least as I read Robin's message, while there was a lot of complaint about terminology in the justification, the actual charter text changes did not seem to change terminology. I think it did remove some terms of art. From rw@firstpr.com.au Fri Mar 20 02:31:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8133A6AA3 for ; Fri, 20 Mar 2009 02:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U3tdH0lpNhw for ; Fri, 20 Mar 2009 02:31:56 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id B0D523A6A68 for ; Fri, 20 Mar 2009 02:31:55 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 8124E175BAE; Fri, 20 Mar 2009 20:32:40 +1100 (EST) Message-ID: <49C36337.6060606@firstpr.com.au> Date: Fri, 20 Mar 2009 20:34:47 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> <49C19BD2.7090800@firstpr.com.au> <49C1B570.5030203@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Noel Chiappa Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 09:31:58 -0000 Short version: Why I think my suggested changes to the draft Charter - or something like them - are worth having. Response to Sam's reply - I think the examples he is considering are not relevant to LISP being used to solve the routing scaling problem. Hi Sam, Thanks for your response. My suggested changes to the draft Charter: http://www.ietf.org/mail-archive/web/lisp/current/msg00286.html are intended to improve the Charter so it gives a clearer understanding to anyone who reads it, especially those who haven't spent the last few years reading the RRG and RAM lists. The changes would ensure readers get: A description of LISP as being part of the "core-edge separation" class of scalable routing solutions, noting that "map-and-encap" was a term used earlier on for this class. An understanding that EID space is purely for end-user networks, to provide multihoming etc. in a scalable fashion. An introduction to ITRs and ETRs and description of what they do. A clearer understanding of Locator Identifier Separation in terms of it: Not involving separate namespaces - contrary to incorrect statements about LISP in an IETF Journal article etc. and in contrast to the HIP approach to Locator Identifier Separation which does involve separate namespaces. Being an operational distinction in how addresses in different sub-sections of the address range (perhaps we should mention global unicast address range). This distinction only being applicable to ITRs and ETRs - not to hosts or ordinary routers. The draft's current wordcount is 624. The changes add 138 words for a total of 762. My attempt above to describe the changes was 140 words, so I think my changes are pretty concise. I think a Charter which didn't clearly describe these points (in addition to the other points it already covers, which I think are well written) would be confusing for many people who will be reading it in the next year or so. I am assuming that the Charter is intended to refer to LISP as defined now and as it will be developed in the next year or so, with the constraint that LISP is intended to be a practical solution to the Internet's routing scaling problem. There are all sorts of other things which could be done with LISP which are not applicable to scalable routing, but I think they should not be covered by the Charter. Please read on for a detailed reply to your message. You wrote: > > Robin> Short version: I think these I-Ds contain incorrect usage > Robin> of the term "namespace": > > At least to the extent that you copy the lisp@ietf.org list can you > please state your concern about the use of terminology in terms of the > affect of that concern? The effect of leaving the Charter in its current form, rather than changing it along the lines I suggested, would include: 1 - Greater difficulty for many people understanding the purpose of LISP's EID space and how LISP could be used to solve the scalable routing problem. 2 - Doubt in the reader's mind about exactly what constitutes "separation". This doubt would be exacerbated by existing references to LISP involving separate namespaces for RLOCs and EIDs, as I listed: http://www.ietf.org/mail-archive/web/lisp/current/msg00273.html even if the use of "namespace" in the two I-Ds is corrected. > After multiple readings of your message, I'm still somewhat confused > about your point. You seem to be saying that the Namespace is a > really generic term that can mean a lot of different things. Broadly speaking, "namespace" could be applied in various fields of endeavour. In computer networking, I think it has a precise and important meaning - so the term should be used only where it applies. "Namespace" definitely should not be used to refer to a subset of larger range of numeric addresses, as if it was a synonym for "sub-range", subnet or whatever. The best definition I could find is: http://en.wiktionary.org/wiki/namespace (computing) A conceptual space that groups classes, identifiers, etc. to avoid conflicts with items in unrelated code that have the same names. If the LISP team have a different understanding of "namespace" I hope they will discuss it. In the context of numbering and addressing, I understand that "namespace" is a unique and apt term for a context in which a name (including a number, which is a numeric name) is to be interpreted. The name "9587 3762" means exactly one thing when interpreted within the Australian telephone system's 03 area code. It means one completely different thing when interpreted in the 02 area code. These area codes are separate namespaces. They both admit 8 digit decimal numbers and they both provide an interpretation of each possible name within that range which enables some of these names to unambiguously identify a particular telephone service. "303" on its own means just a number. If you mention "303" in a gun shop, it will generally be taken to mean the calibre of a rifle. If you mention it in a musical instrument shop, it will generally be interpreted as a reference to a TB-303 electronic instrument made in Japan in 1982. These differing interpretations result from different initially assumed namespaces due to where the specific name was spoken. In IPv4, each network which uses 10/8 has its own namespace for IP addresses in that range and likewise for 172.16/12 and 192.168/16. While any network could in principle do whatever it likes when interpreting IPv4 addresses, in the context of LISP as a potentially practical scalable routing solution, we can assume that the remainder of the IPv4 address space is interpreted according to the one set of meanings in all networks. This is what I called the "IPv4 namespace". In this namespace - this framework for interpreting the meaning of specific names - a particular name 12.34.56.78 at a particular time has exactly one meaning: it identifies a particular IPv4 address, which generally is useful in that it identifies a particular host which receives and sends packets according to this address. (Since the routing system moves packets according to address, the bits are also interpreted in various ways by different routers - but nonetheless, the "meaning" of this pattern of bits is the same the world over.) Exactly what a network does with a packet addressed to 12.34.56.78 would vary - but for any network involved in global Internet connectivity, it is interpreted as meaning a particular device, or at least an address where something we regard as a particular device may be sent a packet. (I won't go into detail about anycast address, with multiple hosts on the one address - or discuss broadcast addresses, 127/8 etc.) LISP needs to be practical in a scenario of global IP networking which is based on IPv4 and/or IPv6. While not every address in these ranges is global unicast, those global unicast addresses of IPv4 are all part of a single namespace. Likewise, for IPv6. So to be exact, I will refer to: IPv4 global unicast namespace IPv6 global unicast namespace LISP needs to rely on the existing Internets: the IPv4 Internet which interprets addresses according to the IPv4 global unicast namespace and which forwards them accordingly. Likewise the IPv6 Internet according to the IPv6 global unicast namespace. It is easy to imagine other global networks using other namespaces, but none will exist in the foreseeable future. So it is reasonable to assume that LISP will rely entirely on the IPv4 and IPv6 Internets and their respective global unicast namespaces for the vital purpose of ITRs and ETRs sending packets to each other. I thought this was understood, so I didn't spell it out in such detail earlier. > You seem to be concerned about some lack of clarity in the drafts. Yes, as I described above. > I think your main point is that you do not believe that a single IP > address can stand as both an RLOC and an EID. Within the constraints of LISP being a practical solution to the IPv4 or IPv6 routing scaling problem, yes. > I agree there are definitions of namespace where saying that EIDs > and RLOCs are in the same namespace means this and no more. OK. For instance the IPv4 global unicast namespace can be divided into many sections, such as addresses being regarded as "RLOC" except where a prefix is somehow defined as being "EID" space. The mapping system carries mapping for EID sections of the global unicast address space, but not for the remaining RLOC sections. ITRs advertise EID prefixes and accept packets addressed to EID addresses into their mapping and encapsulation system, where (if there is mapping and a reachable RLOC address) the packet will be encapsulated and tunnelled to an RLOC address. The I-Ds state that LISP ITRs and ETRs must be on RLOC addresses and that EID space is for end-user networks. An IPv4 global unicast address cannot be in an EID section and also be usable for RLOC purposes, such as ITRs or ETRs. All IPv4 EIDs and RLOCs are still part of the one IPv4 global unicast namespace. It is just that the subset of the total space which is covered by that unicast namespace is divided numerically into sub-sections. Within a sub-section, all addresses are EIDs. Outside the subsections, all addresses are regarded as RLOCs. > There are other reasonable definitions of namespace, for example > definitions under which ULAs and PA IPV6 addresses are in different > namespaces, Yes, these are separate namespaces. PA IPv6 addresses are part of the IPv6 global unicast namespace. ULA addresses are interpreted (given practical meanings) according to a namespace which is unique to the site. So ULA addresses can't be used for ITRs or ETRs in any application of LISP which is to solve the routing scaling problem. Nor can ULA addresses be used for global communication, which is field LISP is involved in. > for which saying that EIDs and RLOCs are in the same namespace says > far more than you need to if I've captured your point above. Sure. When I wrote in previous messages "IPv4 namespace", in the context of scalable routing, I really meant "IPv4 global unicast namespace". > So, let's step past the terminology argument and examine your point. > First, have I got your point right? Am I missing part of it? If we continue the discussion purely in terms of the two namespaces of the two global networks which LISP must rely upon for ITR <-> ETR communications, I think our understandings are well aligned. > It does not seem absolutely true that the same bit pattern cannot > be an EID and an RLOC. In LISP, according to the I-Ds, those addresses which are not EIDs are RLOCs. The distinction is determined by whether the address - or at least addresses in the same prefix (however defined) - have an entry in the mapping system. If they are, it is an EID prefix. If not, it is an RLOC address. I am much clearer about this with Ivip. Mapped Address Blocks (MAB) are BGP-advertised prefixed (advertised by OITRDs, the equivalents of LISP PTRs). Every address within a MAB is a "Scalable PI" (SPI) address - that is, it is mapped by the Ivip mapping system and can be used as, or as part of, a "micronet". Every address within a MAB would be described in LISP as an EID - and only addresses within MABs are "EID"s. LISP lacks a term equivalent to "MAB" and there's no reason why it can't be adopted by LISP. A bit pattern must have a certain length. If it is 32 bits, it is amenable to being interpreted according to the IPv4 global unicast namespace. If so, that address, for the entire (global scalable routing) LISP system, must be either an EID address or an RLOC address. If a global scalable routing application of LISP could use some other network for ITR <-> ETR communications and if that network used 32 bit addressing using a different namespace than the IPv4 global unicast namespace, then I would agree that there could be a single bit pattern which could function both as an EID and as an RLOC. But that would depend on the same bit pattern being used on the two different networks and so in fact meaning two different things, since each network interprets the bit pattern according to the rules of separate namespaces. There is no prospect of a separate global network appearing with such characteristics, so in the context of this discussion, I would say there is no prospect for any 32 bit address being usable in a practical sense as both an EID and RLOC. (As an aside, LISP-ALT does have another network - the ALT network. This is used for ITR -> ETR communications. For simplicity, just discussing IPv4, the ALT network is constrained to use the same IPv4 global unicast namespace as is used by the Internet. As an example of why this is true, the LISP protocols require that the ETR determine the address of an ITR to send a Map Reply packet to by reading the source address of the Map Request packet which arrives via the ALT network. Likewise, the ALT network forwards Map Requests to ETRs according to which EID addresses they advertise to the ALT network (or register with a Map Server, which advertises that EID prefix on the ALT network). EID addresses are part of the IPv4 global unicast address space and so the ALT network is constrained to use the IPv4 global unicast address namespace when ascribing meanings to particular 32 bit patterns which match this large subset of the whole IPv4 address range.) A LISP system could work over both IPv4 and IPv6, including IPv4 traffic packets being encapsulated in IPv6 packets and vice-versa. In this case, there could be separate namespaces for RLOC and EID, but this is not a function of LISP - these namespaces are already differently defined for IPv4 and IPv6. Likewise 128 bit addresses - there is no prospect of there being a separate global network suitable for ITRs, ETRs and hosts using 128 bit addresses in a manner different from how the IPv6 Internet uses them in its IPv6 global unicast namespace. > Here are ways in which this may be false: > > 1) As discussed in section 4 of the interworking draft, you can > announce an EID as an RLOC. http://tools.ietf.org/html/draft-lewis-lisp-interworking-02#section-4 OK, but this is not part of LISP as a scalable routing solution: Doing this is undesirable as it defeats one of the primary goals of LISP - to reduce global routing system state. If EID prefixes are announced into the DFZ, the impact is similar to the case in which LISP has not been deployed, because these EID prefixes will be no more aggregatable than existing PI addressing. This behavior is not desirable and such a mechanism is not viewed as a viable long term solution. > This is meaningful if the address would reach the same entity > regardless of whether you treat it as an EID or RLOC. That section > discusses disadvantages of doing so, but does not forbid the > practice. (Clearly, if new EIDs are announced as RLOCs, we are > making the routing problem worse. It's not clear to me that using > something as both an EID and RLOC that is already announced in the > DFZ actually makes things significantly worse.) Your example is clearly not part of LISP as a solution to the scalable routing problem, which is the context in which I assume we are interested in LISP. I am sure all sorts of things could be done with LISP network elements and processes - but in the Charter, I think we need to focus only on those which might be a practical solution to the routing scaling problem. > 2) The RFC 2547 VPN case is actually important. You discuss some > of the conditions that would be necessary for this to be done > within an ISP as an argument that it couldn't work. For > example, routers would need to keep track of which 10.1.0.1 > they were dealing with. You propose that a bit would be needed > in the IPV4 header. 10/8 can't be used for any global, scalable routing implementation of LISP. Since the IPv4(6) interdomain routing system interfaces with its ISPs and other networks purely on the basis of unadorned IPv4(6) packets, over router links where router behavior is coordinated by a single BGP system for each of IPv4 and IPv6, I assumed that the extra bit would need to be carried in the IPv4(6) header. Links within ISPs and other networks and between networks may well involve VPNs, MPLS or whatever. However, since LISP needs to be practical in all ISPs, it has to run over pure IPv4(6). > It turns out that this practice is quite common today. Typically MPLS > labels are used to distinguish what addressing plan an address is > drawn from in cases where there are multiple valid addressing plans > for an interface. (It's a bit more complicated than this in > actuality). However in a number of cases (particularly the CE > interfaces), only one addressing plan is valid. The routers > definitely do support maintaining separate routing tables and keeping > the routing separate. Sure, but I can't see how these techniques could be part of LISP as a global routing scaling solution. > If you had a mapping function local to an ISP, you absolutely could > return EID->RLOC mappings local to the addressing plan of that ISP. Again, I think you are considering applications of LISP which are not related to solving the routing scaling problem. > If the EIDs are not globally unique, then you'll only be able to reach > that EID from within the scope where it is unique. However non-unique > RLOCs don't seem like they would cause any significant problem. If > the EID was outside the ISP, then the mapping service could give you > the RLOC of a router that would decapsulate-and-reencapsulate your > packet with a new RLOC. > > Is this useful? I don't know. I think such localised variation in the mapping system have not been described in existing LISP I-Ds. I don't recall them having been discussed. I am sure they are not part of whatever LISP has to offer in terms of solving the routing scaling problem. > Will it be permitted by our eventual specs? Who knows. I am not opposed to LISP being developed to do more than solve the scalable routing problem. I assumed the sole purpose of the new WG is to develop LISP as a scalable routing solution. I think that if the Charter is to contemplate uses of LISP beyond scalable routing, that this should be explicitly mentioned. > Will it be technically possibly regardless of anything we do? > Almost certainly yes. Sure. > However, I think there is a core of your concern that is an important > clarification to the drafts. In many cases, you cannot use the same > number as an EID and an RLOC. Since a practical global LISP system relies entirely on the global unicast IPv4 and/or IPv6 networks, there is only one namespace to use for 32 bit IPv4 addresses in the interdomain routing system and for hosts which are involved in communication to all globally accessible hosts. Likewise there is only one such namespace available for using 128 bit IPv6 addresses. There is no other globally usable namespaces or global networks. In that context, I am sure, a single numeric address cannot be used as and EID and an RLOC, where "EID" means something like "mapped by the mapping system, used for end-user networks and never of ITRs or ETRs" and "RLOC" means "all the other addresses, of which the global unicast addresses may be used for ITRs and ETRs. I have not tried to understand how LISP would work with multicast, in part because as far as I know, multicast is not supported by the interdomain routing systems of either the IPv4 or IPv6 Internets. > I'd ask us all to focus on figuring out how to explain that, I think my suggested improvements to the draft are concise and worth including. They can probably be improved upon, but I believe some text along these lines is needed in the Charter. > rather than telling people that they have incorrectly used the term > namespace, I didn't just tell them - I explained in detail why I believe this, specifically concerning LISP, in June last year. > or their identifiers are not "true identifiers" (whatever > truth is), I don't recall writing anything along these lines. > or complaining that we cannot go back and change mailing list > messages. I wasn't complaining. I was pointing out the the message, the NANOG presentation and the IETF Journal article can't be changed, and that some people will read them (especially the presentation and article) - and that as far as I can see, both are misleading in that they explicitly state that LISP creates separate EID and RLOC namespaces. In that context, I think it is all the more important to ensure the Charter is clear about the exact nature of the "Separation". "Separation" is part of LISP's name and is central to understanding LISP's mechanisms and benefits. - Robin From hartmans@mit.edu Fri Mar 20 07:41:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6B73A6A97 for ; Fri, 20 Mar 2009 07:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mjfnYvPNaOL for ; Fri, 20 Mar 2009 07:41:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id EA15E3A6A1F for ; Fri, 20 Mar 2009 07:40:59 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CADA54144; Fri, 20 Mar 2009 10:41:37 -0400 (EDT) To: Robin Whittle References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> <49C19BD2.7090800@firstpr.com.au> <49C1B570.5030203@firstpr.com.au> <49C36337.6060606@firstpr.com.au> From: Sam Hartman Date: Fri, 20 Mar 2009 10:41:37 -0400 In-Reply-To: <49C36337.6060606@firstpr.com.au> (Robin Whittle's message of "Fri\, 20 Mar 2009 20\:34\:47 +1100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org, Noel Chiappa Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 14:41:00 -0000 Hi. I'd like to focus discussion on the specific goals you propose for your charter changes. > A description of LISP as being part of the "core-edge separation" > class of scalable routing solutions, noting that "map-and-encap" > was a term used earlier on for this class. So far, you are the only one who has advanced this particular terminology distinction as important. I'd appreciate hearing comments from others. > An understanding that EID space is purely for end-user networks, to > provide multihoming etc. in a scalable fashion. Your changes in this area may be part of addressing the concern that Margaret, Lixia, and I believe Bryan raised. I think from your most recent messages you may share that concern. > An introduction to ITRs and ETRs and description of what they do. Again, comments welcome from others. > A clearer understanding of Locator Identifier Separation in terms > of it: > Not involving separate namespaces - contrary to incorrect > statements about LISP in an IETF Journal article etc. and > in contrast to the HIP approach to Locator Identifier Separation > which does involve separate namespaces. You've presented one definition of namespace. I strongly suspect that there are a lot of other definitions floating around and that the term was being used loosely. I have not seen a lot of support for your strict definition of namespaces. However, I think that addressing Bryan, Lixia and Margaret's concern needs to be addressed by making this distinction clear. I think that avoiding the term namespace or defining what we mean by namespace will be more productive than an argument over its definition and whether we have found the clearly correct definition for our field. At least as I understand it, your proposed charter text change in this area seems to do this. > Being an operational distinction in how addresses in different > sub-sections of the address range (perhaps we should mention > global unicast address range). I think something along these lines is starting to sound like it is needed. >> This distinction only being applicable to ITRs and ETRs - not to > hosts or ordinary routers. As I understand it, the only XTRs need to care about EID vs RLOC distinctions is one of the core design goals of LISP. It seems like including it in the charter may add clarity and constrain our work. From swb@employees.org Fri Mar 20 08:47:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6195F28C1D1 for ; Fri, 20 Mar 2009 08:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm2bFWf9zECX for ; Fri, 20 Mar 2009 08:47:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A745C28C1EE for ; Fri, 20 Mar 2009 08:47:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,395,1233532800"; d="scan'208";a="271086064" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Mar 2009 15:47:55 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2KFltDr011046; Fri, 20 Mar 2009 08:47:55 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2KFlr9T011454; Fri, 20 Mar 2009 15:47:55 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 11:47:54 -0400 Received: from cisco.com ([10.86.250.53]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 11:47:54 -0400 Date: Fri, 20 Mar 2009 11:47:48 -0400 From: Scott Brim To: Sam Hartman Message-ID: <20090320154748.GI66003@cisco.com> Mail-Followup-To: Scott Brim , Sam Hartman , Robin Whittle , lisp@ietf.org, Noel Chiappa References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> <49C19BD2.7090800@firstpr.com.au> <49C1B570.5030203@firstpr.com.au> <49C36337.6060606@firstpr.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 20 Mar 2009 15:47:54.0339 (UTC) FILETIME=[3B9F2B30:01C9A973] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: Noel Chiappa , Robin Whittle , lisp@ietf.org Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 15:47:09 -0000 Excerpts from Sam Hartman on Fri, Mar 20, 2009 10:41:37AM -0400: > > Hi. > I'd like to focus discussion on the specific goals you propose for your charter changes. > > > A description of LISP as being part of the "core-edge separation" > > class of scalable routing solutions, noting that "map-and-encap" > > was a term used earlier on for this class. > > So far, you are the only one who has advanced this particular > terminology distinction as important. I'd appreciate hearing comments > from others. I believe it's useful to distinguish between encapsulation and various forms of rewriting/translation, which also provide core-edge separation. > > A clearer understanding of Locator Identifier Separation in terms > > of it: > > > Being an operational distinction in how addresses in different > > sub-sections of the address range (perhaps we should mention > > global unicast address range). > > I think something along these lines is starting to sound like it is needed. Does this have to be done before the WG is chartered? From hartmans@mit.edu Fri Mar 20 09:18:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117B43A691E for ; Fri, 20 Mar 2009 09:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdwZOueHLhzy for ; Fri, 20 Mar 2009 09:18:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 77E003A6969 for ; Fri, 20 Mar 2009 09:17:59 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 554DC4144; Fri, 20 Mar 2009 12:18:40 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Fri, 20 Mar 2009 12:18:40 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Presentations on each draft at the meeting: what we're looking for X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 16:18:06 -0000 As you can see from our agenda, we're having a status presentation for each of the drafts. I realize this is a bit late, but I want to give people an idea of what Darrel and I are trying to accomplish with these presentations. We'd like to answer the following questions for each draft: 1) where are we at with the technology - Stable? Clear? 2) what work is remaining to do 3) what review is needed to achieve broad consensus It's my understanding that for some drafts, the bits on the wire are relatively stable. For these drafts our work will focus on finding out what is unclear about the text, getting the necessary review from the rest of the IETF, and moving things forward. For other drafts, I'm told we have some active engineering work to do. One of the primary goals of this first meeting will be to get on the same page about this. I suspect many participants will already know this. I certainly don't. Also, one of the goals of forming a WG is to get broader involvement in an engineering effort. So, if we're successful, I will not be the only new face at the meeting. Darrel and I would definitely appreciate presentations early. If you can get us a version of the presentation by Monday morning, that will help people prepare for the meeting. However, I understand that this is incredibly late notice for such a request. We definitely do need your presentations before you present so we can get them on the website. From hartmans@mit.edu Fri Mar 20 09:33:37 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8EF63A6C62 for ; Fri, 20 Mar 2009 09:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc1RwFhxf5Lj for ; Fri, 20 Mar 2009 09:33:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id C44CB3A68C1 for ; Fri, 20 Mar 2009 09:33:32 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5D01C4144; Fri, 20 Mar 2009 12:34:07 -0400 (EDT) To: Scott Brim References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> <49C19BD2.7090800@firstpr.com.au> <49C1B570.5030203@firstpr.com.au> <49C36337.6060606@firstpr.com.au> <20090320154748.GI66003@cisco.com> From: Sam Hartman Date: Fri, 20 Mar 2009 12:34:07 -0400 In-Reply-To: <20090320154748.GI66003@cisco.com> (Scott Brim's message of "Fri\, 20 Mar 2009 11\:47\:48 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Noel Chiappa , Robin Whittle , lisp@ietf.org Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 16:33:37 -0000 >>>>> "Scott" == Scott Brim writes: >> > A clearer understanding of Locator Identifier Separation in >> terms > of it: >> >> > Being an operational distinction in how addresses in >> different > sub-sections of the address range (perhaps we >> should mention > global unicast address range). >> >> I think something along these lines is starting to sound like >> it is needed. Scott> Does this have to be done before the WG is chartered? Something has to happen. The charter needs to be clear and accurate in what it says. Margaret at least has said that removing a lot of text from the charter might also address her concerns, or at least some of them. Darrel and I discussed a rough outline for proposed text; I'd prefer to try and float that before looking at removing a lot of text from the charter. However if it's late next week and we don't have text that makes people happy, I definitely think we should consider options that allow us to defer the discussion. I think the charter is a tool that among other things serves these goals: 1) Allows people in other parts of the IETF to quickly examine what we're doing and decide whether they need to become involved. 2) Allows the chairs to limit the scope of what we're doing so we can be successful. I think the fact that LISP maps networks rather than end systems is an important property in distinguishing LISP from other proposals and so it may be useful in controlling scope. The other thing I'd like the charter to do is to say how much future possible extensions to LISP are in scope. My belief is that the current charter limits the scope of the LISP we're designing to cases where most routers do not change, and where most hosts and routers are unaware of LISP. While we might choose to make LISP work when deployed very close to the edge, say first hop router, that is not a use case we're focusing on, and we're certainly not designing in features for that deployment. That sort of limitation seems like it may be very valuable to the chairs, so I'm reluctant to drop too much text. From jnc@mercury.lcs.mit.edu Fri Mar 20 10:20:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E597C3A6BB5 for ; Fri, 20 Mar 2009 10:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.431 X-Spam-Level: X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6GbF6GCKoBk for ; Fri, 20 Mar 2009 10:20:08 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 26C5C3A696B for ; Fri, 20 Mar 2009 10:20:07 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3E8476BE5D6; Fri, 20 Mar 2009 13:20:53 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090320172053.3E8476BE5D6@mercury.lcs.mit.edu> Date: Fri, 20 Mar 2009 13:20:53 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 17:20:09 -0000 > From: Sam Hartman I think the fact that LISP maps networks rather than end systems 'initially maps' or 'currently maps' is I think more accurate. There's nothing in either the Request-Reply or encapsulation protocols, _as currently designed_, which limits either one to only networks. > The other thing I'd like the charter to do is to say how much future > possible extensions to LISP are in scope. My belief is that the current > charter limits the scope of the LISP we're designing to cases where > most routers do not change, and where most hosts and routers are > unaware of LISP. While we might choose to make LISP work when deployed > very close to the edge, say first hop router, that is not a use case > we're focusing on, and we're certainly not designing in features for > that deployment. I don't have any problem whatsoever with having the charter limit the output of the WG, as initially chartered (because revising charters down the line, as targets are reached, is certainly done), to documents intended to support the case you describe ("most routers do not change, and where most hosts and routers are unaware of LISP"). However, I'd like to understand exactly what you mean when you say we will "certainly not design[] in features for [other uses]". Taken at its face meaning, that could prevent adding anything intended to give the LISP system a capability to evolve and change down the road. Is that really your intent? Noel From HeinerHummel@aol.com Fri Mar 20 10:55:18 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA4D3A6B31 for ; Fri, 20 Mar 2009 10:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.952 X-Spam-Level: * X-Spam-Status: No, score=1.952 tagged_above=-999 required=5 tests=[AWL=1.665, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1r-Co1XyxoM for ; Fri, 20 Mar 2009 10:55:17 -0700 (PDT) Received: from imo-d21.mx.aol.com (imo-d21.mx.aol.com [205.188.144.207]) by core3.amsl.com (Postfix) with ESMTP id 87EC43A6947 for ; Fri, 20 Mar 2009 10:55:17 -0700 (PDT) Received: from HeinerHummel@aol.com by imo-d21.mx.aol.com (mail_out_v39.1.) id 6.cea.5159d02f (29679); Fri, 20 Mar 2009 13:55:46 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Fri, 20 Mar 2009 13:55:46 EDT To: hartmans-ietf@mit.edu, rw@firstpr.com.au MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1237571746" X-Mailer: 9.0 SE for Windows sub 5021 Cc: lisp@ietf.org, jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 17:55:18 -0000 -------------------------------1237571746 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 20.03.2009 15:42:13 Westeurop=E4ische Normalzeit schreibt= =20 hartmans-ietf@mit.edu: Hi. I'd like to focus discussion on the specific goals you propose for your=20 charter changes. > A description of LISP as being part of the "core-edge separation" > class of scalable routing solutions, noting that "map-and-encap" > was a term used earlier on for this class. So far, you are the only one who has advanced this particular terminology distinction as important. I'd appreciate hearing comments from others. Terminology: I share Magret's concerns. What kind of routing is LISP? What it does is a =20= 2=20 loose hops routing. Locator /identifier split or separation is a completely different story: se= e=20 HIP. Robin's proposal is core-edge separation. The next suggestion might be =20 core-edge split :-(=20 But this is all camouflage terminology, hiding that RLOC routing is anythin= g=20 else but location based routing. =20 This is why I believe that LISP will fail: The ALT may either become large like almost the whole body (internet) or =20 small like the spine of a body. In the first case the scalability issues are only reshuffled but not =20 eliminated, in the second case the internet becomes vulnerable. Who controls= the =20 ALT, controls the internet. DoS attacks is one thing. Another thing is that the power of control is a threat by itself. The =20 European Union is driving the Galileo project although (as far as I know) no= one =20 has been kept off from using the GPS so far. Long-term reasoning! The same will apply to the ALT. =20 Heiner =20 =20 =20 =20 =20 > An understanding that EID space is purely for end-user networks, to > provide multihoming etc. in a scalable fashion. Your changes in this area may be part of addressing the concern that=20 Margaret, Lixia, and I believe Bryan raised. I think from your most recent messages you may share that concern. > An introduction to ITRs and ETRs and description of what they do. Again, comments welcome from others. > A clearer understanding of Locator Identifier Separation in terms > of it: > Not involving separate namespaces - contrary to incorrect > statements about LISP in an IETF Journal article etc. and > in contrast to the HIP approach to Locator Identifier Separation > which does involve separate namespaces. You've presented one definition of namespace. I strongly suspect that there are a lot of other definitions floating around and that the term was being used loosely. I have not seen a lot of support for your strict definition of namespaces. However, I think that addressing Bryan, Lixia and Margaret's concern needs to be addressed by making this distinction clear. I think that avoiding the term namespace or defining what we mean by namespace will be more productive than an argument over its definition and whether we have found the clearly correct definition for our field. At least as I understand it, your proposed charter text change in this area seems to do this. > Being an operational distinction in how addresses in different > sub-sections of the address range (perhaps we should mention > global unicast address range). I think something along these lines is starting to sound like it is needed= . >> This distinction only being applicable to ITRs and ETRs - not to > hosts or ordinary routers. As I understand it, the only XTRs need to care about EID vs RLOC distinctions is one of the core design goals of LISP. It seems like including it in the charter may add clarity and constrain our work. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp -------------------------------1237571746 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 20.03.2009 15:42:13 Westeurop=E4ische Normalzeit sch= reibt=20 hartmans-ietf@mit.edu:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>Hi.
I'd like to focus discussion on the specific goals you pro= pose=20 for your charter changes.


>  A description of LISP as b= eing=20 part of the "core-edge separation"
>  class of scalable routing= =20 solutions, noting that "map-and-encap"
>  was a term used earli= er=20 on for this class.

So far, you are the only one who has advanced th= is=20 particular
terminology distinction as important.  I'd appreciate=20 hearing comments
from others.
Terminology:
I share Magret's concerns. What kind of routing is LISP? What it does i= s a=20 2 loose hops routing.
Locator /identifier split or separation is a completely different story= :=20 see HIP.
Robin's proposal is core-edge separation. The next suggestion might be=20 core-edge split :-( 
But this is all camouflage terminology, hiding that RLOC routing is=20 anything else but location based routing.
 
This is why I believe that LISP will fail:
The ALT may either become large like almost the whole body (internet) o= r=20 small like the spine of a body.
In the first  case the scalability issues are only reshuffled but=20= not=20 eliminated, in the second case the internet becomes vulnerable. Who controls= the=20 ALT, controls the internet. DoS attacks is one thing.
Another thing is that the power of control is a threat by itself.=20= The=20 European Union is driving the Galileo project although (as far as I know) no= one=20 has been kept off from using the GPS so far. Long-term reasoning!
The same will apply to the ALT.
 
 Heiner
 
 
 
 
 
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>

>  An understanding that EID space is purely for=20 end-user networks, to
>  provide multihoming etc. in a scalable= =20 fashion.

Your changes in this area may be part of addressing the=20 concern that Margaret, Lixia, and I believe Bryan raised.
I think from=20= your=20 most recent messages you may share that concern.

>  An=20 introduction to ITRs and ETRs and description of what they do.

Agai= n,=20 comments welcome from others.

>  A clearer understanding of= =20 Locator Identifier Separation in terms
>  of it:

>&nb= sp;=20    Not involving separate namespaces - contrary to=20 incorrect
>     statements about LISP in an IETF Jour= nal=20 article etc. and
>     in contrast to the HIP approac= h to=20 Locator Identifier Separation
>     which does involv= e=20 separate namespaces.

You've presented one definition of=20 namespace.  I strongly suspect that
there are a lot of other=20 definitions floating around and that the term
was being used loosely.&n= bsp;=20 I have not seen a lot of support for your
strict definition of=20 namespaces.  However, I think that addressing
Bryan, Lixia and=20 Margaret's concern needs to be addressed by making
this distinction=20 clear.  I think that avoiding the term namespace or
defining what=20= we=20 mean by namespace will be more productive than an
argument over its=20 definition and whether we have found the clearly
correct definition for= our=20 field.  At least as I understand it, your
proposed charter text ch= ange=20 in this area seems to do this.

>     Being an=20 operational distinction in how addresses in different
> =20    sub-sections of the address range (perhaps we should=20 mention
>     global unicast address range).

I= =20 think something along these lines is starting to sound like it is=20 needed.

>>     This distinction only being=20 applicable to ITRs and ETRs - not to
>     hosts or=20 ordinary routers.


As I understand it, the only XTRs need to car= e=20 about EID vs RLOC
distinctions is one of the core design goals of=20 LISP.  It seems like
including it in the charter may add clarity a= nd=20 constrain our work.
_______________________________________________
= lisp=20 mailing=20 list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
 
 -------------------------------1237571746-- From jnc@mercury.lcs.mit.edu Fri Mar 20 14:11:05 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25FC33A6983 for ; Fri, 20 Mar 2009 14:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWzAnccm+2wy for ; Fri, 20 Mar 2009 14:11:04 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 79B163A67F5 for ; Fri, 20 Mar 2009 14:11:04 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0D9336BE5DD; Fri, 20 Mar 2009 17:11:49 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090320211150.0D9336BE5DD@mercury.lcs.mit.edu> Date: Fri, 20 Mar 2009 17:11:49 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: [lisp] Telling EIDs, RLOCs, and 'old' IPv4 addresses apart X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 21:11:05 -0000 On 3/18/09 12:36 PM, Sam Hartman wrote: > EIDs are IP addresses and that there will definitely be cases where an > end-system cannot tell whether an address is an EID or an RLOC. Running back over some old email I ran across this, and had a thought. Is it possible to allocation RLOCs from the Class-E space (technically, I mean - I am somewhat aware of the the politics around allocation of IPv4 space). I seem to recall a prior discussion that concluded that we can't allocate EIDs from that space, because too many hosts barf on class E addresses. However, the set of xTRs and LISP backbone routers is much smaller - perhaps they all handle class E OK? Noel From vaf@cisco.com Fri Mar 20 23:20:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215963A68DA for ; Fri, 20 Mar 2009 23:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjdOdgtTl696 for ; Fri, 20 Mar 2009 23:20:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 282723A67BD for ; Fri, 20 Mar 2009 23:20:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,399,1233532800"; d="scan'208";a="159329536" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 21 Mar 2009 06:20:52 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2L6KsoK000352; Fri, 20 Mar 2009 23:20:54 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2L6KsSX020551; Sat, 21 Mar 2009 06:20:54 GMT Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [127.0.0.1]) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Debian-4) with ESMTP id n2L6KHoG014893; Fri, 20 Mar 2009 23:20:17 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n2L6K9UA014886; Fri, 20 Mar 2009 23:20:09 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Fri, 20 Mar 2009 23:20:09 -0700 From: Vince Fuller To: Noel Chiappa Message-ID: <20090321062009.GA14260@vaf-lnx1> References: <20090320211150.0D9336BE5DD@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090320211150.0D9336BE5DD@mercury.lcs.mit.edu> User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2132; t=1237616454; x=1238480454; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20Re=3A=20[lisp]=20Telling=20EIDs,=20RLOCs,=20and =20'old'=20IPv4=20addresses=20apart |Sender:=20; bh=4xA4lhOXonSAZOjsG3EQTO5UPfQVln6LLxh5e9827kc=; b=TeffLN5XBuXsQTX5usYrVMt80moIbTbCJdx3b+V/euUyWu2s/1LFXE/pOT zT4+aZ8eNAxQR41rkS20hvdZXBx2G2zQ/mDY8pNFgfLUrdX2L08hqIMVFFZo Fhi8SNshS6; Authentication-Results: sj-dkim-2; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Telling EIDs, RLOCs, and 'old' IPv4 addresses apart X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 06:20:08 -0000 On Fri, Mar 20, 2009 at 05:11:49PM -0400, Noel Chiappa wrote: > On 3/18/09 12:36 PM, Sam Hartman wrote: > > > EIDs are IP addresses and that there will definitely be cases where an > > end-system cannot tell whether an address is an EID or an RLOC. > > Running back over some old email I ran across this, and had a thought. Is it > possible to allocation RLOCs from the Class-E space (technically, I mean - I > am somewhat aware of the the politics around allocation of IPv4 space). > > I seem to recall a prior discussion that concluded that we can't allocate > EIDs from that space, because too many hosts barf on class E addresses. > However, the set of xTRs and LISP backbone routers is much smaller - perhaps > they all handle class E OK? The problem is that it isn't only the LISP-speaking routers that need to handle 240/4 ("class E") addressing; all transit routers between LISP sites will need to handle them as well. Remember that LISP RLOCs, assigned out of topologically-significant, and thus, provider-assigned space, are visible as source and destination IP addresses for packets switched through the Internet routing system. To use 240/4 as EID space, the hosts have to not choke on them. To use 240/4 as RLOC space, the entire routing "core" needs to accept them. Which can be upgraded more readily? Kind of a Catch-22... --Vince P.S. FWIW, draft-fuller-240space-02.txt, published almost exactly a year ago (and no doubt expired because the it is too contentious for the IETF to take any action), recommended that the trivial changes needed to allow 240/4 addresses be made to as many implementations as soon as possible. Yes, it will be years, if ever, before such changes would enable 240/4 to be used in a widespread manner but if the changes (which take about 20 minutes to implement; I performed them on two different Linux implementations and I haven't done any real programming in close to 20 years) are never made, then the space will obviously never be used. Typical "can't do" attitude by the IETF... From rw@firstpr.com.au Sat Mar 21 08:40:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478AA3A682B for ; Sat, 21 Mar 2009 08:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Uezkke3mnAZ for ; Sat, 21 Mar 2009 08:40:13 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 826CA3A6A3C for ; Sat, 21 Mar 2009 08:40:13 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id C9181175A86; Sun, 22 Mar 2009 02:40:59 +1100 (EST) Message-ID: <49C50B0B.8050501@firstpr.com.au> Date: Sun, 22 Mar 2009 02:43:07 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] I can find only one definition of "namespace" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 15:40:15 -0000 Apologies to anyone who breaks out in hives due to further mention of *NAMESPACE*! Hi Sam, In "Re: LISP WG: Loc/ID separation - not separate namespaces" http://www.ietf.org/mail-archive/web/lisp/current/msg00299.html you wrote, in part: > You've presented one definition of namespace. I strongly suspect > that there are a lot of other definitions floating around and that > the term was being used loosely. I have not seen a lot of support > for your strict definition of namespaces. I have done an extensive literature search http://www.firstpr.com.au/ip/ivip/namespace/ and found several entirely compatible definitions of "namespace" in the context of computer networking. The most comprehensive one was: http://en.wikipedia.org/wiki/Namespace_(computer_science) I found many instances of the term being used in RFCs and I-Ds which were consistent with this definition, going back to the early 1990s. The most notable document making frequent references (44 at least) to "namespace" in ways which entirely accord with the definitions I found, was Noel Chiappa in an unfinished draft of an I-D, which is nonetheless cited quite frequently: http://ana.lcs.mit.edu/~jnc/tech/endpoints.txt I found a few instances of usage of the term which I think were loose or incorrect, but that is normal and not suggestive of there being another, different, genuine meaning in the author's mind. I stand by my suggestion that it would be best to remove the term of "namespace" from: http://tools.ietf.org/html/draft-farinacci-lisp-12 http://tools.ietf.org/html/draft-lewis-lisp-interworking-02 and that the explicit statements about LISP creating separate namespaces for EIDs and RLOCs in an IETF Journal article are misleading as long as LISP is to be a practical solution to the routing scaling problem. In an earlier message I mentioned but did not link to a NANOG presentation in which the "separate namespaces" claim was also made: http://www.nanog.org/mtg-0710/presentations/LISP-cons.pdf That is old, not linked to from the LISP site and probably not read much. However statements about new namespaces are also made in two 2008 presentations which are linked from the LISP site: http://www.lisp4.net/docs/lisp-ripe-long.pdf Page 13 indicates that EIDs are a "new namespace". http://www.lisp4.net/docs/lisp-crc-aam-workshop.ppt Why Separate Location from ID? Level of Indirection allows us to: Keep either ID or Location fixed while changing the other Create separate namespaces which can have different allocation properties My page listed above links to 13 mailing list messages since July 2007 in which I raised concerns about inferences or statements regarding a practical core-edge separation system involving separate namespaces for EIDs and RLOCs. No alternative definition of "namespace" has yet been proposed. - Robin From jnc@mercury.lcs.mit.edu Sat Mar 21 09:56:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92CD3A67CF for ; Sat, 21 Mar 2009 09:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEUOnRxwkwjT for ; Sat, 21 Mar 2009 09:56:43 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0EB5B3A6820 for ; Sat, 21 Mar 2009 09:56:42 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 908326BE5EF; Sat, 21 Mar 2009 12:57:29 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090321165729.908326BE5EF@mercury.lcs.mit.edu> Date: Sat, 21 Mar 2009 12:57:29 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Telling EIDs, RLOCs, and 'old' IPv4 addresses apart X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 16:56:43 -0000 > From: Vince Fuller > The problem is that it isn't only the LISP-speaking routers that need > to handle 240/4 ("class E") addressing; all transit routers between > LISP sites will need to handle them as well. ... To use 240/4 as RLOC > space, the entire routing "core" needs to accept them. I guess I was looking ahead to a time when there's a significant chunk of the network which is a LISP 'core', and in which the routing tables contain only RLOCs (and I guess 'legacy addresses' as well, although there are ways to get rid of them too). (We need to get to that if LISP is going to have the largest positive impact on routing tables; if all 'core' routing tables have to contain all 'legacy addresses', plus EIDs (so legacy hosts can get to converted hosts), and also RLOCs (for transit), then we can only save a few spaces, since EID and RLOC blocks will hopefully be considerably more aggregated than legacy blocks.) In such a circumstance, we'd only have to make sure the routers in the LISP 'core' understood class E RLOCs; routes to them wouldn't need to circulate in the 'legacy' part of the network (since legacy hosts will never be trying to send packets to an RLOC anyway). Noel From rw@firstpr.com.au Sat Mar 21 10:11:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E283A6820 for ; Sat, 21 Mar 2009 10:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTfJY14jaYGW for ; Sat, 21 Mar 2009 10:10:59 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 630603A67FC for ; Sat, 21 Mar 2009 10:10:58 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id C2E94175A98; Sun, 22 Mar 2009 04:11:40 +1100 (EST) Message-ID: <49C5204C.9040204@firstpr.com.au> Date: Sun, 22 Mar 2009 04:13:48 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> <49C19BD2.7090800@firstpr.com.au> <49C1B570.5030203@firstpr.com.au> <49C36337.6060606@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 17:11:00 -0000 Short version: Responding to Sam's discussion of the changes I suggested for the draft Charter. Hi Sam, You wrote: > I'd like to focus discussion on the specific goals you propose for > your charter changes. > >> A description of LISP as being part of the "core-edge separation" >> class of scalable routing solutions, noting that "map-and-encap" >> was a term used earlier on for this class. > > So far, you are the only one who has advanced this particular > terminology distinction as important. I'd appreciate hearing > comments from others. I hope others will support this. I think the paper by Lixia and colleagues is an important step in defining terminology and arguing for the correctness of pursuing the core-edge separation approach: Towards a Future Internet Architecture: Arguments for Separating Edges from Transit Core Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf >> An understanding that EID space is purely for end-user networks, >> to provide multihoming etc. in a scalable fashion. > > Your changes in this area may be part of addressing the concern > that Margaret, Lixia, and I believe Bryan raised. I think from > your most recent messages you may share that concern. I can't be sure my my suggested text resolves their concern. I hope they will comment and suggest new text themselves. >> An introduction to ITRs and ETRs and description of what they do. > > Again, comments welcome from others. OK. >> A clearer understanding of Locator Identifier Separation in terms >> of it: > >> Not involving separate namespaces - contrary to incorrect >> statements about LISP in an IETF Journal article etc. and >> in contrast to the HIP approach to Locator Identifier >> Separation which does involve separate namespaces. > > You've presented one definition of namespace. I strongly suspect > that there are a lot of other definitions floating around and that > the term was being used loosely. I have not seen a lot of support > for your strict definition of namespaces. I responded to this in my previous message and in the new web page. http://www.ietf.org/mail-archive/web/lisp/current/msg00307.html http://www.firstpr.com.au/ip/ivip/namespace/ As far as I recall, you are the first to suggest that there may well be multiple meanings of the term in the context of scalable routing. > However, I think that addressing Bryan, Lixia and Margaret's > concern needs to be addressed by making this distinction clear. I am not quite sure which distinction you refer to. > I think that avoiding the term namespace or defining what we mean > by namespace will be more productive than an argument over its > definition and whether we have found the clearly correct definition > for our field. I don't think there is any disagreement about what "namespace" means. No-one has suggested an alternative definition of the term. It seems to be a useful, precise, and widely understood concept since at least the early 1990s in computer networking. I guessed its history went back to 1980s computer programming, but I just used Google Books and found a few 1969 AI books which used "namespace". I was unable to find any IETF or IRTF definition of it, but it is a widely used term in RFCs and I-Ds. I guess most people who used it figured it was widely and correctly understood and that there were no alternative meanings. The IRTF Name Space Research Group from a few years ago did not seem to see the need to define the term. I think the use of "namespace" in the two LISP I-Ds is simply a low-key mistake and could easily be fixed. I guess the more explicit claims made in the Journal article and presentations probably arose from the authors not thinking clearly enough about what separate namespaces really means and how this is impractical for any routing scaling solution which we need to have voluntarily adopted by the great majority of end-user networks which want multihoming - and so could not involve global changes to routers or hosts. > At least as I understand it, your proposed charter text change in > this area seems to do this. I think "namespace" is not a problematic term and that there is good cause for using it in the Charter, since the Charter quite correctly goes to some trouble to describe the "separation" and since HIP, which does a more conceptually pure and powerful "separation" is widely known to involve separate namespaces. Jari wrote of "truth in advertising about the readiness of the technology for wide deployment" regarding the LISP WG: http://www.ietf.org/mail-archive/web/lisp/current/msg00262.html I think the claims and inferences about LISP creating a new namespace for EIDs, or two separate namespaces for RLOCs and EIDs, is at odds with "truth in advertising". HIP does separate Locators and Identifiers into separate namespaces. I understand that HIP is widely regarded as a true Loc/ID Separation scheme. HIP's separate namespace for EIDs means it can't be considered as part of a practical solution to the routing scaling problem. If LISP did create separate RLOC and EID namespaces, it too would not be a practical solution because its use on a global scale would require new global networks which operate according to those new namespaces - RLOCs over some new global network and/or all hosts adopting some new EID namespace for all their communications. Even if I thought there were were no misstatements about LISP regarding separate namespaces, I think the Charter should state clearly what the nature of LISP's "separation" is. Many people reasonably and correctly assume that HIP, with its separate namespaces, is a true Locator ID Split protocol. But LISP's name: Locator Identifier Separation Protocol gives the impression that LISP is The protocol in this field. I imagine that the many people who are more familiar with HIP than with LISP or any other scalable routing architectures would by default consider LISP to involve a split to the same extent as HIP - separate namespaces. I think it is important to note that LISP is not as radical, pure or architecturally elegant as HIP. Its "separation" involve different uses for different sections of the existing IPv4(6) global unicast address space. It may be less elegant and pure, but this is what makes LISP a potentially practical solution to the routing scaling problem which a pure architecture such as HIP can never be. Since two LISP I-Ds currently use "namespace" in a manner I think is misleading, and since the IETF Journal article and two 2008 presentations (currently linked to from the LISP site) explicitly state that there are separate namespaces, I think it is all the more important to have the Charter clearly state that there are no separate namespaces. (This is all within the context of LISP being a practical solution to the routing scaling problem. LISP could be applied with separate namespaces, but I think that is outside the scope of the purpose of the new WG because it would not address the routing scaling problem in a practical manner.) >> Being an operational distinction in how addresses in different >> sub-sections of the address range (perhaps we should mention >> global unicast address range). > > I think something along these lines is starting to sound like it is > needed. I think it would be good to have the Charter refer to the IPv4(6) "global unicast address range" and the one global namespace for this, which any practical scalable routing solution relies upon for both its EID space (hosts) and RLOC space (DFZ and other routers between XTRs). As I discovered in recent discussions, mentioning something like "IPv4 namespace" is inaccurate or at least too vague. >>> This distinction only being applicable to ITRs and ETRs - not >> hosts or ordinary routers. > > As I understand it, the only XTRs need to care about EID vs RLOC > distinctions is one of the core design goals of LISP. It seems > like including it in the charter may add clarity and constrain our > work. I agree. - Robin From jnc@mercury.lcs.mit.edu Sat Mar 21 10:23:04 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0333A68B4 for ; Sat, 21 Mar 2009 10:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HJ+cKN+G6dz for ; Sat, 21 Mar 2009 10:23:03 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 4F0753A6899 for ; Sat, 21 Mar 2009 10:23:03 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C5A0A6BE571; Sat, 21 Mar 2009 13:23:50 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090321172350.C5A0A6BE571@mercury.lcs.mit.edu> Date: Sat, 21 Mar 2009 13:23:50 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] I can find only one definition of "namespace" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 17:23:04 -0000 > From: Robin Whittle > The most notable document making frequent references (44 at least) to > "namespace" in ways which entirely accord with the definitions I found, > was Noel Chiappa in an unfinished draft of an I-D, which is nonetheless > cited quite frequently I have to admit there's a certain droll humour in having _my own flipping document_ being cited to tell me I don't know what the hell I'm talking about... But I see the irony has escaped you. An important defining characteristic of a namespace is the _semantics_ of the names, not just their _syntax_. Two namespaces may have similar syntax, but different semantics (e.g. disk block numbers and memory locations). It is the difference in the semantics of legacy IPvN addresses, LISP EIDs, and RLOCs that make them separate namespaces, even though they are identical syntactically. Look, you don't like LISP. We get that. You think it's a bad idea. We get that. So why don't you go start your own WG, create your own documents, write your own code? Being obstructive about LISP is not doing anyone any good at all. Noel From roque@lacnic.net Sun Mar 22 14:38:53 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8833A68BC for ; Sun, 22 Mar 2009 14:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x66zl1VKYSpt for ; Sun, 22 Mar 2009 14:38:52 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id D644A28C101 for ; Sun, 22 Mar 2009 14:38:51 -0700 (PDT) Received: from [IPv6:2001:df8::80:217:f2ff:fe4d:a80e] (unknown [IPv6:2001:df8:0:80:217:f2ff:fe4d:a80e]) by mail.lacnic.net.uy (Postfix) with ESMTP id D38393084C5 for ; Sun, 22 Mar 2009 18:39:33 -0300 (UYT) Message-Id: <83B62425-E996-4A8C-9D7F-B78E363E3C3E@lacnic.net> From: Roque Gagliano To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Mar 2009 14:39:29 -0700 X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Subject: [lisp] Using Signed object to validate entries in Mapping Database: draft-lisp-rgaglian-ioa-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 21:38:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, As mentioned some months ago in the lisp-interest mailing list I =20 believe that the work in SIDR WG can be somehow used to verify =20 authority of the entries on the mapping database, particularly for =20 LISP but in general for Map&Encap solutions. I compiled a first draft and I am sorry that did not make it to the =20 cut date. The draft can be downloaded at: = http://iie.fing.edu.uy/~rgaglian/drafts/draft-lisp-rgaglian-ioa-00.txt The idea is to generate a CMS signed object where an EID (or set of =20 EID) address holder can sign the authority for a set of RLOC to be =20 associated with them in the mapping database. I call this objects IOA. The verification can be done by: - the mapping system before accepting an entry in the mapping = database. - the mapping clients to verify the answers from the mapping = system. How would you use this in LISP? I believe it can integrate well with the map-server as the number of =20 signed object will probably be big. Be aware that I am not describing =20= how to secure the channel to the map-server (that should be internal =20 to the ISP). Another option is to load the xTR with map filters with the data from =20= the IOAs. I look forward to hear your comments, Roque -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknGsBEACgkQnk+WSgHpbO56ywCgktRuVxs7cVPziworgWd+wLDn tRUAoNaacb+HqG0GSQmYw7d7aGZ9mz+u =3D/VMj -----END PGP SIGNATURE----- From hartmans@mit.edu Mon Mar 23 16:06:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A147128C1DF for ; Mon, 23 Mar 2009 16:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUxNaL1Of+jr for ; Mon, 23 Mar 2009 16:06:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-46b4.meeting.ietf.org [130.129.70.180]) by core3.amsl.com (Postfix) with ESMTP id 0351528C1CE for ; Mon, 23 Mar 2009 16:06:02 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 438C24144; Mon, 23 Mar 2009 19:06:50 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090320172053.3E8476BE5D6@mercury.lcs.mit.edu> From: Sam Hartman Date: Mon, 23 Mar 2009 19:06:50 -0400 In-Reply-To: <20090320172053.3E8476BE5D6@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri\, 20 Mar 2009 13\:20\:53 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:06:03 -0000 >>>>> "Noel" == Noel Chiappa writes: Noel> However, I'd like to understand exactly what you mean when Noel> you say we will "certainly not design[] in features for Noel> [other uses]". Taken at its face meaning, that could prevent Noel> adding anything intended to give the LISP system a Noel> capability to evolve and change down the road. Noel> Is that really your intent? So, what it definitely does not mean is sound protocol design: designing for extensibility, adding extension mechanisms, adding ways of doing phased upgrades. If you were to propose an extension designed to make LISP work better when an EID was mapped to a specific stack ID I'd say that was currently out of scope. If you argued that we should choose between two proposals on the table because one would make a future of LISP where most hosts did know about LISP easier, I'd initially sit back and watch the WG discussions. If people came to consensus about which proposal to use quickly, that would be fine. If the discussion seemed stuck, but a consensus would be clear if arguments hinging on evolution of LISP beyond the current charter were discarded, then I would make a consensus call discarding those arguments. --Sam From tony.li@tony.li Mon Mar 23 16:52:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E221B3A6C4F for ; Mon, 23 Mar 2009 16:52:00 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob7uUg-BWdzw for ; Mon, 23 Mar 2009 16:52:00 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id EEAC33A6B18 for ; Mon, 23 Mar 2009 16:51:59 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA06.westchester.pa.mail.comcast.net with comcast id Wk2l1b01S17dt5G56nsicZ; Mon, 23 Mar 2009 23:52:42 +0000 Received: from [127.0.0.1] ([130.129.65.195]) by OMTA13.westchester.pa.mail.comcast.net with comcast id WnsY1b00c4ClyMu3Znsins; Mon, 23 Mar 2009 23:52:49 +0000 Message-ID: <49C80509.9010306@tony.li> Date: Mon, 23 Mar 2009 14:54:17 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Noel Chiappa References: <20090318225402.9CE096BE599@mercury.lcs.mit.edu> In-Reply-To: <20090318225402.9CE096BE599@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:52:01 -0000 Noel Chiappa wrote: > > From: "Templin, Fred L" > > > Why would you like to see a stack identifier when you could have a true > > host identifier > > Because I don't want to have the upgrade the software on every host on the > entire Internet. More generally, it is not clear that the 'host' is truly the fundamental entity that you want to identify. Given virtualization and migration, do you really want to identify the physical chassis, or the logical, functional entity? It seems reasonable to me that the stack ID is more fundamental. Tony From hartmans@mit.edu Mon Mar 23 17:08:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7287928C158 for ; Mon, 23 Mar 2009 17:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-48ok97Q487 for ; Mon, 23 Mar 2009 17:08:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-46b4.meeting.ietf.org [130.129.70.180]) by core3.amsl.com (Postfix) with ESMTP id 630F028C1EE for ; Mon, 23 Mar 2009 17:08:04 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 257A94144; Mon, 23 Mar 2009 20:08:44 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Mon, 23 Mar 2009 20:08:44 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:08:08 -0000 Here is a proposed update to the charter that I hope addresses the concerns raised on the list. I want to stress that right now, this is just my comments. I have not run this by anyone else yet. So, I probably got things horribly wrong. First, I remove acronyms from the discussion of ID/LOC splits. Darrel discussed an idea with the authors of expanding EID as end-site identifier. I've picked that up in this version of the charter. I've significantly expanded the discussion of LISP to describe what EIDs are within the scope of this WG and some of their properties. I've also included a paragraph that I believe gives the three basic design constraints of LISP. I want that in the charter because I believe it is a scope limitation that will help the chairs. I want to stress that this proposed change is something I have not seen others asking for. Comments very welcome. The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation". The basic idea behind the separation that the Internet architecture combines two functions, Routing Locators, (where you are attached to the network) and Endpoint Identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple location and identity, thus allowing for efficient aggregation of the routing locator space and providing persistent identity in the identifier space. LISP supports the separation of the Internet address space into end-site Identifiers (EIDs) and Routing Locators (RLOCs) following a network-based map-and-encapsulate scheme (RFC 1955). Both LISP EIDs and RLOCs are IP addresses. LISP EIDs are composed of three parts: a portion that identifies an organization, a portion that identifies a subnet within an organization, and a portion that identifies an interface on that subnet. LISP maps only the upper portion of the EID; as a consequence a host would typically change EIDs when it moves from one organization to another or whenever it moves from one subnet to another within an organization. Generally, the same IP address cannot be used as both an EID and an RLOC, especially if the entities named by the EID and RLOC are different. LISP requires no changes to end-systems or to most routers. LISP aims for an incrimentally deployable protocol. A number of other approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the EID-to-RLOC mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications). Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG as Experimental Mar 2010 Submit base ALT specification to the IESG as Experimental Mar 2010 Submit the LISP Interworking specification to the IESG as Experimental June 2010 Submit the LISP Map Server specification to the IESG as Experimental June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 Submit a preliminary analysis as Informational Dec 2010 Re-charter or close. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From brian.e.carpenter@gmail.com Mon Mar 23 17:54:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE043A699A for ; Mon, 23 Mar 2009 17:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2KLEBiMn2Dp for ; Mon, 23 Mar 2009 17:54:51 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 79DD33A67D9 for ; Mon, 23 Mar 2009 17:54:51 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3017760wfg.31 for ; Mon, 23 Mar 2009 17:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=pPtb3DGz3BrBODXqhDYdlcHsb6TOCLaw3R8RVDx0pfE=; b=wlhmcPbOKHaFy6mkjQxUNmc7+5vqrkWB2/Wzs2GSUIxQLC4QfTVDKXS7Pz9H75OrDV 4n0+Rtlasekbw4ydWwjxsWGZZw6ZQG8p+Oh519Dq7U15uvbbnU3jJVNb49wlhslompXY NetYVqbMo9ww/6IwpwfnQF0EUVONz7sMdJtp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=yGhikFdlP39jdn1SxkvbYmORtgAA0Se/9NqSc0E2zqdGVxZHSpZLQF9W7pZIv4hg7y 0OinskDjV5dnKcSY92J3hsTN1fAEYoHQB5EeehhBa0Wao0jFl+gRALlAbuq5ce0cVZoC qIMY2VofAz5L2Hwm7JydGfCSL2lOPW6PZr2VA= Received: by 10.143.3.16 with SMTP id f16mr3107852wfi.344.1237856142135; Mon, 23 Mar 2009 17:55:42 -0700 (PDT) Received: from ?130.129.64.245? (dhcp-40f5.meeting.ietf.org [130.129.64.245]) by mx.google.com with ESMTPS id 24sm12488128wfc.57.2009.03.23.17.55.40 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Mar 2009 17:55:41 -0700 (PDT) Message-ID: <49C82F88.9050905@gmail.com> Date: Tue, 24 Mar 2009 13:55:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:54:52 -0000 Sam, As already hinted, I've written my last comment on terminology. The charter as written is completely neutral about IPv4 versus IPv6. I hope that doesn't conceal a hidden assumption. It might be wise to specify that both IPv4 and IPv6 will be supported. I would leave the question of mixed IPv4/IPv6 support aside for now, since so much else is bubbling in the v4/v6 coexistence area. Brian From jnc@mercury.lcs.mit.edu Mon Mar 23 17:57:25 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571C13A693F for ; Mon, 23 Mar 2009 17:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoY6-r9EX8vx for ; Mon, 23 Mar 2009 17:57:24 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id A53F33A67D9 for ; Mon, 23 Mar 2009 17:57:24 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4A34B6BE57F; Mon, 23 Mar 2009 20:58:14 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090324005814.4A34B6BE57F@mercury.lcs.mit.edu> Date: Mon, 23 Mar 2009 20:58:14 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:57:25 -0000 > From: Sam Hartman > If you were to propose an extension designed to make LISP work better > when an EID was mapped to a specific stack ID I'd say that was > currently out of scope. The extension, sure. I already said as much: >> I don't have any problem whatsoever with having the charter limit the output >> of the WG, as initially chartered .. to documents intended to support >> the [basic scenario] But what about, e.g., a field intended for later use in such an extension? Noel From menth@informatik.uni-wuerzburg.de Mon Mar 23 18:01:01 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697F53A6A43 for ; Mon, 23 Mar 2009 18:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Gi3bKQCbEDX for ; Mon, 23 Mar 2009 18:01:00 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 331923A69DB for ; Mon, 23 Mar 2009 18:01:00 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 79E8F199076; Tue, 24 Mar 2009 02:01:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 6D3AC19906F; Tue, 24 Mar 2009 02:01:50 +0100 (CET) Received: from [92.226.212.240] (g226212240.adsl.alicedsl.de [92.226.212.240]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 39E64199067; Tue, 24 Mar 2009 02:01:50 +0100 (CET) Message-ID: <49C830FF.2050900@informatik.uni-wuerzburg.de> Date: Tue, 24 Mar 2009 02:01:51 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: lisp@ietf.org Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de 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, 24 Mar 2009 01:01:01 -0000 Hi Sam, I am a bit puzzled about this part of the charter. > LISP EIDs are composed of three parts: a > portion that identifies an organization, a portion that identifies a > subnet within an organization, and a portion that identifies an > interface on that subnet. That makes the fact explicit that LISP EIDs are local locators. I thought this should not be the case, at least in theory in the long-term given the vision of LISP-in-the-hosts. Is that limitation required? What's the motivation behind it? Can the charter also do without it? > LISP maps only the upper portion of the > EID; What is the upper portion of this triple? The organization or the "interface identifier on that subnet"? What does this imply for mapping systems? Do they map (a) organization identifiers or (b) subnet interface identifiers to RLOCs then? (a) means that all EIDs of an organization have the same RLOCs. So it's rather a site of an organization, right? (b) means that "interfce identerfiers on that subnet" are globally unique, but that cannot be. > as a consequence a host would typically change EIDs when it moves > from one organization to another or whenever it moves from one subnet > to another within an organization. Does that mean that the EID is not bound to a special device, but to a location? If I get the assumption right, LISP seems to me more like a separation of global and site routing than separation of a locator and identifier since my intuitive understanding of an identifier is something that is independent of the location - or can be at least in theory somewhen in the far future. Sorry if the answers to my questions are trivial. I may have missed something in the previous discussions. Regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From swb@employees.org Mon Mar 23 18:17:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2CF23A6C4F for ; Mon, 23 Mar 2009 18:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUKrfxEuwObC for ; Mon, 23 Mar 2009 18:17:26 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C50A03A6C26 for ; Mon, 23 Mar 2009 18:17:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,410,1233532800"; d="scan'208";a="40182267" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Mar 2009 01:18:15 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2O1IFTx003313; Mon, 23 Mar 2009 21:18:15 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2O1IFEL011721; Tue, 24 Mar 2009 01:18:15 GMT Date: Mon, 23 Mar 2009 18:18:14 -0700 From: Scott Brim To: Sam Hartman Message-ID: <20090324011814.GJ51065@cisco.com> Mail-Followup-To: Scott Brim , Sam Hartman , lisp@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: lisp@ietf.org Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:17:26 -0000 Excerpts from Sam Hartman on Mon, Mar 23, 2009 08:08:44PM -0400: > The basic idea behind the separation that the Internet architecture > combines two functions, Routing Locators, (where you are attached to > the network) and Endpoint Identifiers (who you are) in one number > space: The IP address. Proponents of the separation architecture > postulate that splitting these functions apart will yield several > advantages, including improved scalability for the routing system. > The separation aims to decouple location and identity, thus allowing s/identity/identification/ > for efficient aggregation of the routing locator space and providing > persistent identity in the identifier space. It is not clear that any "persistent identity" is needed beyond domain names and URIs, so I would suggest that the charter just sidestep the issue: for efficient aggregation of the routing locator space and providing for location-independent identification. swb From hartmans@mit.edu Mon Mar 23 18:18:15 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACE13A6C65 for ; Mon, 23 Mar 2009 18:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMPCIBvrls+d for ; Mon, 23 Mar 2009 18:18:14 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.87.223]) by core3.amsl.com (Postfix) with ESMTP id D7FE53A6C4F for ; Mon, 23 Mar 2009 18:18:14 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D15DF4144; Mon, 23 Mar 2009 21:19:03 -0400 (EDT) To: menth@informatik.uni-wuerzburg.de References: <49C830FF.2050900@informatik.uni-wuerzburg.de> From: Sam Hartman Date: Mon, 23 Mar 2009 21:19:03 -0400 In-Reply-To: <49C830FF.2050900@informatik.uni-wuerzburg.de> (Michael Menth's message of "Tue\, 24 Mar 2009 02\:01\:51 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:18:15 -0000 >>>>> "Michael" == Michael Menth writes: Michael> Hi Sam, I am a bit puzzled about this part of the Michael> charter. >> LISP EIDs are composed of three parts: a portion that >> identifies an organization, a portion that identifies a subnet >> within an organization, and a portion that identifies an >> interface on that subnet. Michael> That makes the fact explicit that LISP EIDs are local Michael> locators. This clarification is the one thing I'm fairly sure we have consensus to do:-) Michael> I thought this should not be the case, at least Michael> in theory in the long-term given the vision of Michael> LISP-in-the-hosts. Is that limitation required? What's Michael> the motivation behind it? Can the charter also do without Michael> it? Several people have asked for this clarification, so my motivation was to address comments we've received. LISP-in-the-host is something I at least hope is out of scope for this WG. We're defining today's LISP. We will recharter when we change assumptions like we're talking about here. So, the point of putting this in the charter is that we want to have an explicit charter change (and thus an explicit level-set) with the IETF community if any of these assumptions change. I could see a future charter talking about how while LISP in RFC xxxx only mapped organizations, there is a desire to create an extension to LISP to bring EID mapping down to the host. That would be a major rechartering and would require significant community discussion. >> LISP maps only the upper portion of the EID; Michael> What is the upper portion of this triple? The Michael> organization or the "interface identifier on that Michael> subnet"? The organization. Organization is probably not the best term; end-site might be a better term actually. Michael> What does this imply for mapping systems? Do Michael> they map (a) organization identifiers or (b) subnet Michael> interface identifiers to RLOCs then? I'm still coming up to speed. I *think* it's a bit more complicated than that. Michael> (a) means that all EIDs of an organization have the same Michael> RLOCs. So it's rather a site of an organization, right? Rightish at least, possibly even completely right. >> as a consequence a host would typically change EIDs when it >> moves from one organization to another or whenever it moves >> from one subnet to another within an organization. Michael> Does that mean that the EID is not bound to a special Michael> device, but to a location? If I get the assumption right, Michael> LISP seems to me more like a separation of global and Michael> site routing than separation of a locator and identifier Michael> since my intuitive understanding of an identifier is Michael> something that is independent of the location - or can be Michael> at least in theory somewhen in the far future. Today's LISP EIDs definitely do seem to include aspects both of local location and of identification. From hartmans@mit.edu Mon Mar 23 18:21:47 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1D03A6C67 for ; Mon, 23 Mar 2009 18:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9267vYNPAmp for ; Mon, 23 Mar 2009 18:21:46 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.87.223]) by core3.amsl.com (Postfix) with ESMTP id 6D2453A6C65 for ; Mon, 23 Mar 2009 18:21:46 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A28544148; Mon, 23 Mar 2009 21:22:26 -0400 (EDT) To: Scott Brim References: <20090324011814.GJ51065@cisco.com> From: Sam Hartman Date: Mon, 23 Mar 2009 21:22:26 -0400 In-Reply-To: <20090324011814.GJ51065@cisco.com> (Scott Brim's message of "Mon\, 23 Mar 2009 18\:18\:14 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:21:47 -0000 I'd appreciate others' comments. I support both of Scott's changes below. >>>>> "Scott" == Scott Brim writes: Scott> Excerpts from Sam Hartman on Mon, Mar 23, 2009 08:08:44PM Scott> -0400: >> The basic idea behind the separation that the Internet >> architecture combines two functions, Routing Locators, (where >> you are attached to the network) and Endpoint Identifiers (who >> you are) in one number space: The IP address. Proponents of the >> separation architecture postulate that splitting these >> functions apart will yield several advantages, including >> improved scalability for the routing system. The separation >> aims to decouple location and identity, thus allowing Scott> s/identity/identification/ >> for efficient aggregation of the routing locator space and >> providing persistent identity in the identifier space. Scott> It is not clear that any "persistent identity" is needed Scott> beyond domain names and URIs, so I would suggest that the Scott> charter just sidestep the issue: Scott> for efficient aggregation of the routing locator space Scott> and providing for location-independent identification. Scott> swb From hartmans@mit.edu Mon Mar 23 18:26:39 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C681D28C271 for ; Mon, 23 Mar 2009 18:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMp-v-qSdPbK for ; Mon, 23 Mar 2009 18:26:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.87.223]) by core3.amsl.com (Postfix) with ESMTP id 2CCBC28C1E2 for ; Mon, 23 Mar 2009 18:26:39 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 761EC4148; Mon, 23 Mar 2009 21:27:27 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090324005814.4A34B6BE57F@mercury.lcs.mit.edu> From: Sam Hartman Date: Mon, 23 Mar 2009 21:27:27 -0400 In-Reply-To: <20090324005814.4A34B6BE57F@mercury.lcs.mit.edu> (Noel Chiappa's message of "Mon\, 23 Mar 2009 20\:58\:14 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:26:39 -0000 >>>>> "Noel" == Noel Chiappa writes: Noel> But what about, e.g., a field intended for later use in such Noel> an extension? That too would be out of scope. A field for future extensibility. . . could be OK. I definitely think we should be having this scope discussion now and establish clear limits. From jnc@mercury.lcs.mit.edu Mon Mar 23 19:05:11 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFC128C1A8 for ; Mon, 23 Mar 2009 19:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntMuApoEdzzw for ; Mon, 23 Mar 2009 19:05:11 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 1235D3A69C4 for ; Mon, 23 Mar 2009 19:05:10 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C69626BE597; Mon, 23 Mar 2009 22:06:00 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090324020600.C69626BE597@mercury.lcs.mit.edu> Date: Mon, 23 Mar 2009 22:06:00 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 02:05:11 -0000 > From: Sam Hartman >> But what about, e.g., a field intended for later use in such >> an extension? > That too would be out of scope. > A field for future extensibility. . . could be OK. I guess I don't understand the difference between the two. Note that I did say "a field ... for later use", and I don't quite see how that's different from "a field for future extensibility". I am _not_ trying to argue for the inclusion of any substantial text (beyond a sentence or two describing the field, in whatever document describes that packet format), i.e. the extension itself would _not_ be documented, nor would a document about it be an output document of the current WG. Noel From jnc@mercury.lcs.mit.edu Mon Mar 23 19:25:08 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C230A3A6A92 for ; Mon, 23 Mar 2009 19:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Gc9MBj3DcTE for ; Mon, 23 Mar 2009 19:25:07 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 66A6B3A6836 for ; Mon, 23 Mar 2009 19:25:07 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3D4756BE578; Mon, 23 Mar 2009 22:25:56 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090324022557.3D4756BE578@mercury.lcs.mit.edu> Date: Mon, 23 Mar 2009 22:25:56 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 02:25:08 -0000 > From: Sam Hartman > Darrel discussed an idea with the authors of expanding EID as end-site > identifier. That's not really correct, though, because an _individual_ LISP EID names an individual host (well, perhaps even an interface, as Fred Templin pointed out). So they don't identify "sites". If the term 'LISP EID' is not acceptable, I suggest you pick a term which i) recognizes that an individual example names an individual 'something' (machine or interface), and ii) properly captures the ambiguity, and potentially changing semantics, of the LISP EID. E.g. something like 'LISP device name'. (I picked 'device' to be deliberately amniguous as to whether an LEID names a host or an interface, to avoid semi-endless debates about what it does name. :-) Comments on the draft charter: > In general, these proposals are based on the "Locator/Identifier > separation". I think 'location and identity separation' is a better term. (I tend to use 'separation of location and identity', actually, preferring the flow of that version.) "Locator", as originally defined in RFC-1992, is a particular kind of name, not a generic concept. (If anyone looks at RFC-1992, the term 'node' in that document means 'node in an RFC-1992 map', not 'node' in the more generic sense.) > the Internet architecture combines two functions, Routing Locators, > (where you are attached to the network) and Endpoint Identifiers (who > you are) in one number space: The IP address. "Locators" and "Endpoint Identifiers" are particular _kinds_ of name; to describe "functions", terms like 'location, for the purposes of routing' and 'identity, for use in end-end interactions' would be more apropos. Also, did you want to mention how the internet architecture also confuses whether what is being named by an IP address is an interface, or the host itself ('stack', if one wishes)? Making this point is not necessary, if you think it will distract. > end-site Identifiers (EIDs) Same comment as above about "site". > LISP EIDs are composed of three parts: a portion that identifies an > organization, a portion that identifies a subnet within an > organization, and a portion that identifies an interface on that subnet Ah, one 'organization' might have multiple ETRs, and multiple LEID blocks (and RLOC sets associated with each one), so I think 'site' is better than 'organization'. Also, not all sites will adopt that two-layer division internally. I think this would better put as: LISP EIDs are composed of two parts: a 'global' portion that uniquely identifies a particular site, and a 'local' portion which identifies a device within that site. The 'local' portion may be further subdivided internal to a site, e.g. to identify a particular physical network within that site, and a device on that network, but that division may not be visible outside the site. Again, 'device' is deliberately ambiguous. > Generally, the same IP address cannot be used as both an EID and an > RLOC, especially if the entities named by the EID and RLOC are > different. I'm not sure about this; if routes are tagged as to whether they are routes to 'legacy' addresses , LEIDs or RLOCs, (which I claim they will almost certainly have to be, to enable routing efficiencies by restricting the scopes over which they are carried), one could indeed have a particular 32-bit value used as both an EID and an RLOC (and in different places). Do we need to cover this in the charter, or can we just drop this sentence? > The LISP WG is chartered to work on the LISP base protocol > (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system > (draft-fuller-lisp-alt-05.txt), LISP Interworking > (draft-lewis-lisp-interworking-02.txt), LISP Map Server > (draft-fuller-lisp-ms-00.txt), and LISP multicast > (draft-farinacci-lisp-multicast-01.txt) This wording might be taken to read as saying only these documents can be produced. I wonder if that will be too limiting (e.g. if we want to split draft-farinacci-lisp-12.txt into, say a 'LISP Overview' document and a 'LISP protocol specification' document)? Is there some way to clarify that? Also, I wonder what will happen if, in the course of deploying testbeds, we decide we need something else (like the Map Server thing, which is a _very_ recent addition). Would we have to modify the charter if we decide we need something else to get the test-bed operational? The rest looks fine. Noel From rw@firstpr.com.au Mon Mar 23 19:45:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E493A6C56 for ; Mon, 23 Mar 2009 19:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFqTfoMZ-wgC for ; Mon, 23 Mar 2009 19:45:05 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 295043A6C52 for ; Mon, 23 Mar 2009 19:45:04 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 8C0B217573D; Tue, 24 Mar 2009 13:45:53 +1100 (EST) Message-ID: <49C84962.7040904@firstpr.com.au> Date: Tue, 24 Mar 2009 13:45:54 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 02:45:06 -0000 Hi Sam, I support the critiques of your new text by Michael Menth and Scott Brim: http://www.ietf.org/mail-archive/web/lisp/current/msg00317.html http://www.ietf.org/mail-archive/web/lisp/current/msg00318.html I think it involves too much low level detail and that quite a few of those details are incorrect or not conducive to either explaining LISP or to clearly defining the scope of the WG. I share Noel's concern about being unable to understand the difference between what he asked for and what you offered, which you apparently consider to be different: http://www.ietf.org/mail-archive/web/lisp/current/msg00322.html I think the suggestions I made: http://www.ietf.org/mail-archive/web/lisp/current/msg00286.html would be better than the new text you added, for reasons I discussed here: http://www.ietf.org/mail-archive/web/lisp/current/msg00298.html http://www.ietf.org/mail-archive/web/lisp/current/msg00309.html - Robin From rw@firstpr.com.au Mon Mar 23 23:33:38 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8593A6C9F for ; Mon, 23 Mar 2009 23:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDkJ1Pm+IXWU for ; Mon, 23 Mar 2009 23:33:37 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 602FE3A6CA3 for ; Mon, 23 Mar 2009 23:33:36 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id AB706175AB0; Tue, 24 Mar 2009 17:34:25 +1100 (EST) Message-ID: <49C87EF2.3050703@firstpr.com.au> Date: Tue, 24 Mar 2009 17:34:26 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lisp@ietf.org References: <20090321172350.C5A0A6BE571@mercury.lcs.mit.edu> In-Reply-To: <20090321172350.C5A0A6BE571@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Noel Chiappa Subject: Re: [lisp] I can find only one definition of "namespace" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 06:33:39 -0000 Short version: I think we all agree about the definition of "namespace". I still hope to encourage someone to explain how LISP could use separate namespaces for EIDs than for RLOCs within the constraint that this form of LISP is part of a practical scaling routing solution: one which must be voluntarily adopted on a wide scale, and therefore must be fully functioning without any changes to hosts or to the interdomain routing system. Hi Noel, You wrote: >> The most notable document making frequent references (44 at least) to >> "namespace" in ways which entirely accord with the definitions I found, >> was Noel Chiappa in an unfinished draft of an I-D, which is nonetheless >> cited quite frequently > > I have to admit there's a certain droll humour in having _my own flipping > document_ being cited to tell me I don't know what the hell I'm talking > about... > > But I see the irony has escaped you. Not at all - I just didn't mention it. I think you have a perfectly good understanding of what "namespace" means. However, I think you are mistaken if you support the view that LISP, as a practical solution to the routing scaling problem, could involve separate namespaces for RLOCs and EIDs. (I know LISP could do this, but not in a way which is part of a practical solution at the time of introduction and in the years which follow.) Neither you nor anyone else has yet described, by way of an example, exactly what this "LISP involves separate namespaces for RLOC vs. EID" claim means and why it is valid for a practical routing scaling problem. There are inferences about this in two current LISP I-Ds, as noted at the end of: http://www.ietf.org/mail-archive/web/lisp/current/msg00273.html This also links to an IETF Journal article which is explicit about separate namespaces. Also, two presentations currently linked to from http://www.lisp4.net: http://www.lisp4.net/docs/lisp-crc-aam-workshop.ppt (2008-03) http://www.lisp4.net/docs/lisp-ripe-long.pdf (2008-05) both state: Why Separate Location from ID? Level of Indirection allows us to: Keep either ID or Location fixed while changing the other Create _separate_namespaces_ which can have different allocation properties This is the big distinction between LISP and HIP (and I guess some other potential solutions to the routing scaling problem which also involve separate namespaces for EIDs and RLOCs): HIP is not a practical solution because it requires hosts use a different kind of address for EIDs, involving a different namespace from what IPv4 or IPv6 hosts use today. This requires modifications to hosts. (For HIP to a practical solution for the routing scaling problem, first all existing hosts would need to be converted to IPv6, with the HIP extensions. Then they would all need IPv6 connectivity - and their applications would need to be rewritten for IPv6 and I think for HIP.) LISP does not require separate namespaces: It can work nicely with both RLOCs and EIDs sharing the one namespace. Therefore, it can be used with existing IPv4(6) hosts and the existing IPv4(6) interdomain routing system. So LISP could be practical for widespread voluntary deployment while HIP or any other system which requires a new namespace for EIDs and/or RLOCs could never become useful without a wholesale upgrade to all hosts and/or all DFZ routers. As I wrote: http://www.firstpr.com.au/ip/ivip/namespace/ in your document: http://ana.lcs.mit.edu/~jnc/tech/endpoints.txt (BTW, I hope that site is stable, because this page seems to be cited by dozens of other documents, and other pages at this site are also frequently cited in discussion lists, papers, I-Ds etc.) I counted 44 or so usages of "namespace", all of which accord with the meaning you describe below, and which I have found is the only meaning ever associated with the term in the context of computer science and network addressing. No other document I found in the networking field comes close to this number of uses of the term "namespace". > An important defining characteristic of a namespace is the _semantics_ of the > names, not just their _syntax_. Two namespaces may have similar syntax, but > different semantics (e.g. disk block numbers and memory locations). This exactly accords with my understanding of "namespace" - and as far as I can tell with everyone else's understanding, including your's now and in the past. > It is the difference in the semantics of legacy IPvN addresses, > LISP EIDs, and RLOCs that make them separate namespaces, even > though they are identical syntactically. As I have argued before, and will argue again below, if LISP is to be a practical solution to the routing scaling problem, it _can't_ use separate namespaces for RLOCs and EIDs. If a practical application of LISP to the routing scaling problem did involve separate namespaces for RLOCs and EIDs, then it would be possible for the one numeric address, such as 11.22.33.44, to be usable as an RLOC and as an EID at the same time. But this is impossible because for global communications, the ITR needs to work within the IPv4 Global Unicast namespace for both traffic packets (an EID usage of an address) and for getting packets to ETRs (an RLOC usage of an address). There's no way an ITR could emit a packet tunneled to 11.22.33.44 and have it get to the destination RLOC while it regards 11.22.33.44 as being an EID address. The latter would involve it looking up the mapping for 11.22.33.44 and encapsulating it to some RLOC address. > Look, you don't like LISP. We get that. You think it's a bad idea. We get > that. So why don't you go start your own WG, create your own documents, write > your own code? Being obstructive about LISP is not doing anyone any good at > all. I do create my own documents and would be glad of some critiques, on the RRG list: http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-01 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01 http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf (With Steve Russert.) My critiques are well intentioned and constructive. I am trying to draw you and other LISP folks into genuine discussion and help other people understand what I think are the limitations of the approaches you have chosen. I am not making broad-brush, disrespectful comments about LISP-ALT. Nor am I ignoring it as unworthy of discussion. Discussing these things helps me and hopefully other people learn about scalable routing. You or anyone else can point out why my critique doesn't apply to LISP-ALT or why the critique is faulty in its logic, value judgements etc. My list of LISP critiques is not complete, but it is a good starting point for people who want to understand LISP-ALT and the reasons why some people, not just me, think it is not going to be the best or even a practical solution to the routing scaling problem in anything like its current form. http://www.firstpr.com.au/ip/ivip/lisp-links/ Please describe a situation in which LISP could be a practical solution to the routing scaling problem in which LISP introduces separate namespaces for EIDs and/or RLOCs: that is separate semantics for the one individual name (the one particular IP address) with the one address being usable as both an EID and an RLOC. For the mathematically inclined, here is my argument about why LISP or any other scalable routing system cannot be both practical (for smooth adoption without completely revising the routing system and/or all hosts) and use separate namespaces for RLOCs and EIDs. Initially I will consider the IPv4 Internet, which is the only one which matters at present, since it is the only one with global reach and which 100% of all actually used hosts are connected to. (Not counting experimental networks.) 1 - There are two aspects of the Internet which any potentially practical core-edge separation scheme such as LISP, APT or Ivip absolutely relies upon: a - The current behavior of all hosts. b - The current behavior of the internal and interdomain routing systems - especially the interdomain system, since it is conceivable that an ISP adopting the scheme could upgrade its internal system. 2 - The current state of the IPv4 Internet is that all hosts and routers use the one address space: IPv4. Broadly speaking we can think of this address space having a single namespace. In fact, within the 2^32 address range, there are sections such as 10.0.0.0/8 where there is a separate namespace for each network which uses such addresses. What really matters for any scalable routing solution is the "IPv4 Global Unicast" namespace. This is because the only existing global IP network with universal host connectivity uses this namespace for all its off-site communications and for all its routing system. 3 - A practical scalable routing solution can't be introduced by force or require upgrading all hosts or all the routers in the DFZ. (A possible exception to the latter restriction is [1].) 4 - A practical scalable routing solution for IPv4 therefore must have its EID addresses be 100% compatible with existing hosts. (At least for offsite communications.) 5 - A practical scalable routing solution for IPv4 therefore must have its RLOC addresses be 100% compatible with existing DFZ routers. 6 - Since both the DFZ and all existing hosts rely on the IPv4 address range and, for all offsite communications, use this address range according to the IPv4 Global Unicast namespace, it follows that any practical scalable routing system must have both its RLOC and EID addresses using the same IPv4 Global Unicast namespace. Of course the technology of LISP or APT or Ivip or whatever could be used for other purposes, including separate namespaces for RLOCs and EIDs. Also, over time, it is possible and probably desirable for the scheme to be able to support separate namespaces. However, during introduction (say 10 years or more) it is absolutely essential that the RLOC addresses and EID addresses work with all hosts and all DFZ routers, which means they both must use the same IPv4 Global Unicast namespace. It so happens that there is another network which is potentially capable of being used by hosts and for ITR <--> ETR communications: IPv6. It is far from being available to all ISPs, and it is only used by a tiny fraction of hosts. A scalable routing solution could use IPv6 DFZ communication between ITRs and ETRs when carrying packets addressed to IPv4 EIDs. This would be an instance of using separate namespaces for: EID: IPv4 Global Unicast namespace RLOC: IPv6 Global Unicast namespace However, this must be an option and cannot be assumed as part of the introduction of the scalable routing system. The scalable routing system needs to be easily adoptable for all ISPs. Not all ISPs use IPv6. LISP requires the ETRs and ITRs to be run by the end-user network, and not every end-user network necessarily wants to be messing with IPv6 either. AFAIK, there is no advantage whatsoever in using IPv6 for RLOCs. Every ISP which could use IPv6 already has IPv4 - and for a long time there would be no problem finding a few RLOC addresses for every end-user network which adopted LISP. So you *could* use LISP with separate namespaces for RLOCs and EIDs - but only as an option, with no obvious benefit. These separate namespaces are not the creation of LISP, it is just a choice to use two separate networks, with two separate global unicast namespaces. Likewise, LISP, or any other scalable routing solution, could carry traffic packets addressed to IPv6 EIDs using IPv4 RLOCs. As above, it would need to be an option, rather than a requirement of the basic system for mass voluntary adoption. In this case, there could be an advantage, since it would enable an end-user network to communicate with IPv6 without a native IPv6 connection, (assuming there were well-placed IPv6 PTRs able to tunnel to the IPv4 RLOC ETRs in its network. You could easily invent some other namespaces for RLOCs and/or EIDs. However, for LISP to be practical (widely voluntarily adopted without the need to change hosts or the DFZ routers), those namespaces are of no use at all. LISP as a practical solution to the routing scaling problem, there are only two "global" networks which matter (and IPv6 is only potentially global). The namespaces used in these two networks are: IPv4 Global Unicast namespace: All DFZ routers and all hosts - AKA the IPv4 Internet. IPv6 Global Unicast namespace: Some DFZ routers and a few hosts - AKA the IPv6 Internet. If you think my critique is wrong, please explain why. - Robin [1] It is possible (I think highly likely) that by the time we really need a scalable routing solution for IPv6 that there will have been time to upgrade all DFZ routers to implement the IPv6 version of Modified IP Header Forwarding: http://www.firstpr.com.au/ip/ivip/ivip6/ Maybe we could upgrade the DFZ and some other routers in time for introducing an IPv4 scalable routing, according to: http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw Doing so would save a lot of complexity in ITRs and ETRs, since there would be no PMTUD problems to solve. Also, these approaches involve no encapsulation overhead. From olivier.bonaventure@uclouvain.be Tue Mar 24 08:12:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6093A6D23 for ; Tue, 24 Mar 2009 08:12:40 -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_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V29yC7KDBH4k for ; Tue, 24 Mar 2009 08:12:39 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id CDBA03A6D00 for ; Tue, 24 Mar 2009 08:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=JzoWMS/nH4kERtuGC1mFh5CwMOI=; b=cwYBm2xdON JIZXS+ue2vsEYaHj1fBTLjqJfc+CDuV3Bs7XYg/aYAJNWpDgNhtjxo9sF2bSeaED Op26L9XHxeoCwSYZsVLfpEumptD61pvbtLNzqnO6zgFXrncnqxA7sBdhaHhk7dnq zjM9yuvn0WfVaZWP9KOxufW/O0mre4B3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=GSCg0 QcQpN+y++gMiWZmax5F9krHMJcxy/IkeToPRpPrhwQZk/FlPfsleyedPbXg6UUt2 LsqZo40gmuiS2AI0K1HDn4BLkCR7riiPRPJkP3VPrm20q/FQHWGeGEZDOi0t1KpI nNyJELeH+YwheeArlNS1q0dQTFdjlYd8FwmSSE= Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Tue, 24 Mar 2009 16:13:30 +0100 (CET) Message-ID: <49C8F88C.9090404@uclouvain.be> Date: Tue, 24 Mar 2009 16:13:16 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Roque Gagliano , lisp@ietf.org References: <83B62425-E996-4A8C-9D7F-B78E363E3C3E@lacnic.net> In-Reply-To: <83B62425-E996-4A8C-9D7F-B78E363E3C3E@lacnic.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: DA374F2020.CA154 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: Re: [lisp] Using Signed object to validate entries in Mapping Database: draft-lisp-rgaglian-ioa-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 24 Mar 2009 15:12:40 -0000 Roque, > > As mentioned some months ago in the lisp-interest mailing list I believe > that the work in SIDR WG can be somehow used to verify authority of the > entries on the mapping database, particularly for LISP but in general > for Map&Encap solutions. > > I compiled a first draft and I am sorry that did not make it to the cut > date. The draft can be downloaded at: > http://iie.fing.edu.uy/~rgaglian/drafts/draft-lisp-rgaglian-ioa-00.txt Thanks for this draft. Securing the mapping system is an important problem that hasn't received enough attention on the lisp mailing list. I hope that once the nitty details of the charter have been sorted out we'll be able to have technical discussions on this topic on the mailing list. > The idea is to generate a CMS signed object where an EID (or set of EID) address holder can sign the authority for a set of RLOC to be associated with them in the mapping database. I call this objects IOA. > > The verification can be done by: > - the mapping system before accepting an entry in the mapping database. > - the mapping clients to verify the answers from the mapping system. This is a possible approach. It would be interesting to discuss how the IOA would be discributed ? One option could be a central repository such as a RIR containing all the IOAs Another option could be to include the IOA in the mapping reply or the url of the IOA in the mapping reply. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From hartmans@mit.edu Tue Mar 24 09:16:59 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90A028C2D7 for ; Tue, 24 Mar 2009 09:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ9kMxuIB76j for ; Tue, 24 Mar 2009 09:16:59 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.87.223]) by core3.amsl.com (Postfix) with ESMTP id 1EF7228C2AF for ; Tue, 24 Mar 2009 09:16:58 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 666B94144; Tue, 24 Mar 2009 12:17:47 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090324020600.C69626BE597@mercury.lcs.mit.edu> From: Sam Hartman Date: Tue, 24 Mar 2009 12:17:47 -0400 In-Reply-To: <20090324020600.C69626BE597@mercury.lcs.mit.edu> (Noel Chiappa's message of "Mon\, 23 Mar 2009 22\:06\:00 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:16:59 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Sam Hartman >>> But what about, e.g., a field intended for later use in such >>> an extension? >> That too would be out of scope. A field for future >> extensibility. . . could be OK. Noel> I guess I don't understand the difference between the two. Ok. I guess the question is whether the field has a specific meaning that is beyond what we're doing today. If it does, then we run into problems where we have to discuss whether we believe that's a good idea. If the field is simply some field that might support unspecified evolution and we're applying the general criteria of protocol extensibility and good engineering design and we don't have to build consensus on some specific evolutionary path, then that's totally fine. From hartmans@mit.edu Tue Mar 24 09:36:49 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6B53A66B4 for ; Tue, 24 Mar 2009 09:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.543 X-Spam-Level: X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_71=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUNY5cWOxZlr for ; Tue, 24 Mar 2009 09:36:48 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.87.223]) by core3.amsl.com (Postfix) with ESMTP id A739B3A6CC2 for ; Tue, 24 Mar 2009 09:36:48 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 11C114144; Tue, 24 Mar 2009 12:37:40 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090324022557.3D4756BE578@mercury.lcs.mit.edu> From: Sam Hartman Date: Tue, 24 Mar 2009 12:37:40 -0400 In-Reply-To: <20090324022557.3D4756BE578@mercury.lcs.mit.edu> (Noel Chiappa's message of "Mon\, 23 Mar 2009 22\:25\:56 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:36:49 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Sam Hartman Darrel discussed an >> idea with the authors of expanding EID as end-site identifier. Noel> That's not really correct, though, because an _individual_ Noel> LISP EID names an individual host (well, perhaps even an Noel> interface, as Fred Templin pointed out). So they don't Noel> identify "sites". Noel> If the term 'LISP EID' is not acceptable, I suggest you pick Noel> a term which i) recognizes that an individual example names Noel> an individual 'something' (machine or interface), and ii) Noel> properly captures the ambiguity, and potentially changing Noel> semantics, of the LISP EID. E.g. something like 'LISP device Noel> name'. (I picked 'device' to be deliberately amniguous as to Noel> whether an LEID names a host or an interface, to avoid Noel> semi-endless debates about what it does name. :-) I think it's very clear that it names an interface within the scope of LISP that we are chartering. Noel> Comments on the draft charter: >> In general, these proposals are based on the >> "Locator/Identifier separation". Noel> I think 'location and identity separation' is a better Noel> term. (I tend to use 'separation of location and identity', Noel> actually, preferring the flow of that version.) I didn't change this part other than to remove acronyms. We've seen an explicit request from Scott to remove identity where I used it. At least in the applications area, never using the term identity definitely seems to be the running approach. Noel> Also, did you want to mention how the internet architecture Noel> also confuses whether what is being named by an IP address Noel> is an interface, or the host itself ('stack', if one Noel> wishes)? Making this point is not necessary, if you think it Noel> will distract. I was not actually changing this part of the charter. >> end-site Identifiers (EIDs) Noel> Same comment as above about "site". I'd like some expansion for the acronym. I'm not overly attached to what it is:-) I suspect that end-site will make a few people happier, although I agree with your comment that it is ambiguous. >> LISP EIDs are composed of three parts: a portion that >> identifies an organization, a portion that identifies a subnet >> within an organization, and a portion that identifies an >> interface on that subnet Noel> Ah, one 'organization' might have multiple ETRs, and Noel> multiple LEID blocks (and RLOC sets associated with each Noel> one), so I think 'site' is better than 'organization'. I agree. Noel> Also, Noel> not all sites will adopt that two-layer division Noel> internally. I think this would better put as: How with LISP as we are scoping it today can you avoid some internal subnetting? Noel> LISP EIDs are composed of two parts: a 'global' portion Noel> that uniquely identifies a particular site, and a 'local' Noel> portion which identifies a device within that site. The I'd like to say that the global portion is what is mapped into an RLOC. Also, I'd like to say interface rather than device. Besides that I think your wording is much better than mine. Noel> Noel> 'local' portion may be further subdivided internal to a Noel> site, e.g. to identify a particular physical network within Noel> that site, and a device on that network, but that division Noel> may not be visible outside the site. >> Generally, the same IP address cannot be used as both an EID >> and an RLOC, especially if the entities named by the EID and >> RLOC are different. Noel> I'm not sure about this; if routes are tagged as to whether Noel> they are routes to 'legacy' addresses , LEIDs or RLOCs, Noel> (which I claim they will almost certainly have to be, to Noel> enable routing efficiencies by restricting the scopes over Noel> which they are carried), one could indeed have a particular Noel> 32-bit value used as both an EID and an RLOC (and in Noel> different places). I do think we need to say something here. I'm not sure I said a factually correct thing, but I think that a case where the same 32-bit number was used for an RLOC and an unrelated EID would be a significant difference from LISP today. So, I'm not sure what we say here, but I think Robin's concerns as well as Margaret's call for something to be said answering to what extent we expect EIDs and RLOCs to overlap.m From darlewis@cisco.com Tue Mar 24 10:38:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1691928C10C for ; Tue, 24 Mar 2009 10:38:51 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NymsHO5ktJGg for ; Tue, 24 Mar 2009 10:38:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2E67628C114 for ; Tue, 24 Mar 2009 10:38:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,413,1233532800"; d="scan'208";a="160867039" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2009 17:32:11 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2OHWBfN021281; Tue, 24 Mar 2009 10:32:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2OHWB8X009861; Tue, 24 Mar 2009 17:32:11 GMT Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 10:32:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 10:32:10 -0700 Message-ID: <60C4A248E730F249990993E3B9BD44D8077E4C3B@xmb-sjc-218.amer.cisco.com> In-Reply-To: <49C82F88.9050905@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] My proposed revisions to the charter Thread-Index: AcmsG0Oa3EXwS6ACRSy5wOpWXQDdZgAichqA References: <49C82F88.9050905@gmail.com> From: "Darrel Lewis (darlewis)" To: "Brian E Carpenter" , "Sam Hartman" X-OriginalArrivalTime: 24 Mar 2009 17:32:11.0130 (UTC) FILETIME=[769CB5A0:01C9ACA6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1168; t=1237915931; x=1238779931; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20My=20proposed=20revisions=20to =20the=20charter |Sender:=20; bh=gLQl16baCD7xMkbDE3aSDxa7tS2qIr+vl8K+ZB8QXzA=; b=DZZ0p2EjhJeV0ScB54jRCNcDK2lUddC5/GNybZQDnhJGbdeiLCqfql5Hh2 u9a+5U71TGBPz1x4WSjfrPjl51fiK1CJqmtggkyhD2Ir9bpW5eT5nv4HRUDO 6MmyJi1vsW; Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 17:38:51 -0000 > Sam, >=20 > As already hinted, I've written my last comment on terminology. >=20 > The charter as written is completely neutral about IPv4 versus IPv6. > I hope that doesn't conceal a hidden assumption. It might be=20 > wise to specify that both IPv4 and IPv6 will be supported. > I would leave the question of mixed IPv4/IPv6 support aside=20 > for now, since so much else is bubbling in the v4/v6 coexistence area. >=20 Brian,=20 >From my perspective the LISP core specs are very explicit in their support for both IPv4 and IPv6. In addition to specifying this same-AFI encapsulation (4-to-4 over 4 and 6-to-6 over 6) they also are explicit in supporting both the encapsulation IPv6 EIDs in LISP packets which have IPv4 RLOCs (6-to-6 over 4), and the encapsulation of IPv4 EIDs in LISP packets witch have IPv6 RLOCs (4-to-4 over 6). These capabilities seem to me an important response to the protocol's stated design goals incremental deployability and practical utility. I personally don't think that the charter needs to dive into this level of detail - but if you think so perhaps you could offer some suggested text? -Darrel From brian.e.carpenter@gmail.com Tue Mar 24 11:15:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1406128C299 for ; Tue, 24 Mar 2009 11:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTGlmsA1LYaw for ; Tue, 24 Mar 2009 11:15:25 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 1AE2E28C26B for ; Tue, 24 Mar 2009 11:15:25 -0700 (PDT) Received: by qyk36 with SMTP id 36so3239276qyk.29 for ; Tue, 24 Mar 2009 11:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yohfeaTuCHrVpBqbs9byif9AXb/T/YpT5vUOussS/k0=; b=RQynheu0NdBgedC2eJbmIZjDxEx+0lV9FE2f7nglwr8/jPIKsjb6M3UdtYIJ5VZoEM /h/dB3AngskWwi2d86gw02U+LGKRJj2Pu/EBbOITnA3/9p/gnzFmaUDwuH7ec8OPkrwB 589bI8a7ijFmbjI2S+kLF1Qgsx9gZrGeSUalc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=cEY2Q1yrQTHZedZcNmBIKoPs0oFHEgEaYE18DjvX6EvsCfPFzICsonFqMhuSEXaAXv cqf73P+BH4iNrZW28TVGMUX8QWDN+Z6XAjIhF5o6c9HDbKLHulJbh5HDSIQcYUL4q0QG 1iMG5RLFGiSO+wLFydHmfO98fcTTcd85hPoq8= Received: by 10.142.237.19 with SMTP id k19mr3498513wfh.209.1237918575372; Tue, 24 Mar 2009 11:16:15 -0700 (PDT) Received: from ?130.129.18.229? (dhcp-12e5.meeting.ietf.org [130.129.18.229]) by mx.google.com with ESMTPS id 30sm13860298wfc.44.2009.03.24.11.16.14 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Mar 2009 11:16:14 -0700 (PDT) Message-ID: <49C9236A.4060509@gmail.com> Date: Wed, 25 Mar 2009 07:16:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Darrel Lewis (darlewis)" References: <49C82F88.9050905@gmail.com> <60C4A248E730F249990993E3B9BD44D8077E4C3B@xmb-sjc-218.amer.cisco.com> In-Reply-To: <60C4A248E730F249990993E3B9BD44D8077E4C3B@xmb-sjc-218.amer.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 18:15:26 -0000 On 2009-03-25 06:32, Darrel Lewis (darlewis) wrote: >> Sam, >> >> As already hinted, I've written my last comment on terminology. >> >> The charter as written is completely neutral about IPv4 versus IPv6. >> I hope that doesn't conceal a hidden assumption. It might be >> wise to specify that both IPv4 and IPv6 will be supported. >> I would leave the question of mixed IPv4/IPv6 support aside >> for now, since so much else is bubbling in the v4/v6 coexistence area. >> > > Brian, > >>From my perspective the LISP core specs are very explicit in their > support for both IPv4 and IPv6. In addition to specifying this same-AFI > encapsulation (4-to-4 over 4 and 6-to-6 over 6) they also are explicit > in supporting both the encapsulation IPv6 EIDs in LISP packets which > have IPv4 RLOCs (6-to-6 over 4), and the encapsulation of IPv4 EIDs in > LISP packets witch have IPv6 RLOCs (4-to-4 over 6). These capabilities > seem to me an important response to the protocol's stated design goals > incremental deployability and practical utility. > > I personally don't think that the charter needs to dive into this level > of detail - but if you think so perhaps you could offer some suggested > text? Darrel, Thanks. The most I would suggest is that the second occurrence of "IP" becomes "IPv4 or IPv6", so we'd have Both LISP EIDs and RLOCs are IPv4 or IPv6 addresses. Brian From darlewis@cisco.com Tue Mar 24 13:24:04 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8694D28C33D for ; Tue, 24 Mar 2009 13:24:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdjI6ul6iQHT for ; Tue, 24 Mar 2009 13:24:03 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DFDBF3A6C49 for ; Tue, 24 Mar 2009 13:23:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,414,1233532800"; d="scan'208";a="160968664" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2009 20:24:28 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2OKOQul019038; Tue, 24 Mar 2009 13:24:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2OKOQWQ002299; Tue, 24 Mar 2009 20:24:26 GMT Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 13:24:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 13:24:24 -0700 Message-ID: <60C4A248E730F249990993E3B9BD44D8077E4DA0@xmb-sjc-218.amer.cisco.com> In-Reply-To: <49C9236A.4060509@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] My proposed revisions to the charter Thread-Index: AcmsrJ++m19tQ2XHQY63TmagJ1Nn1QAEdcqA References: <49C82F88.9050905@gmail.com> <60C4A248E730F249990993E3B9BD44D8077E4C3B@xmb-sjc-218.amer.cisco.com> <49C9236A.4060509@gmail.com> From: "Darrel Lewis (darlewis)" To: "Brian E Carpenter" X-OriginalArrivalTime: 24 Mar 2009 20:24:26.0330 (UTC) FILETIME=[86DF13A0:01C9ACBE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=437; t=1237926266; x=1238790266; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[lisp]=20My=20proposed=20revisions=20to =20the=20charter |Sender:=20; bh=6w+Yp0FO891Ow4tqwzz3GxMSdpPne21JOVXv1rRsTM0=; b=klkwXeM/id1joJhhCr5iJMuHHNosffLbBIRiAxxY+zfrnCQXvWe3/QNXjc 7nnMl1jlrGa+gKoFBbnAWUn7ktVANrvtURkt79EF+pwxFJFVnWRHcxKqj2nS B5hL1gXJym; Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:24:04 -0000 =20 > > I personally don't think that the charter needs to dive into this=20 > > level of detail - but if you think so perhaps you could offer some=20 > > suggested text? >=20 > Darrel, >=20 > Thanks. The most I would suggest is that the second=20 > occurrence of "IP" becomes > "IPv4 or IPv6", so we'd have > Both LISP EIDs and RLOCs are IPv4 or IPv6 addresses. > Thanks Brian, I find that very reasonable. -Darrel From jnc@mercury.lcs.mit.edu Tue Mar 24 14:22:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FAE43A6C3B for ; Tue, 24 Mar 2009 14:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEF0babwQIEN for ; Tue, 24 Mar 2009 14:22:09 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 6ABA03A6BFF for ; Tue, 24 Mar 2009 14:22:09 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 032356BE56C; Tue, 24 Mar 2009 17:22:59 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090324212300.032356BE56C@mercury.lcs.mit.edu> Date: Tue, 24 Mar 2009 17:22:59 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:22:10 -0000 > From: Sam Hartman >>> Darrel discussed an idea with the authors of expanding EID as >>> end-site identifier. >> That's not really correct, though, because an _individual_ >> LISP EID names an individual host (well, perhaps even an >> interface, as Fred Templin pointed out). So they don't >> identify "sites". >> ... >> (I picked 'device' to be deliberately am[b]iguous as to whether an >> LEID names a host or an interface, to avoid semi-endless debates about >> what it does name. > I think it's very clear that it names an interface My main issue, originally, was with the notion that a particular EID named an "end-site", which to most people would mean a whole chunk of the internetwork. I now see (below in your message) that you intended to mean something other than that with the term "end-site", so if we don't use the potentially confusing word 'site' I don't think there's an issue there. But now that you mention it, I think an IP address (and a LISP EID) name _more_ than an interface, they also name a host (or stack); for instance, in TCP they name the fate-sharing entity at the far end of a TCP connection. (Just for grins, I'll also very briefly take a page out of Robin's book, and point you at RFC-791, "Internet .. Protocol Specification", where we read that "hosts [are] identified by fixed length addresses".) Hence my use of a new, ambiguous term, neither 'host' nor 'interface', because IP addresses actually name both at the same time (to our great confusion). > At least in the applications area, never using the term identity > definitely seems to be the running approach. The problem is that the term 'identity' has been in use for a long time in discussing these issues at the internetwork layer (see e.g. RFC-1498, which is the famous paper from Saltzer from 1982). > How with LISP as we are scoping it today can you avoid some internal > subnetting? If I have a site (i.e. a piece of the internetwork) with only a single logical physical network (i.e. I have at most bridges, and no routers), there is only one subnet at that site, and thus no reason to dedicate any of the 'local' part of the EID to designate the subnet; the entire field can be used to number hosts/interfaces. > I'd like to say that the global portion is what is mapped into an RLOC. This gets into a bit of definitional mud here here, because I seem to vaguely recall that there were plans to have multiple ETRs divide things up, so that not all traffic to a single 'site' (as I am using the term) goes to a single ETR. (However, that's the operational side, and I'm not totally up to speed on the plans in that area, so I can't say for sure.) Anyway, the upshot is that a single 'site' might have a single LEID block assigned, but different parts of that LEID block might resolve to different RLOCs. So is the 'global' part just the high part (i.e. the block issued to the site as a whole), or does it include everything down to the last bit that the mapping system looks at to produce a mapping? > I think that a case where the same 32-bit number was used for an RLOC > and an unrelated EID would be a significant difference from LISP today. > ... > call for something to be said answering to what extent we expect EIDs > and RLOCs to overlap. In my experience, on the Internet, generally if something isn't absolutely impossible, people will figure out a way to do it - and they will do it no matter whether there's a document saying that they should or should not do it. (And they often are very clever in doing so - look at things like web site load-sharing traffic dispatchers, where a number of machines share a single IP address.) So if it's _possible_ to use the same bit pattern as both an EID and an RLOC, my guess is people will do it, no matter what the documents say. And my take is that, because of _other_ concerns (e.g. limiting routing overhead), it will be technically possible, which means people probably will do it no matter what we say in any documents. Noel From jnc@mercury.lcs.mit.edu Tue Mar 24 14:52:41 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5805028C30D for ; Tue, 24 Mar 2009 14:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1raSDg89H-wv for ; Tue, 24 Mar 2009 14:52:40 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 876C128C1AD for ; Tue, 24 Mar 2009 14:52:40 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 092C06BE557; Tue, 24 Mar 2009 17:53:30 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090324215331.092C06BE557@mercury.lcs.mit.edu> Date: Tue, 24 Mar 2009 17:53:30 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:52:41 -0000 > From: Sam Hartman > I guess the question is whether the field has a specific meaning that > is beyond what we're doing today. > ... > If the field is simply some field that might support unspecified > evolution and we're applying the general criteria of protocol > extensibility and good engineering design and we don't have to build > consensus on some specific evolutionary path, then that's totally fine. Ah, I see what you mean (I think...) Your formulation in the last paragraph is one I am basically happy with. Let me say that in general I like to see 'hooks' be architectural, rather than engineering. Perhaps an example will make what I mean by that clearer. For example, I had mentioned (elsewhere) that I'd like to see Map-Reply enrichened with 'authentication-type/authentication-data' fields for the mapping in that Reply. Note that in doing so I made no reference whatsoever about what kind of authentication, etc, etc - simply left a 'high-level' hook to do _some_ kind of authentication on the mapping, the details to be left until later. In other words, it just says 'in the future there may be authentication' (i.e. a high-level architectural direction), not anything about how such authentication would actually work (i.e. lower-level engineering detail). I assume this would pass the test in your last paragraph? The only possible 'fly in the ointment' is if some people would want to classify even that as 'specifying a particular evolutionary path'... Noel From Fred.L.Templin@boeing.com Tue Mar 24 16:12:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4FE3A681D for ; Tue, 24 Mar 2009 16:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx26ld-E17Pf for ; Tue, 24 Mar 2009 16:12:40 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 2AE463A6821 for ; Tue, 24 Mar 2009 16:12:40 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2ONDQBV018065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Mar 2009 16:13:27 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2ONDQE0014023; Tue, 24 Mar 2009 16:13:26 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2ONDQ20014017; Tue, 24 Mar 2009 16:13:26 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 16:13:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 16:13:25 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105BB4A4A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090324212300.032356BE56C@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] My proposed revisions to the charter Thread-Index: AcmsxsEzLYEJj7tMQ0m03J6FGjhoxQADWlWg References: <20090324212300.032356BE56C@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 24 Mar 2009 23:13:26.0585 (UTC) FILETIME=[22EF3290:01C9ACD6] Subject: Re: [lisp] My proposed revisions to the charter X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:12:41 -0000 Noel, =20 > But now that you mention it, I think an IP address (and a LISP EID) name > _more_ than an interface, they also name a host (or stack); In the implementations I am familiar with, interfaces can configure both IPv6 and IPv4 addresses. So, IPv6 addresses assigned to the interface name the IPv6 stack, and IPv4 addresses assigned to the interface name the IPv4 stack. So if you only assign an IPvX EID (and not an IPvY EID) you have only named one of the stacks. (Or, if you prefer to see the IPv6 and IPv4 "stacks" as two halves of the same stack, then you have only named 1/2 of the stack.) HIP on the other hand introduces a true EID that is independent of the underlying IPv4/IPv6 stacks. So, as long as you have IPv6 and IPv4 addresses configured on the interface, TCP can bind to the HIP HIT independenly of which IP version is used beneath. So, the HIP HIT gives address family independence precisely because it is not itself an IP address of any version, i.e., it is a true EID. > for instance, in > TCP they name the fate-sharing entity at the far end of a TCP > connection. The HIT names the fate-sharing entity when HIP is used, and is indeed a true EID. Fred fred.l.templin@boeing.com > (Just for grins, I'll also very briefly take a page out of Robin's > book, and point you at RFC-791, "Internet .. Protocol Specification", where we > read that "hosts [are] identified by fixed length addresses".) Hence my use of > a new, ambiguous term, neither 'host' nor 'interface', because IP addresses > actually name both at the same time (to our great confusion). From rw@firstpr.com.au Tue Mar 24 18:21:20 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B1A3A6AF5 for ; Tue, 24 Mar 2009 18:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHl5F0DYtBv9 for ; Tue, 24 Mar 2009 18:21:18 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id CF1603A6848 for ; Tue, 24 Mar 2009 18:21:17 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id B30F5175719; Wed, 25 Mar 2009 12:22:08 +1100 (EST) Message-ID: <49C98742.9000902@firstpr.com.au> Date: Wed, 25 Mar 2009 12:22:10 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lisp@ietf.org References: <20090324212300.032356BE56C@mercury.lcs.mit.edu> In-Reply-To: <20090324212300.032356BE56C@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Noel Chiappa Subject: Re: [lisp] My proposed revisions to the charter - LISP lacks proper terminology X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:21:20 -0000 Short version: Most of the third paragraph should be replaced. LISP lacks distinct terms for important concepts. This makes discussion and description tortuous and error prone, especially when terseness is a goal. Ivip has distinct terms for important concepts so discussion and descriptions can be both terse and unambiguous. I think LISP should have distinct terms for the same concepts too. There's no reason not to use the same terms as I use in Ivip. Sam wrote that a single address would "typically" not be used in EID and RLOC roles. For a practical LISP system, "typical" is not strong enough - it is impossible. Noel still seems to think it is possible, but has yet to explain how. Quoting > Noel and >> Sam: >> I'd like to say that the global portion is what is mapped into an RLOC. > > This gets into a bit of definitional mud here here, because I seem to vaguely > recall that there were plans to have multiple ETRs divide things up, so that > not all traffic to a single 'site' (as I am using the term) goes to a single > ETR. (However, that's the operational side, and I'm not totally up to speed > on the plans in that area, so I can't say for sure.) LISP and the other core-edge separation techniques all enable load balancing for a multihomed network. In an example where a single physical end-user network has two ISP links, each with its own ETR, then the total amount of LISP-mapped address space the end-user network controls, say 22.22.22.0/24 could be split into two /25 prefixes, each with its own mapping. One /25 would have mapping so ETR-A is its preferred ETR (to be used when ITRs perceive that both ETRs are up) and the other /29 would have ETR-B preferred. (LISP also has explicit load-sharing instructions in the mapping data, but this is an instance of just using Priority rather than the load-balancing Weight.) LISP has no specific terminology for these concepts: A prefix of LISP-mapped address space assigned to a single organisation or end-user network. A prefix which is covered by a single body of mapping information. (May be the whole of the above, or may be a subset of it.) This lack of precise terminology leads to difficulties describing and discussing these things, as we see on the list now. In Ivip, the 22.22.22.0/24 prefix would be referred to as the UAB (User Address Block). Each /25 would be a "micronet". Theoretically one or (for routing scalability) many more, such as thousands, of UABs would be in a Mapped Address Block (MAB) which is advertised in the DFZ by OITRDs (equivalent to LISP PTRs). LISP has no equivalent term for MAB either. In LISP, "EID" could mean several things, including a way to use address space, or a single address used as an Endpoint Identifier or a prefix of such addresses. An "EID prefix" could also mean the equivalent of a MAB (advertised in BGP), the equivalent of a UAB (the LISP mapped address space assigned to an end-user), or the equivalent of a micronet (a particular prefix which is the subject of a single mapping specification, though in Ivip, micronets don't have to be prefixes). I think the LISP team should adopt definite terms for what are known in Ivip as MAB, UAB and micronet. You are welcome to use these terms. I pinched "micronet" from Bill Herrin's TRRP proposal where it was a prefix, and use it to refer to a a contiguous block of 1 to any number of IPv4 addresses or IPv6 /64 prefixes which is covered by a single entry in the mapping database. I use the term "Scalable PI" (SPI) to refer to any Ivip-mapped address space. There's no reason why "SPI" could not be adopted as a general term in LISP for the complete set of, or the type of, address which is LISP-mapped and therefore is suitable only for end-user networks, and which can be used for multihoming, portability and inbound TE in a scalable fashion. In the above example, the 22.22.22.0/24 is used for one physical site. There could be more ISP links, more ETRs on each link (each its own RLOC address) and it would be possible in LISP to split the /24 into any mixture of prefixes from /25 to /32 and give each one of these (micronet equivalents) a separate mapping entry. It is also possible for some of this space to be used at another physical end-user network - either owned by the original organisation or not. In the first example, company CCC had the /24 originally for its single site end-user network. Here is a second example, with 32 sites: As the company grew and as IPv4 address space (LISP mapped or not) became harder obtain, CCC decided to use its existing /24 (Ivip: UAB) more intensively for its growing network of branch offices. Let's say it had 32 offices, all over the world, each with 100 desktop machines, a mail server, a web server and a few other things. CCC splits its /24 into 32 /29 prefixes (8 IPv4 addresses each) and gives separate mapping to each. (In Ivip, each such /29 is a micronet.) Then, it has 32 physically separate end-user network sites each with links to two ISPs and each, in LISP, with a single ETR at the end of each link. Within each /29 is an address for the mail-server with web server (for web-mail, amongst other things), a router address for VPN access from the outside world and some other addresses for the NAT machines serving the desktops on private addresses. Multihoming is achieved by having each such /29 ("micronet") mapped to the two ETRs of each physical site, with the ITRs choosing which of the two ETRs to use. LISP has load balancing features in the ITR, so traffic addressed to the one /29 could be load balanced over the two ISP links to the two separate ETR addresses It would also be possible to load balance these by further splitting them into /30s, with one being handled by one ETR and the other by the other, except during an outage when the ITRs figure out to send packets addressed to both /30s to whichever ETR is working. A statement such as: >> I'd like to say that the global portion is what is mapped into an >> RLOC. isn't much help, since it is not clear what the "global portion" of the address bits are and what sort of role the "EID" address/prefix in question is playing. I think the 2nd and subsequent sentences in the 3rd paragraph in the second draft: http://www.ietf.org/mail-archive/web/lisp/current/msg00314.html have many problems and should be replaced. >= Both LISP EIDs and RLOCs are IP addresses. They have to be when LISP is initially introduced as a practical solution to the routing scaling problem - and for many years after: until such time as either DFZ routers can be upgraded and/or all hosts can be changed so that two separate networks or two separate namespaces in the one network, can be used globally for the two purposes of addressing hosts and tunneling packets to ETRs. As discussed in my recent message: http://www.ietf.org/mail-archive/web/lisp/current/msg00325.html and in about 15 mailing list messages in the last 20 months, listed here: http://www.firstpr.com.au/ip/ivip/namespace/ LISP or any other "incrementally deployable" [1] core-edge separation solution to the routing scaling problem which is actually practical and could be widely voluntarily adopted must rely on the existing IPv4 or IPv6 networks both for the EID addresses used by hosts and for the RLOC addresses used by ETRs. Therefore, in this context (being a practical, voluntarily adopted, scheme) it is true to say that both EIDs and RLOCs are IP addresses. Then, it is also true to say, in terms of global operation, that the EID and RLOC addresses must both be handled by routers and hosts alike according to the single global unicast namespace of whichever network is used: IPv4 or IPv6. >= LISP EIDs are composed of three parts: a portion that identifies >= an organization, a portion that identifies a subnet within an >= organization, and a portion that identifies an interface on that >= subnet. I don't recall anything like this in LISP I-Ds. What is meant by "LISP EIDs"? In the absence of more specific terminology, I think any such description needs to have a sentence or so specifying exactly what is being referred to. Assuming straight binary boundary prefixes for all divisions (not for instance a /16 starting on a /17 boundary and so straddling a /16 boundary), here is an example of how the bits might be used if CCC's /24 was split up into 32 separate, individually mapped /29 prefixes. Most significant Least significant 0 31 Big-endian bit number. 31 0 Conventional binary bit number. aaaa aaaa aaaa aaaa bbbb bbbb cccc cddd aaaa aaaa aaaa aaaa .... .... .... .... Advertised in the DFZ, equivalent to Ivip's Mapped Address Block. aaaa aaaa aaaa aaaa bbbb bbbb .... .... CCC's /24 (Ivip: UAB.) aaaa aaaa aaaa aaaa bbbb bbbb cccc c... A particular /29 covered by a single mapping entry. (Ivip: micronet.) aaaa aaaa aaaa aaaa bbbb bbbb cccc cddd A particular IP address within the above. With the current lack of proper terminology, "LISP EID" could mean any of the above. The description in the 2nd draft is not very helpful or accurate. The bits in an EID don't explicitly "identify" an organisation. The "aaa" bits are specific to a particular DFZ advertised prefix (Ivip: MAB). In LISP (or in Ivip) this *could* contain a single range of addresses belonging to a single end-user network. But it is vital that the core-edge separation scheme be usable and generally used so that each such DFZ advertised prefix covers the space of many (hundreds to thousands) of separate end-user networks. Otherwise, we get little or no reduction in the burden on the DFZ per end-user network. It is possible, but undesirable, in LISP or Ivip for the /16 prefix: aaaa aaaa aaaa aaaa .... .... .... .... to be several things all at once: 1 - A DFZ advertised prefix for PTRs (Ivip: MAB). 2 - A prefix of LISP-mapped address space assigned to a particular organisation for its one or more physically distinct end-user networks (Ivip: UAB). 3 - A prefix with a single mapping (Ivip: micronet). In this case, for CCC, they have a single end-user network and multihome via two ISPs, with a single EID prefix with a single mapping (Ivip: micronet) which covers their entire assigned address space (Ivip: UAB.) Also, CCC has its two ISPs advertise this same /16 into the DFZ (Ivip: MAB.) This achieves no scaling improvement over the current practice of advertising the /16 as a conventional PI address in BGP. However, it is a technically valid arrangement under LISP or Ivip. It has no scaling benefits, but it might have benefits for CCC. For instance, with LISP, CCC may believe that individual ITRs are better placed to decide which of the two ETRs to tunnel packets to, rather than relying on BGP to adapt to a failure of one ISP link or the other. With Ivip, CCC might prefer to nearly instantly switch traffic from one ISP link to the other with a single mapping change. My point is that this use of a single /16 for three roles, which were performed by three separate prefixes in the 32 site example above, is a perfectly valid LISP arrangement and is not at all covered by the "three parts" text in the 2nd draft of the Charter. >= LISP maps only the upper portion of the EID; Since the reader has no way of being sure what the EID in question is, or whether "upper" refers to the first or the second of the "three parts" previously described, this does not help their understanding. Also, the "three parts" text did not state clearly where these three parts reside in the binary address bits to the reader has to imagine the the first mentioned part is the most significant, in the "upper" part of the address bits. >= as a consequence a host would typically change EIDs when it moves >= from one organization to another or whenever it moves from one >= subnet to another within an organization. A host must get a new address when it changes to another subnet of any kind, and assuming it moves to a subnet in another organisation, it must therefore get another address. This is true of ordinary non-EID (non LISP-mapped and therefore RLOC space) or of LISP-mapped EID space (Ivip: SPI) space. So this sentence doesn't help anyone understand LISP. >= Generally, the same IP address cannot be used as both an EID and >= an RLOC, especially if the entities named by the EID and RLOC are >= different. This would be an incorrect and extremely confusing sentence to have in the LISP WG Charter. It is always true that "the same IP address cannot be used as both an EID and an RLOC" as I have argued many times, including in my last message. So the first half of the sentence is misleading and the second has no valid meaning. > Anyway, the upshot is that a single 'site' might have a single LEID block > assigned, but different parts of that LEID block might resolve to different > RLOCs. So is the 'global' part just the high part (i.e. the block issued to > the site as a whole), or does it include everything down to the last bit that > the mapping system looks at to produce a mapping? Noel, I hope that my 32 separate /29 prefix example illustrates the sort of scenarios you are referring to. >> I think that a case where the same 32-bit number was used for an RLOC >> and an unrelated EID would be a significant difference from LISP today. If "LISP today" means as implemented in the current test network and as LISP must be implemented for a practical, widely, voluntarily adopted core-edge separation solution to the routing scaling problem then the above sentence is absolutely true. There are no separate namespaces within the IPv4 address range which can be used for RLOCs and EIDs, because the only global network which can be used for both hosts and ETRs uses a single namespace for the global unicast portions of its address range. There is only one namespace available to LISP or any other scheme for the two purposes of getting packets to IPv4 headdresses ETRs and for unmodified IPv4 hosts to use as addresses for themselves: the IPv4 Global Unicast namespace. My previous message also explains why an ITR can't possibly be tunneling packets to w.x.y.z as an ETR (RLOC) address while accepting incoming packets addressed to w.x.y.z as if it was an "EID" address, so these packets would be mapped and encapsulated to some ETR address. >> ... >> call for something to be said answering to what extent we expect EIDs >> and RLOCs to overlap. I agree. I think my suggested changes to the draft Charter do a good job of explaining this, and other crucial aspects of LISP, in a concise and unambiguous manner: http://www.ietf.org/mail-archive/web/lisp/current/msg00286.html Further discussion of these suggested changes: http://www.ietf.org/mail-archive/web/lisp/current/msg00298.html http://www.ietf.org/mail-archive/web/lisp/current/msg00309.html > In my experience, on the Internet, generally if something isn't absolutely > impossible, people will figure out a way to do it - and they will do it no > matter whether there's a document saying that they should or should not do it. I agree. > (And they often are very clever in doing so - look at things like web site > load-sharing traffic dispatchers, where a number of machines share a single IP > address.) Yes, but it is not always truly clever and wise. Look at the mess of ugliness, unpleasant surprises and things which just don't work which many people made with the desktop publishing and now with HTML, CSS, javascript and FLASH in website design and HTML email. In particular, consider NAT . . . > So if it's _possible_ to use the same bit pattern as both an EID and an RLOC, > my guess is people will do it, no matter what the documents say. It is not possible. The ITR will eat its own emitted encapsulated packets and/or the packets emitted by other ITRs. PTRs in the DFZ will attract encapsulated packets and look up the mapping of what they consider to be an EID address, and will then encapsulate the already encapsulated packet and send it to some hapless ETR. > And my take is that, because of _other_ concerns (e.g. limiting routing overhead), it > will be technically possible, which means people probably will do it no > matter what we say in any documents. Please read my previous message: http://www.ietf.org/mail-archive/web/lisp/current/msg00325.html and describe in detail how you thing it would be possible, in LISP (or any other core-edge separation scheme) to use the one particular address (or 32 bit pattern of bits or whatever you want to call it) as both an EID and an RLOC. - Robin [1] "Incrementally deployable" means different things to different people. So I think it's use in the Charter needs to be expanded into something more specific. See: http://www.ops.ietf.org/lists/rrg/2008/msg00957.html From hartmans@mit.edu Tue Mar 24 18:37:27 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0C43A6AFB for ; Tue, 24 Mar 2009 18:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgCACxykltmw for ; Tue, 24 Mar 2009 18:37:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-46b4.meeting.ietf.org [130.129.70.180]) by core3.amsl.com (Postfix) with ESMTP id CE8133A6945 for ; Tue, 24 Mar 2009 18:37:26 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9BCB34144; Tue, 24 Mar 2009 21:38:08 -0400 (EDT) To: Robin Whittle References: <20090324212300.032356BE56C@mercury.lcs.mit.edu> <49C98742.9000902@firstpr.com.au> From: Sam Hartman Date: Tue, 24 Mar 2009 21:38:08 -0400 In-Reply-To: <49C98742.9000902@firstpr.com.au> (Robin Whittle's message of "Wed\, 25 Mar 2009 12\:22\:10 +1100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org, Noel Chiappa Subject: Re: [lisp] My proposed revisions to the charter - LISP lacks proper terminology X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:37:27 -0000 >>>>> "Robin" == Robin Whittle writes: Robin> Short version: Most of the third paragraph should be Robin> replaced. Here, you may well be right:-) I took a stab at things, but it looks like there is more work to do. Most of what you said is stuff that I cannot really comment on as a chair. Robin> Sam wrote that a single address would Robin> "typically" not be used in EID and RLOC roles. For a Robin> practical LISP system, "typical" is not strong enough - it Robin> is impossible. Robin> Noel still seems to think it is Robin> possible, but has yet to explain how. I think there has been enough discussion on-list and other private comments that the rough consensus of the participants so far is that there will be cases where the same IP stands both as an EID and a RLOC. My claim that this typically does not happen may even be too strong:-) I acknowledge that you disagree and that so far our sample size is small. From hartmans@mit.edu Tue Mar 24 19:03:23 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761483A6AE4 for ; Tue, 24 Mar 2009 19:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+PfKRaBscpk for ; Tue, 24 Mar 2009 19:03:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-46b4.meeting.ietf.org [130.129.70.180]) by core3.amsl.com (Postfix) with ESMTP id D63223A6AD8 for ; Tue, 24 Mar 2009 19:03:22 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F252B4144; Tue, 24 Mar 2009 22:04:08 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Tue, 24 Mar 2009 22:04:08 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] LISP presentations available X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 02:03:23 -0000 Most of the presentations for tomorrow's meeting are available on the meeting materials management tool at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=74 I'd like to thank the authors for getting that to us! From rw@firstpr.com.au Tue Mar 24 21:04:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE4328C122 for ; Tue, 24 Mar 2009 21:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd18wGVQoSsO for ; Tue, 24 Mar 2009 21:04:15 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 0FFB528C134 for ; Tue, 24 Mar 2009 21:04:15 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id BE7F41759D8; Wed, 25 Mar 2009 15:05:05 +1100 (EST) Message-ID: <49C9AD73.2070102@firstpr.com.au> Date: Wed, 25 Mar 2009 15:05:07 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] Consensus? EID and RLOC use of the same address = separate namespace debate X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 04:04:17 -0000 Short version: I see no evidence in the list messages that rough consensus has been reached that "there will be cases where the same IP stands both as an EID and a RLOC". Private discussions were mentioned, but AFAIK these should have nothing to do with judgements about rough consensus. Since 2007-01 draft-farinacci-lisp-00 to 12 has this as an absolute requirement: EIDs MUST NOT be used as LISP RLOCs. I am perplexed that I have so far been unable to prompt anyone to write to this list agreeing with this requirement. I go further and state that within the context of LISP being a practical solution to the routing scaling problem, a particular IP address CANNOT successfully be used as both an EID and RLOC. Hi Sam, In "Re: [lisp] My proposed revisions to the charter - LISP lacks proper terminology": http://www.ietf.org/mail-archive/web/lisp/current/msg00336.html you wrote, in part: >> Sam wrote that a single address would "typically" not be used in >> EID and RLOC roles. For a practical LISP system, "typical" is not >> strong enough - it is impossible. >> >> Noel still seems to think it is possible, but has yet to explain >> how. > > I think there has been enough discussion on-list and other private > comments that the rough consensus of the participants so far is > that there will be cases where the same IP stands both as an EID > and a RLOC. I am completely unable to see how you as co-chair could decide that rough consensus has been reached on this. The messages so far are linked to at: http://www.firstpr.com.au/ip/ivip/namespace/ All of the following discussion is within the context of LISP being a practical solution to the routing scaling problem, which means it needs to work properly with unmodified hosts and unmodified DFZ routers. If LISP could work with the same particular IP address being used for both an EID and an RLOC, then this could only occur due to the devices which handle the packets differently according to which role the address is being used in (ITRs and ETRs) have some way of telling whether the address is to be interpreted as an EID or as an RLOC. This would only be possible if there were in fact two separate namespaces for RLOC and EID and if there was some mechanism by which the ITRs and ETRs could recognise which namespace to use when interpreting the address. Without that, the an ITR will eat its own emitted encapsulated packet or the encapsulated packet will get out to the DFZ and be forwarded to a PTR, which will regard it as a traffic packet with an EID destination address - to be encapsulated and tunneled to some RLOC address. I wrote about this specifically at the end of my last message: http://www.ietf.org/mail-archive/web/lisp/current/msg00335.html Sam, I think that in stating that rough consensus has been reached that "there will be cases where the same IP stands both as an EID and a RLOC." you are also implying that rough consensus has been reached that LISP (in the context of being a practical solution) does or can involve two separate namespaces for RLOC and EIDs. I see no evidence for such consensus. I wrote extensively that: There can be no such separate namespaces. Trying to use a particular address as both an RLOC and EID cannot work. Noel Chiappa asserted that there could be two separate namespaces: http://www.ietf.org/mail-archive/web/lisp/current/msg00274.html Dino Farinacci wrote: http://www.ietf.org/mail-archive/web/lisp/current/msg00291.html that the AFI field could be used to provide any number of namespaces, but the example he gave could not be used by LISP if it was to be a practical solution to the routing scaling problem. Scott Brim wrote: http://www.ietf.org/mail-archive/web/lisp/current/msg00296.html that it was impossible to prevent someone using a field for a different role to what was intended. Noel wrote: http://www.ietf.org/mail-archive/web/lisp/current/msg00332.html So if it's _possible_ to use the same bit pattern as both an EID and an RLOC, my guess is people will do it, no matter what the documents say. And my take is that, because of _other_ concerns * (e.g. limiting routing overhead), it will be technically * possible, which means people probably will do it no matter what we say in any documents. That's it as far as I can tell. Despite my repeated urgings no-one has described an example of how two separate namespaces could be used in a practical LISP solution to the routing scaling problem - or what amounts to the same thing, how the one IP address could be used both as an EID and as an RLOC. Sam, you may well have been part of private discussions I am not aware of. But as far as I can see, those discussions should have no bearing on your decision about whether consensus as been achieved. So far, no-one has produced anything more than assertions or inappropriate examples when disagreeing with my argument. No-one has pointed out where in the LISP I-Ds the concept of two separate namespaces is specified. No-one has pointed out where in the I-Ds this concept of separate namespaces is allowed or where it is allowed for an address to be used simultaneously as an EID or RLOC. It is easy to quote chapter and verse on why an address can't be used both as an EID and RLOC. Since January 2007 this has been a part of the basic LISP I-D [!!!], in a form which would constitute an "absolute requirement" in an RFC 2119 RFC. http://tools.ietf.org/html/draft-farinacci-lisp-12 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. I am really perplexed that I have so far been unable to get anyone to write to this list acknowledging that a given address cannot be used both as an EID and an RLOC in any implementation of LISP which would be practical for widespread voluntary adoption. - Robin From rw@firstpr.com.au Tue Mar 24 21:08:05 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8433A69DF for ; Tue, 24 Mar 2009 21:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EK7YtvFYEz8 for ; Tue, 24 Mar 2009 21:08:04 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 77B283A6768 for ; Tue, 24 Mar 2009 21:08:04 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 7E3221759D8; Wed, 25 Mar 2009 15:08:53 +1100 (EST) Message-ID: <49C9AE57.5070004@firstpr.com.au> Date: Wed, 25 Mar 2009 15:08:55 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] EIDs MUST NOT be used as LISP RLOCs. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 04:08:05 -0000 Just quoting the Good Book: http://tools.ietf.org/html/draft-farinacci-lisp-12#page-8 Please see my previous message: Consensus? EID and RLOC use of the same address = separate namespace debate - Robin From Fred.L.Templin@boeing.com Wed Mar 25 08:02:01 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65ED628C13D for ; Wed, 25 Mar 2009 08:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVTCjiTqwCT5 for ; Wed, 25 Mar 2009 08:02:00 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 845A528C146 for ; Wed, 25 Mar 2009 08:02:00 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2PF2nfE008967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 10:02:49 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2PF2n7E002865; Wed, 25 Mar 2009 10:02:49 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2PF2gpK002611; Wed, 25 Mar 2009 10:02:49 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 08:02:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 08:02:43 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105BB4BF9@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <49C9AE57.5070004@firstpr.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MTU handling in LISP Thread-Index: Acms/21S6FTJOpZVTVeK6HfVeFCBkAAV4v+A References: <49C9AE57.5070004@firstpr.com.au> From: "Templin, Fred L" To: "Dino Farinacci" , X-OriginalArrivalTime: 25 Mar 2009 15:02:45.0474 (UTC) FILETIME=[C113EC20:01C9AD5A] Subject: [lisp] MTU handling in LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:02:01 -0000 Dino, There are still MTU oddities in the latest LISP draft that the team somehow seems reluctant to face up to. First, there are no circumstances under which the ITR may discard any packet with DF=3D0, i.e., even for packets as large as 64KB. Instead, the ITR should pick a fragment size (e.g., 1400B) and perform inner IPv4 fragmentation on packets that are larger than this size before encapsulating each fragment as an individual LISP packet. The final destination gets to reassemble these. Second, there are two problems with the stateful case. First, there is no guarantee that the ICMPs sent by middleboxes will make it to the ITR. Second, the attack surface for spoofed ICMPs is the entire Internet. To address this, we can enlist the ETR's aid in reporting any IPv4 fragmentation that occurs on the path from the ITR, and these reports will be encapsulated as LISP packets sent back to the ITR and hence not susceptible to ICMP filters on the path. The attack surface is also reduced to on-path only. I have already shown how this can be accommodated through a slight rearrangement of the LISP header with no extra overhead, and with the added benefit of providing extra locator reachability bits. But, just for you, I am also going to _RELAX THE REQUIREMENT FOR THE ETR TO DO ANY REASSEMBLY_. Yes, that's right - all the ETR will have to do is return fragmentation reports; any outer IP fragmented packets received by the ETR are dropped. This approach lets the ITR discover a size S for which it will drop any packets with DF=3D0 larger than S and return an ICMP packet too big to the original source _without wasting any tunnel resources_, i.e., even if S < 1500. If it turns out that S is excessively small (e.g., S < 1280 for IPv6) then there is truly a degenerate link somewhere within the tunnel and someone should send a polite e-mail kindly requesting that it be fixed. So, what do you want to do about this? Leave the current LISP text as it is and hope for the best? Or pick up a lightweight mechanism that just might put the issue to bed once and for all? Thanks - Fred fred.l.templin@boeing.com From Fred.L.Templin@boeing.com Wed Mar 25 08:05:29 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E27E28C14D for ; Wed, 25 Mar 2009 08:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.296 X-Spam-Level: X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVd2W5aOLRV7 for ; Wed, 25 Mar 2009 08:05:28 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 6792928C139 for ; Wed, 25 Mar 2009 08:05:28 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2PF6JC8011373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 10:06:19 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2PF6Ipm013413; Wed, 25 Mar 2009 08:06:18 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2PF6GRg013301; Wed, 25 Mar 2009 08:06:18 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 08:06:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 08:06:15 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105BB4C04@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105BB4BF9@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] MTU handling in LISP Thread-Index: Acms/21S6FTJOpZVTVeK6HfVeFCBkAAV4v+AAAEHj3A= References: <49C9AE57.5070004@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A105BB4BF9@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Dino Farinacci" , X-OriginalArrivalTime: 25 Mar 2009 15:06:16.0681 (UTC) FILETIME=[3EF78D90:01C9AD5B] Subject: Re: [lisp] MTU handling in LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:05:29 -0000 Slight correction: > -----Original Message----- > From: Templin, Fred L > Sent: Wednesday, March 25, 2009 8:03 AM > To: Dino Farinacci; lisp@ietf.org > Subject: [lisp] MTU handling in LISP >=20 > Dino, >=20 > There are still MTU oddities in the latest LISP draft > that the team somehow seems reluctant to face up to. >=20 > First, there are no circumstances under which the ITR > may discard any packet with DF=3D0, i.e., even for packets > as large as 64KB. Instead, the ITR should pick a fragment > size (e.g., 1400B) and perform inner IPv4 fragmentation > on packets that are larger than this size before > encapsulating each fragment as an individual LISP packet. > The final destination gets to reassemble these. >=20 > Second, there are two problems with the stateful case. > First, there is no guarantee that the ICMPs sent by > middleboxes will make it to the ITR. Second, the attack > surface for spoofed ICMPs is the entire Internet. >=20 > To address this, we can enlist the ETR's aid in reporting > any IPv4 fragmentation that occurs on the path from the > ITR, and these reports will be encapsulated as LISP > packets sent back to the ITR and hence not susceptible > to ICMP filters on the path. The attack surface is also > reduced to on-path only. >=20 > I have already shown how this can be accommodated through > a slight rearrangement of the LISP header with no extra > overhead, and with the added benefit of providing extra > locator reachability bits. But, just for you, I am also > going to _RELAX THE REQUIREMENT FOR THE ETR TO DO ANY > REASSEMBLY_. >=20 > Yes, that's right - all the ETR will have to do is return > fragmentation reports; any outer IP fragmented packets > received by the ETR are dropped. This approach lets the > ITR discover a size S for which it will drop any packets > with DF=3D0 larger than S and return an ICMP packet too This should of course read "DF=3D1". Fred fred.l.templin@boeing.com > big to the original source _without wasting any tunnel > resources_, i.e., even if S < 1500. If it turns out that > S is excessively small (e.g., S < 1280 for IPv6) then > there is truly a degenerate link somewhere within the > tunnel and someone should send a polite e-mail kindly > requesting that it be fixed. >=20 > So, what do you want to do about this? Leave the current > LISP text as it is and hope for the best? Or pick up a > lightweight mechanism that just might put the issue to > bed once and for all? >=20 > Thanks - Fred > fred.l.templin@boeing.com > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Wed Mar 25 08:10:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AC723A68F6 for ; Wed, 25 Mar 2009 08:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeG5eG-62sOh for ; Wed, 25 Mar 2009 08:10:51 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-46b4.meeting.ietf.org [130.129.70.180]) by core3.amsl.com (Postfix) with ESMTP id 912863A67A5 for ; Wed, 25 Mar 2009 08:10:51 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A4B23641B4; Wed, 25 Mar 2009 11:11:43 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Message-Id: <20090325151143.A4B23641B4@carter-zimmerman.suchdamage.org> Date: Wed, 25 Mar 2009 11:11:43 -0400 (EDT) Subject: [lisp] Charter for discussion at today's meeting X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:10:52 -0000 I've attempted to rifine my text to address concerns brought up on the list today. At today's meeting I hope we can identify open issues with this text. Unless we believe some issue will be far easier to discuss face-to-face rather than over the list, we will focus on identifying the issues not on closing them out. The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation". The basic idea behind the separation that the Internet architecture combines two functions, Routing Locators, (where you are attached to the network) and Identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the Internet address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of other approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the EID-to-RLOC mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications). Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG as Experimental Mar 2010 Submit base ALT specification to the IESG as Experimental Mar 2010 Submit the LISP Interworking specification to the IESG as Experimental June 2010 Submit the LISP Map Server specification to the IESG as Experimental June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 Submit a preliminary analysis as Informational Dec 2010 Re-charter or close. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Wed Mar 25 08:26:20 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66EC328C12A for ; Wed, 25 Mar 2009 08:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9UlcoIlzUv2 for ; Wed, 25 Mar 2009 08:26:19 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id B7C7028C11A for ; Wed, 25 Mar 2009 08:26:19 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 16A9F6BE555; Wed, 25 Mar 2009 11:27:10 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090325152711.16A9F6BE555@mercury.lcs.mit.edu> Date: Wed, 25 Mar 2009 11:27:10 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Charter for discussion at today's meeting X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:26:20 -0000 > From: Sam Hartman A minor unclarity: > LISP maps the "global" portion of the identifier into a set of locators > that can reach the identified interface That seems to imple the RLOCs reach the destination directly, not through ETRs. So perhaps 'LISP maps the "global" portion of the identifier into a set of locators for de-capsulation devices which can reach the identified interface', or something like that? Noel From jnc@mercury.lcs.mit.edu Wed Mar 25 08:47:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25AE3A693E for ; Wed, 25 Mar 2009 08:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54QHnAbnm3OC for ; Wed, 25 Mar 2009 08:47:16 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id F27133A683A for ; Wed, 25 Mar 2009 08:47:15 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DF3336BE555; Wed, 25 Mar 2009 11:48:07 -0400 (EDT) To: lisp@ietf.org, Olivier.Bonaventure@uclouvain.be Message-Id: <20090325154807.DF3336BE555@mercury.lcs.mit.edu> Date: Wed, 25 Mar 2009 11:48:07 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Using Signed object to validate entries in Mapping Database: draft-lisp-rgaglian-ioa-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:47:16 -0000 > From: Olivier Bonaventure > Securing the mapping system is an important problem that hasn't > received enough attention on the lisp mailing list. On this list, no. But the problem of securing the system by signing bindings has received a fair amount of attention, in particular in the context of CONS. See, for instance, this message to the RRG mailing list: http://www.ietf.org/mail-archive/web/rrg/current/msg01077.html and following messages on that date and following days, starting here: http://www.ietf.org/mail-archive/web/rrg/current/mail142.html (BTW, does the mailman archive have any sort of index page? I found these by manually editing the URL in a binary search... not too efficient.) I'm not sure how much security we need in this trial. I _do_ think (as earlier messages indicated, peripherally) that we need to make _provision_ for better security down the road (the 'authentication type/authentication data' fields I mentioned), but beyond that I think we can probably avoid opening that can of worms for the moment. Noel From hartmans@mit.edu Wed Mar 25 08:53:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7155A3A67FF for ; Wed, 25 Mar 2009 08:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZhLtqe+ccDI for ; Wed, 25 Mar 2009 08:53:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.87.223]) by core3.amsl.com (Postfix) with ESMTP id C9A993A67F4 for ; Wed, 25 Mar 2009 08:53:25 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5CEE0641B4; Wed, 25 Mar 2009 11:54:18 -0400 (EDT) To: jnc@mercury.lcs.mit.edu (Noel Chiappa) References: <20090325152711.16A9F6BE555@mercury.lcs.mit.edu> From: Sam Hartman Date: Wed, 25 Mar 2009 11:54:18 -0400 In-Reply-To: <20090325152711.16A9F6BE555@mercury.lcs.mit.edu> (Noel Chiappa's message of "Wed\, 25 Mar 2009 11\:27\:10 -0400 \(EDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Charter for discussion at today's meeting X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:53:26 -0000 >>>>> "Noel" == Noel Chiappa writes: >> From: Sam Hartman Noel> A minor unclarity: >> LISP maps the "global" portion of the identifier into a set of >> locators that can reach the identified interface Noel> That seems to imple the RLOCs reach the destination Noel> directly, not through ETRs. So perhaps 'LISP maps the Noel> "global" portion of the identifier into a set of locators Noel> for de-capsulation devices which can reach the identified Noel> interface', or something like that? I think this is an improvement From roque@lacnic.net Wed Mar 25 09:13:50 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63ACA3A6D3B for ; Wed, 25 Mar 2009 09:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrctwskHhEEm for ; Wed, 25 Mar 2009 09:13:49 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id 414823A6BB3 for ; Wed, 25 Mar 2009 09:13:48 -0700 (PDT) Received: from [IPv6:2001:13c7:7001:5064:323:45ff:fe67:78ab] (unknown [IPv6:2001:13c7:7001:5064:323:45ff:fe67:78ab]) by mail.lacnic.net.uy (Postfix) with ESMTP id C1B0A308457; Wed, 25 Mar 2009 13:14:36 -0300 (UYT) Message-Id: <06A52779-0FF7-441C-9A85-5DF64BFADAD8@lacnic.net> From: Roque Gagliano To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <49C8F88C.9090404@uclouvain.be> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-21--155049790" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 09:14:31 -0700 References: <83B62425-E996-4A8C-9D7F-B78E363E3C3E@lacnic.net> <49C8F88C.9090404@uclouvain.be> X-Pgp-Agent: GPGMail d55 (v55, Leopard) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.930.3) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Cc: lisp@ietf.org Subject: Re: [lisp] Using Signed object to validate entries in Mapping Database: draft-lisp-rgaglian-ioa-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:13:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-21--155049790 Content-Type: multipart/alternative; boundary=Apple-Mail-20--155049817 --Apple-Mail-20--155049817 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Olivier, > > This is a possible approach. It would be interesting to discuss how > the > IOA would be discributed ? > One option could be a central repository such as a RIR containing all > the IOAs > Another option could be to include the IOA in the mapping reply or the > url of the IOA in the mapping reply. > The way that RPKI works is by using a distributed repository where each signed object (ie certificates, ioa, roas) mentions the location of its repository. So, yes the RIR have a repository for the first two layers of material (certificates to ISPs) but the ISP then can implement their own CA and their own repository to host its signed objects (ie ioas). The protocol propossed to fetch all these object from various repositories is rsync and normally a relying party has a local cache with all the material that has download. There is a lap that by design we took as 24hs from time I update my repository until every party has the latest copy. Regards, r. > Olivier > > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium --Apple-Mail-20--155049817 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Olivier,

This is a = possible approach. It would be interesting to discuss how the
IOA = would be discributed ?
One option could be a central repository such = as a RIR containing all
the IOAs
Another option could be to = include the IOA in the mapping reply or the
url of the IOA in the = mapping reply.


The way = that RPKI works is by using a distributed repository where each signed = object (ie certificates, ioa, roas) mentions the location of its = repository. So, yes the RIR have a repository for the first two layers = of material (certificates to ISPs) but the ISP then can implement their = own CA and their own repository to host its signed objects (ie = ioas).

The protocol propossed to fetch all = these object from various repositories is rsync and normally a relying = party has a local cache with all the material that has download. There = is a lap that by design we took as 24hs from time I update my repository = until every party has the latest = copy.

Regards,
r.

<= br>
Olivier

--
http://inl.info.ucl.ac.be , = UCLouvain, = Belgium

= --Apple-Mail-20--155049817-- --Apple-Mail-21--155049790 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknKWGcACgkQnk+WSgHpbO490ACgwycXO6GiJcGcgk/YKWygvAIs C6sAoN0bJQdN8ArI1fc7WIQjTwNLXIA1 =9mqj -----END PGP SIGNATURE----- --Apple-Mail-21--155049790-- From jmh@joelhalpern.com Wed Mar 25 09:51:43 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D543A67E1 for ; Wed, 25 Mar 2009 09:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W9nAWqql2EX for ; Wed, 25 Mar 2009 09:51:42 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 828F83A677D for ; Wed, 25 Mar 2009 09:51:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3D26D4303D2 for ; Wed, 25 Mar 2009 09:52:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [130.129.17.160] (dhcp-11a0.meeting.ietf.org [130.129.17.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 1F4554303CC for ; Wed, 25 Mar 2009 09:52:35 -0700 (PDT) Message-ID: <49CA6153.40801@joelhalpern.com> Date: Wed, 25 Mar 2009 12:52:35 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Interworking - NAT X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:51:43 -0000 Reading the interworking NAT description, I am trying to figure out which one of two cases it is trying to address. For context, as I read it, LISP-NAT attempts to do 1-1 NAT in the address space for IPv4. One case is some time in the future when significant parts of the world are (hypothetically) on LISP. In that case, the number of hosts needing to talk to non-LISP palces at any given time may well be small. Getting a sufficient pool of aggregatable addresses for such communication without affecting other parts of the IPv4 world may be doable. In contrast, if folks could get 1-1 NAT for IPv4 now then that would be a viable solution to a number of real world problems already. We as a community are looking are recommending something similar as part of IPv6 (NAT66). If that could be done for v4 in the current world, I am not at all clear on why a site would bother with the rest of LISP. Given typical site attitudes, that sort of NAT would seem sufficient for them. Yours, Joel M. Halpern From dmm@1-4-5.net Wed Mar 25 10:19:50 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32C93A6B70 for ; Wed, 25 Mar 2009 10:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaixCRlcNkk3 for ; Wed, 25 Mar 2009 10:19:49 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 025903A6ADC for ; Wed, 25 Mar 2009 10:19:48 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n2PHKfmT015020; Wed, 25 Mar 2009 10:20:41 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n2PHKfFO015019; Wed, 25 Mar 2009 10:20:41 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 25 Mar 2009 10:20:41 -0700 From: David Meyer To: "Joel M. Halpern" Message-ID: <20090325172041.GA14881@1-4-5.net> References: <49CA6153.40801@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <49CA6153.40801@joelhalpern.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: lisp@ietf.org Subject: Re: [lisp] Interworking - NAT X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:19:50 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2009 at 12:52:35PM -0400, Joel M. Halpern wrote: > Reading the interworking NAT description, I am trying to figure out =20 > which one of two cases it is trying to address. > > For context, as I read it, LISP-NAT attempts to do 1-1 NAT in the =20 > address space for IPv4. If you mean 1-1 NAT from the IPv4 EID space to the IPv4 RLOC space, yes. > One case is some time in the future when significant parts of the world = =20 > are (hypothetically) on LISP. In that case, the number of hosts needing = =20 > to talk to non-LISP palces at any given time may well be small. Getting = =20 > a sufficient pool of aggregatable addresses for such communication =20 > without affecting other parts of the IPv4 world may be doable. > > In contrast, if folks could get 1-1 NAT for IPv4 now then that would be = =20 > a viable solution to a number of real world problems already. We as a = =20 > community are looking are recommending something similar as part of IPv6 = =20 > (NAT66). If that could be done for v4 in the current world, I am not at = =20 > all clear on why a site would bother with the rest of LISP. Given =20 > typical site attitudes, that sort of NAT would seem sufficient for them. Perhaps, however, 1-1 NAT still carries a lot of operational burden for sites deploying the technology. Deploying PTR infrastructure eases this burden, and provides quite a bit of additional functionality. I think of it as a tool in the toolkit that can be useful in some cases. Dave --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknKZ+kACgkQORgD1qCZ2KclqwCfcNSwKcrZDcV+xiqJd7DWRhLJ rJcAn2rjj2Xy9DK5CIboPJnTKsZh8guc =unIF -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From dmm@1-4-5.net Wed Mar 25 10:36:58 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E903A6D54 for ; Wed, 25 Mar 2009 10:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLxiadscgJbq for ; Wed, 25 Mar 2009 10:36:57 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id AACB43A686E for ; Wed, 25 Mar 2009 10:36:57 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n2PHbn0D015759; Wed, 25 Mar 2009 10:37:49 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n2PHbnrE015758; Wed, 25 Mar 2009 10:37:49 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 25 Mar 2009 10:37:49 -0700 From: David Meyer To: David R Oran Message-ID: <20090325173749.GA15700@1-4-5.net> References: <426ADC97-57AF-4503-9495-AA7531218B56@cisco.com> <20090325172555.GB6690@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <20090325172555.GB6690@cisco.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: lisp@ietf.org Subject: Re: [lisp] My comment at the mic during the WG meeting about evaluating/measuring complexity X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:36:58 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2009 at 10:25:55AM -0700, David Meyer wrote: > On Wed, Mar 25, 2009 at 10:21:44AM -0700, David R Oran wrote: > Christian Vogt raised a point at the mic during the WG meeting that =20 > the LISP as a whole system appeared to be getting very complex and =20 > cautioned that complex systems are hard to deploy and manage. Dave =20 > Meyer commented that trying to evaluate complexity was hard/subjective = =20 > and we should not rat-hole on discussing LISP's complexity. >=20 > I don't have an opinion on whether LISP (as a system) is complex or =20 > not, whether the complexity justified or gratuitous, or whether the =20 > complexity represents a serious barrier to deployment and operation. I = =20 > do, however, disagree with Dave Meyer that we don't have pretty good =20 > objective criteria for evaluating complexity, and that it would be =20 > good to apply these to assessing LISP's complexity. =20 Well, what I intended was that it is not all that useful to make statements like "addition of components makes things more complicated". =20 > WG co-chair Sam Hartman asked me to document what I thought these =20 > objective criteria were. This is by no means a complete list, but =20 > includes: >=20 > - How big is the total state space of the system, and how does it =20 > scale with the number of elements participating. >=20 > - How many elements of the system need to change state when a single =20 > event occurs (events include boxes going up/down, routes changing, EID = =20 > prefixes being added/removed, RLOCs being added removed, etc.) >=20 > - How many individual logical elements are involved in each primitive =20 > operation of the system (e.g. resolving a MAP request) such that =20 > either the operation fails (in the absence of redundancy) or requires =20 > high-reliability machinery to provide acceptable availability. >=20 > - How many individual elements need hand configuration to provision =20 > and manage the system. How does this scale with the number of sites, =20 > service providers, and registries. >=20 > - How many administrative domains are involved in the consistent =20 > operation of the system, and how many configuration and policy =20 > elements need to be coordinated across those boundaries. >=20 > I would assert that at best these are actually measurable, and at =20 > worst can be loosely assessed. =20 No disagreement with what you've said here. But taking data points (measurement) or even systematic "loose assessment" is a qualitatively different statement than what I was responding to. =20 Dave =20 =09 --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknKa+0ACgkQORgD1qCZ2KdKRACeNvkFf7wqhioM2dfMXrnQYmk8 JYYAn1y5p5vQ9GfJynRRzqaRxSMM+W7K =el79 -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From swb@employees.org Wed Mar 25 10:43:53 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F603A6A9A for ; Wed, 25 Mar 2009 10:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxlCusnALrpK for ; Wed, 25 Mar 2009 10:43:52 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 542A83A6D6F for ; Wed, 25 Mar 2009 10:43:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,420,1233532800"; d="scan'208";a="32341749" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 25 Mar 2009 17:44:39 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2PHidg4018477; Wed, 25 Mar 2009 13:44:39 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2PHicpZ019842; Wed, 25 Mar 2009 17:44:38 GMT Date: Wed, 25 Mar 2009 10:44:32 -0700 From: Scott Brim To: David Meyer Message-ID: <20090325174432.GO1112@cisco.com> Mail-Followup-To: Scott Brim , David Meyer , David R Oran , lisp@ietf.org References: <426ADC97-57AF-4503-9495-AA7531218B56@cisco.com> <20090325172555.GB6690@cisco.com> <20090325173749.GA15700@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline In-Reply-To: <20090325173749.GA15700@1-4-5.net> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: David R Oran , lisp@ietf.org Subject: Re: [lisp] My comment at the mic during the WG meeting about evaluating/measuring complexity X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:43:53 -0000 --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This is all excellent, but there's a criterion missing that I don't know how to name ... something about the organization of the elements involved in a change. If a change propagates hierarchically that's less complexity than if a change propagates, is reflected back toward the origin, and elements which have already changed have to change again until balance is achieved. In particular I don't think lisp-ms adds particularly to the _overall_ system complexity because it is peripheral and a particular change only flows in one direction. swb Excerpts from David Meyer on Wed, Mar 25, 2009 10:37:49AM -0700: > On Wed, Mar 25, 2009 at 10:25:55AM -0700, David Meyer wrote: > > On Wed, Mar 25, 2009 at 10:21:44AM -0700, David R Oran wrote: > > Christian Vogt raised a point at the mic during the WG meeting that =20 > > the LISP as a whole system appeared to be getting very complex and =20 > > cautioned that complex systems are hard to deploy and manage. Dave =20 > > Meyer commented that trying to evaluate complexity was hard/subjective = =20 > > and we should not rat-hole on discussing LISP's complexity. > >=20 > > I don't have an opinion on whether LISP (as a system) is complex or =20 > > not, whether the complexity justified or gratuitous, or whether the =20 > > complexity represents a serious barrier to deployment and operation. I = =20 > > do, however, disagree with Dave Meyer that we don't have pretty good = =20 > > objective criteria for evaluating complexity, and that it would be =20 > > good to apply these to assessing LISP's complexity. > =20 > Well, what I intended was that it is not all that useful > to make statements like "addition of components makes > things more complicated". > =20 > > WG co-chair Sam Hartman asked me to document what I thought these =20 > > objective criteria were. This is by no means a complete list, but =20 > > includes: > >=20 > > - How big is the total state space of the system, and how does it =20 > > scale with the number of elements participating. > >=20 > > - How many elements of the system need to change state when a single = =20 > > event occurs (events include boxes going up/down, routes changing, EID = =20 > > prefixes being added/removed, RLOCs being added removed, etc.) > >=20 > > - How many individual logical elements are involved in each primitive = =20 > > operation of the system (e.g. resolving a MAP request) such that =20 > > either the operation fails (in the absence of redundancy) or requires = =20 > > high-reliability machinery to provide acceptable availability. > >=20 > > - How many individual elements need hand configuration to provision =20 > > and manage the system. How does this scale with the number of sites, = =20 > > service providers, and registries. > >=20 > > - How many administrative domains are involved in the consistent =20 > > operation of the system, and how many configuration and policy =20 > > elements need to be coordinated across those boundaries. > >=20 > > I would assert that at best these are actually measurable, and at =20 > > worst can be loosely assessed. > =20 > No disagreement with what you've said here. But taking > data points (measurement) or even systematic "loose > assessment" is a qualitatively different statement than > what I was responding to. > =20 > Dave > =20 > =09 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknKbYAACgkQF0TR2hENFAQuTQCbBQh9kdm2FlfcErAVYhXf/MhL cZIAoLAl6lHMF1Ju6xXtl46JuqIzeHiA =TQaA -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz-- From oran@cisco.com Wed Mar 25 10:21:35 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946343A6D6A for ; Wed, 25 Mar 2009 10:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.627 X-Spam-Level: X-Spam-Status: No, score=-6.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk88vZ5q1ClP for ; Wed, 25 Mar 2009 10:21:34 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9E1863A68AB for ; Wed, 25 Mar 2009 10:21:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,420,1233532800"; d="scan'208";a="146515943" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2009 17:21:44 +0000 Received: from sjc-vpnasa1-44.cisco.com ([10.21.104.44]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id n2PGhqn3024003; Wed, 25 Mar 2009 08:43:52 -0800 Message-Id: <426ADC97-57AF-4503-9495-AA7531218B56@cisco.com> From: David R Oran To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 10:21:44 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2094; t=1237999432; x=1238863432; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20My=20comment=20at=20the=20mic=20during=20the=20 WG=20meeting=20about=20evaluating/measuring=20complexity |Sender:=20 |To:=20lisp@ietf.org; bh=eT+AYpnQtmR60osXeJWFWvsWG7Pc8svZJQqrOmKG9Ns=; b=LXMDFpbTJ2BFuokHTwWD5iyVlOvw+0MgunSSNMkZpSStbJ/XPOv+Uv9JgX KOJZI/StoYA27rbhwZZYk54ORlVBjmb3Z2Q+G4DKy9aOInlc60ueHmiAHZCX j7XUaLonbH; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Mailman-Approved-At: Wed, 25 Mar 2009 10:50:20 -0700 Subject: [lisp] My comment at the mic during the WG meeting about evaluating/measuring complexity X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:21:35 -0000 Christian Vogt raised a point at the mic during the WG meeting that the LISP as a whole system appeared to be getting very complex and cautioned that complex systems are hard to deploy and manage. Dave Meyer commented that trying to evaluate complexity was hard/subjective and we should not rat-hole on discussing LISP's complexity. I don't have an opinion on whether LISP (as a system) is complex or not, whether the complexity justified or gratuitous, or whether the complexity represents a serious barrier to deployment and operation. I do, however, disagree with Dave Meyer that we don't have pretty good objective criteria for evaluating complexity, and that it would be good to apply these to assessing LISP's complexity. WG co-chair Sam Hartman asked me to document what I thought these objective criteria were. This is by no means a complete list, but includes: - How big is the total state space of the system, and how does it scale with the number of elements participating. - How many elements of the system need to change state when a single event occurs (events include boxes going up/down, routes changing, EID prefixes being added/removed, RLOCs being added removed, etc.) - How many individual logical elements are involved in each primitive operation of the system (e.g. resolving a MAP request) such that either the operation fails (in the absence of redundancy) or requires high-reliability machinery to provide acceptable availability. - How many individual elements need hand configuration to provision and manage the system. How does this scale with the number of sites, service providers, and registries. - How many administrative domains are involved in the consistent operation of the system, and how many configuration and policy elements need to be coordinated across those boundaries. I would assert that at best these are actually measurable, and at worst can be loosely assessed. DaveO. "Make everything as simple as possible, but not simpler." - Albert Einstein. From dmm@cisco.com Wed Mar 25 10:26:36 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6EB3A6A9A for ; Wed, 25 Mar 2009 10:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=3.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmmHEmceG6kd for ; Wed, 25 Mar 2009 10:26:35 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A7A563A6A79 for ; Wed, 25 Mar 2009 10:26:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,420,1233532800"; d="scan'208";a="146653902" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2009 17:27:28 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2PHRSIA029355 for ; Wed, 25 Mar 2009 10:27:28 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2PHRSm9001064 for ; Wed, 25 Mar 2009 17:27:28 GMT Received: (from dmm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA08025; Wed, 25 Mar 2009 10:25:55 -0700 (PDT) X-Authentication-Warning: pita.cisco.com: dmm set sender to dmm@cisco.com using -f Date: Wed, 25 Mar 2009 10:25:55 -0700 From: David Meyer To: David R Oran Message-ID: <20090325172555.GB6690@cisco.com> References: <426ADC97-57AF-4503-9495-AA7531218B56@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426ADC97-57AF-4503-9495-AA7531218B56@cisco.com> User-Agent: Mutt/1.4i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2500; t=1238002048; x=1238866048; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dmm@cisco.com; z=From:=20David=20Meyer=20 |Subject:=20Re=3A=20My=20comment=20at=20the=20mic=20during= 20the=20WG=20meeting=20about=20evaluating/measuring=20comple xity |Sender:=20; bh=2dhnzPEkl+QCwHudK75mZTyZx1M9xF1EhdJXT1LKJZk=; b=mid/tdLlp6x3kJk6/cikVdAkrgnBtYg5h+OWoXXzcuKBJGylP6KyVVMfje yn/7SCWnlRxgxrMlKV5ZBpfiOLRQ4Bee9fJEr43r3mToBH5kU8qNntM+4XLk tptgAqL3VQ; Authentication-Results: sj-dkim-3; header.From=dmm@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Mailman-Approved-At: Wed, 25 Mar 2009 10:50:20 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] My comment at the mic during the WG meeting about evaluating/measuring complexity X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:26:36 -0000 On Wed, Mar 25, 2009 at 10:21:44AM -0700, David R Oran wrote: > Christian Vogt raised a point at the mic during the WG meeting that > the LISP as a whole system appeared to be getting very complex and > cautioned that complex systems are hard to deploy and manage. Dave > Meyer commented that trying to evaluate complexity was hard/subjective > and we should not rat-hole on discussing LISP's complexity. > > I don't have an opinion on whether LISP (as a system) is complex or > not, whether the complexity justified or gratuitous, or whether the > complexity represents a serious barrier to deployment and operation. I > do, however, disagree with Dave Meyer that we don't have pretty good > objective criteria for evaluating complexity, and that it would be > good to apply these to assessing LISP's complexity. Well, what I intended was that it is not all that useful to make statements like "addition of components makes things more complicated". > > WG co-chair Sam Hartman asked me to document what I thought these > objective criteria were. This is by no means a complete list, but > includes: > > - How big is the total state space of the system, and how does it > scale with the number of elements participating. > > - How many elements of the system need to change state when a single > event occurs (events include boxes going up/down, routes changing, EID > prefixes being added/removed, RLOCs being added removed, etc.) > > - How many individual logical elements are involved in each primitive > operation of the system (e.g. resolving a MAP request) such that > either the operation fails (in the absence of redundancy) or requires > high-reliability machinery to provide acceptable availability. > > - How many individual elements need hand configuration to provision > and manage the system. How does this scale with the number of sites, > service providers, and registries. > > - How many administrative domains are involved in the consistent > operation of the system, and how many configuration and policy > elements need to be coordinated across those boundaries. > > I would assert that at best these are actually measurable, and at > worst can be loosely assessed. No disagreement with what you've said here. But taking data points (measurement) or even systematic "loose assessment" is a qualitatively different statement than what I was responding to. Dave From oran@cisco.com Wed Mar 25 10:49:32 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144B93A6976 for ; Wed, 25 Mar 2009 10:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.626 X-Spam-Level: X-Spam-Status: No, score=-6.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Thrsf-QWrGgJ for ; Wed, 25 Mar 2009 10:49:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0007D3A67B4 for ; Wed, 25 Mar 2009 10:49:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,420,1233532800"; d="scan'208";a="146668778" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2009 17:50:23 +0000 Received: from sjc-vpnasa1-44.cisco.com ([10.21.104.44]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id n2PHCVAl025182; Wed, 25 Mar 2009 09:12:31 -0800 Message-Id: From: David R Oran To: Scott Brim In-Reply-To: <20090325174432.GO1112@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 10:50:23 -0700 References: <426ADC97-57AF-4503-9495-AA7531218B56@cisco.com> <20090325172555.GB6690@cisco.com> <20090325173749.GA15700@1-4-5.net> <20090325174432.GO1112@cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3911; t=1238001151; x=1238865151; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[lisp]=20My=20comment=20at=20the=20mic= 20during=20the=20WG=20meeting=20about=20evaluating/measuring =20complexity |Sender:=20 |To:=20Scott=20Brim=20; bh=TAeCd72+5tHAiXanUabmWfjJ2KGDWlC5SKha6FbiYlc=; b=pfKGvOdwh9jEYRLA9J+UWPCnBwU3Z5dweS7dLXNTwqtihkIDPjIRcRsxDS 0Q7G4JATLpYhGya6yKpmLLmaqz1+qrQSyll7aPiGCvYmeihbie6hC5JmAdSv cYJZoT3iTG; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Mailman-Approved-At: Wed, 25 Mar 2009 10:50:20 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] My comment at the mic during the WG meeting about evaluating/measuring complexity X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:49:32 -0000 On Mar 25, 2009, at 10:44 AM, Scott Brim wrote: > This is all excellent, but there's a criterion missing that I don't > know how to name ... something about the organization of the elements > involved in a change. If a change propagates hierarchically that's > less complexity than if a change propagates, is reflected back toward > the origin, and elements which have already changed have to change > again until balance is achieved. In particular I don't think lisp-ms > adds particularly to the _overall_ system complexity because it is > peripheral and a particular change only flows in one direction. > True (of course) but it's a second order effect - trees trade off protocol/topology simplicity for single points of failure (each down branch) that in turn my require other complexity to ensure robustness (e.g. high-reliability or redundant components). Basically, you can push the complexity around, but at first order if the element count is large the complexity increases. > swb > > Excerpts from David Meyer on Wed, Mar 25, 2009 10:37:49AM -0700: >> On Wed, Mar 25, 2009 at 10:25:55AM -0700, David Meyer wrote: >>> On Wed, Mar 25, 2009 at 10:21:44AM -0700, David R Oran wrote: >>> Christian Vogt raised a point at the mic during the WG meeting that >>> the LISP as a whole system appeared to be getting very complex and >>> cautioned that complex systems are hard to deploy and manage. Dave >>> Meyer commented that trying to evaluate complexity was hard/ >>> subjective >>> and we should not rat-hole on discussing LISP's complexity. >>> >>> I don't have an opinion on whether LISP (as a system) is complex or >>> not, whether the complexity justified or gratuitous, or whether the >>> complexity represents a serious barrier to deployment and >>> operation. I >>> do, however, disagree with Dave Meyer that we don't have pretty good >>> objective criteria for evaluating complexity, and that it would be >>> good to apply these to assessing LISP's complexity. >> >> Well, what I intended was that it is not all that useful >> to make statements like "addition of components makes >> things more complicated". >> >>> WG co-chair Sam Hartman asked me to document what I thought these >>> objective criteria were. This is by no means a complete list, but >>> includes: >>> >>> - How big is the total state space of the system, and how does it >>> scale with the number of elements participating. >>> >>> - How many elements of the system need to change state when a single >>> event occurs (events include boxes going up/down, routes changing, >>> EID >>> prefixes being added/removed, RLOCs being added removed, etc.) >>> >>> - How many individual logical elements are involved in each >>> primitive >>> operation of the system (e.g. resolving a MAP request) such that >>> either the operation fails (in the absence of redundancy) or >>> requires >>> high-reliability machinery to provide acceptable availability. >>> >>> - How many individual elements need hand configuration to provision >>> and manage the system. How does this scale with the number of sites, >>> service providers, and registries. >>> >>> - How many administrative domains are involved in the consistent >>> operation of the system, and how many configuration and policy >>> elements need to be coordinated across those boundaries. >>> >>> I would assert that at best these are actually measurable, and at >>> worst can be loosely assessed. >> >> No disagreement with what you've said here. But taking >> data points (measurement) or even systematic "loose >> assessment" is a qualitatively different statement than >> what I was responding to. >> >> Dave >> >> > > > >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > From dow.street@linquest.com Wed Mar 25 11:05:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89AFA3A6D68 for ; Wed, 25 Mar 2009 11:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvpRqmMhHWG5 for ; Wed, 25 Mar 2009 11:05:32 -0700 (PDT) Received: from smtp136.sat.emailsrvr.com (smtp136.sat.emailsrvr.com [66.216.121.136]) by core3.amsl.com (Postfix) with ESMTP id 7ED453A6822 for ; Wed, 25 Mar 2009 11:05:32 -0700 (PDT) Received: from relay23.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay23.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id DA6CA1B40B8 for ; Wed, 25 Mar 2009 14:06:24 -0400 (EDT) Received: by relay23.relay.sat.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 8C5451B40B0 for ; Wed, 25 Mar 2009 14:06:24 -0400 (EDT) Message-Id: <2ABFC26A-854D-416F-BB8B-2BFE60DCB812@linquest.com> From: Dow Street To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 11:06:08 -0700 X-Mailer: Apple Mail (2.930.3) Subject: Re: [lisp] Charter for discussion at today's meeting X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:05:33 -0000 Some possible re-wording for the charter text: The basic idea behind the separation that the Internet architecture combines two functions, Routing Locators, (where you are attached to the network) and Identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the Internet address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. Locator/Identifier separation approaches are rooted in the premise that the current Internet architecture often uses a single IP address (i.e. name) for two distinctly different roles: Routing Locators (which describe "where" you are attached to the network) and Identifiers (which describe "who" you are). Proponents of separation approaches postulate that acknowledging these two distinct functions, and using different names when referencing them, can yield several advantages. LISP attempts to leverage such a split to improve scalability of the routing system. A Locator/Identifier split can be applied at different points in the architecture, and when applied, establishes two namespaces of different scopes where there was previously a single namespace. The two new namespaces may be similar to, or differ from, both the previous single namespace and each other. For example, the Host Identity Protocol (HIP) applies a split within the host, where the HIP "Locator" namespace retains the structure and location semantics of an IP address, but the "Identifier" namespace has notably different properties. In contrast, LISP applies a Locator/Identifier split within the network topology, following a network-based map-and- encapsulation scheme (RFC 1955). In LISP, both locators and identifiers are structurally equivalent to IP addresses. A primary function of LISP is to establish these two namespaces and to provide a function for mapping an identifier into a set of locators that can reach the identified interface. A LISP identifier itself is semantically defined to be composed of two parts: a "global" portion that uniquely identifies a particular site (i.e. sub-graph of the network topology) and a "local" portion that identifies an interface within a site. Only the "global" portion of the identifier is relevant when conducting this mapping function. In LISP, when a host moves from one site to another, or moves between subnets within a site, a new locator-to-identifier mapping would generally be triggered. This layer of indirection allows the routing locator space to retain an aggregatable structure, without requiring changes to identifiers, across several types of topology change events. Although LISP uses an IP address for both the "Locator" and "Identifier" name, in general these namespaces are discrete. From dow.street@linquest.com Wed Mar 25 11:08:13 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E2C3A6849 for ; Wed, 25 Mar 2009 11:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va1CtyYJ4RmO for ; Wed, 25 Mar 2009 11:08:12 -0700 (PDT) Received: from smtp136.sat.emailsrvr.com (smtp136.sat.emailsrvr.com [66.216.121.136]) by core3.amsl.com (Postfix) with ESMTP id CA6B63A6AEB for ; Wed, 25 Mar 2009 11:07:58 -0700 (PDT) Received: from relay23.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay23.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 438A01B4016 for ; Wed, 25 Mar 2009 14:08:51 -0400 (EDT) Received: by relay23.relay.sat.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 03D681B400F for ; Wed, 25 Mar 2009 14:08:50 -0400 (EDT) Message-Id: From: Dow Street To: lisp@ietf.org In-Reply-To: <2ABFC26A-854D-416F-BB8B-2BFE60DCB812@linquest.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 11:08:50 -0700 References: <2ABFC26A-854D-416F-BB8B-2BFE60DCB812@linquest.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [lisp] Charter for discussion at today's meeting X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:08:13 -0000 Lost some line breaks in there somehow... R, Dow On Mar 25, 2009, at 11:06 AM, Dow Street wrote: Some possible re-wording for the charter text: The basic idea behind the separation that the Internet architecture combines two functions, Routing Locators, (where you are attached to the network) and Identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the Internet address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. Locator/Identifier separation approaches are rooted in the premise that the current Internet architecture often uses a single IP address (i.e. name) for two distinctly different roles: Routing Locators (which describe "where" you are attached to the network) and Identifiers (which describe "who" you are). Proponents of separation approaches postulate that acknowledging these two distinct functions, and using different names when referencing them, can yield several advantages. LISP attempts to leverage such a split to improve scalability of the routing system. A Locator/Identifier split can be applied at different points in the architecture, and when applied, establishes two namespaces of different scopes where there was previously a single namespace. The two new namespaces may be similar to, or differ from, both the previous single namespace and each other. For example, the Host Identity Protocol (HIP) applies a split within the host, where the HIP "Locator" namespace retains the structure and location semantics of an IP address, but the "Identifier" namespace has notably different properties. In contrast, LISP applies a Locator/Identifier split within the network topology, following a network-based map-and- encapsulation scheme (RFC 1955). In LISP, both locators and identifiers are structurally equivalent to IP addresses. A primary function of LISP is to establish these two namespaces and to provide a function for mapping an identifier into a set of locators that can reach the identified interface. A LISP identifier itself is semantically defined to be composed of two parts: a "global" portion that uniquely identifies a particular site (i.e. sub-graph of the network topology) and a "local" portion that identifies an interface within a site. Only the "global" portion of the identifier is relevant when conducting this mapping function. In LISP, when a host moves from one site to another, or moves between subnets within a site, a new locator-to-identifier mapping would generally be triggered. This layer of indirection allows the routing locator space to retain an aggregatable structure, without requiring changes to identifiers, across several types of topology change events. Although LISP uses an IP address for both the "Locator" and "Identifier" name, in general these namespaces are discrete. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From jzwiebel@cisco.com Wed Mar 25 11:50:00 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2823A6D84 for ; Wed, 25 Mar 2009 11:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1oobnvGoiFB for ; Wed, 25 Mar 2009 11:49:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 722883A67F3 for ; Wed, 25 Mar 2009 11:49:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,420,1233532800"; d="scan'208,217";a="274046595" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Mar 2009 18:50:52 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2PIoqiq029452; Wed, 25 Mar 2009 11:50:52 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2PIoq2J013041; Wed, 25 Mar 2009 18:50:52 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 11:50:51 -0700 Received: from [10.0.1.4] ([10.21.123.168]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 11:50:51 -0700 In-Reply-To: <49C9AD73.2070102@firstpr.com.au> References: <49C9AD73.2070102@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-46--145676521 Message-Id: <59368833-6E24-4B9F-A224-1F8F23E7D278@cisco.com> From: John Zwiebel Date: Wed, 25 Mar 2009 08:50:44 -1000 To: Robin Whittle X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 25 Mar 2009 18:50:51.0716 (UTC) FILETIME=[9EB6B840:01C9AD7A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2406; t=1238007052; x=1238871052; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[lisp]=20Consensus?=20EID=20and=20RLOC= 20use=20of=20the=20same=20address=20=3D=20separate=20namespa ce=20debate |Sender:=20; bh=w7FpFyjnTv/R2btGlRdr1qcZwJ5lyhgs+XaU/5KahEo=; b=ZOyJjx6C7ng9n8ACjSJNotNu4TwgsTZCk4L74BiJWpv9pqyjDfI/4STL2E RkEcUGmjl6Rr9rPTMP9xjsms0LHwJ7qAXYuxqgEPJMs5PB3KdN7W8Fq8Htsi 2y08f+YC4uCpe5u2BKi5AP/B8zTnLozvQViPCNo2+8Yzsz5BRjLK0=; Authentication-Results: sj-dkim-1; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Consensus? EID and RLOC use of the same address = separate namespace debate X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:50:00 -0000 --Apple-Mail-46--145676521 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 24, 2009, at 6:05 PM, Robin Whittle wrote: > > Since 2007-01 draft-farinacci-lisp-00 to 12 has > this as an absolute requirement: > > EIDs MUST NOT be used as LISP RLOCs. This does not say you can't use the same IP address for an EID and for an RLOC. It says EID and RLOC functions cannot be assigned to the same interface at the same time. Or, another way of looking at it, an interface cannot be in EID space and in RLOC space. --Apple-Mail-46--145676521 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Mar 24, 2009, at 6:05 PM, Robin Whittle wrote:


=A0=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Since 2007-01 draft-farinacci-lisp-00 to 12 = has

=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = this as an absolute requirement:


=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = EIDs MUST NOT be used as LISP RLOCs.

=


This does not say you can't = use the same IP address for an EID
and for an RLOC. = =A0

It says =A0EID and =A0RLOC functions cannot = be assigned to
the same interface at the same = time.

Or, another way of looking at it, an = interface cannot be in EID space
and in RLOC = space.
= --Apple-Mail-46--145676521-- From jnc@mercury.lcs.mit.edu Wed Mar 25 12:30:19 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0FE3A6BA5 for ; Wed, 25 Mar 2009 12:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxjWdHaHz5Ds for ; Wed, 25 Mar 2009 12:30:18 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 34CED3A6830 for ; Wed, 25 Mar 2009 12:30:17 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 88E016BE555; Wed, 25 Mar 2009 15:31:09 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090325193109.88E016BE555@mercury.lcs.mit.edu> Date: Wed, 25 Mar 2009 15:31:09 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] My comment at the mic during the WG meeting about evaluating/measuring complexity X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 19:30:19 -0000 > From: Scott Brim > In particular I don't think lisp-ms adds particularly to the _overall_ > system complexity There is also the point that there is system _complexity_, and then there are system _evolvability_, system _flexibility_, system _robustness_, etc. These latter are both i) important, and ii) hard to measure, and increasing these latter measures often involves some extra complexity. LISP-MS is an excellent example of this; it insulates the xTRs from the mapping system, so that if we change ALT, or replace it, we have to only modify the MSs to do so, not all the xTRs. Noel From HeinerHummel@aol.com Wed Mar 25 12:33:55 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E981D3A6BAC for ; Wed, 25 Mar 2009 12:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.582 X-Spam-Level: * X-Spam-Status: No, score=1.582 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzSJqKWFv+Ww for ; Wed, 25 Mar 2009 12:33:55 -0700 (PDT) Received: from imr-d02.mx.aol.com (imr-d02.mx.aol.com [205.188.157.40]) by core3.amsl.com (Postfix) with ESMTP id 061013A6BA4 for ; Wed, 25 Mar 2009 12:33:54 -0700 (PDT) Received: from HeinerHummel@aol.com by imr-d02.mx.aol.com (mail_out_v39.1.) id c.c9e.4a4f53ae (30740); Wed, 25 Mar 2009 15:32:55 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Wed, 25 Mar 2009 15:32:52 EDT To: jzwiebel@cisco.com, rw@firstpr.com.au MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1238009572" X-Mailer: 9.0 SE for Windows sub 5021 Cc: lisp@ietf.org Subject: Re: [lisp] Consensus? EID and RLOC use of the same address = separate namespa... X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 19:33:56 -0000 -------------------------------1238009572 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 I think much more important is the implicit statement, that for RLOCs no ne= w=20 (routable) namespace shall be applied (although the potential is given). =20 Instead the namespace of IPv4 shall concurrently be used for RLOC addressin= g as=20 well as for EID addressing. Of course, as no EID is also an RLOC, this also= =20 means that RLOC addresses are different from EID addresses. =20 Right? =20 Heiner =20 =20 In einer eMail vom 25.03.2009 19:51:12 Westeurop=E4ische Normalzeit schreibt= =20 jzwiebel@cisco.com: =20 On Mar 24, 2009, at 6:05 PM, Robin Whittle wrote: Since 2007-01 draft-farinacci-lisp-00 to 12 has=20 this as an absolute requirement:=20 EIDs MUST NOT be used as LISP RLOCs. This does not say you can't use the same IP address for an EID and for an RLOC. =20 It says EID and RLOC functions cannot be assigned to the same interface at the same time. Or, another way of looking at it, an interface cannot be in EID space and in RLOC space. =3D _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp -------------------------------1238009572 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I think much more important is the implicit statement, that for RLOCs n= o=20 new (routable) namespace shall be applied (although the potential is given).= =20 Instead the namespace of IPv4 shall concurrently be used for RLOC=20 addressing as well as for EID addressing. Of course, as no EI= D is=20 also an RLOC, this also means that RLOC addresses are different from EID=20 addresses.
 
Right?
 
Heiner
 
 
In einer eMail vom 25.03.2009 19:51:12 Westeurop=E4ische Normalzeit sch= reibt=20 jzwiebel@cisco.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>
On Mar 24, 2009, at 6:05 PM, Robin Whittle wrote:


      =20=  =20         Since 2007-01 draft-farinacci-lisp-00= to=20 12 has

      =20=  =20         this as an absolute=20 requirement:


      =20=  =20           EIDs MUST NOT be used as LISP=20 RLOCs.



This does not say you can't use the same IP address for an EID
and for an RLOC.  

It says  EID and  RLOC functions cannot be assigned to
the same interface at the same time.

Or, another way of looking at it, an interface cannot be in EID=20 space
and in RLOC=20 space.
=3D

_______________________________________________
= lisp=20 mailing=20 list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
 
 -------------------------------1238009572-- From jnc@mercury.lcs.mit.edu Wed Mar 25 13:04:03 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927203A6D81 for ; Wed, 25 Mar 2009 13:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5CgbPmgSb8f for ; Wed, 25 Mar 2009 13:04:02 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id B90D93A6B91 for ; Wed, 25 Mar 2009 13:04:02 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 41D4A6BE555; Wed, 25 Mar 2009 16:04:54 -0400 (EDT) To: lisp@ietf.org, roque@lacnic.net Message-Id: <20090325200454.41D4A6BE555@mercury.lcs.mit.edu> Date: Wed, 25 Mar 2009 16:04:54 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Using Signed object to validate entries in Mapping Database: draft-lisp-rgaglian-ioa-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:04:03 -0000 > From: Roque Gagliano I looked briefly at the draft, but don't have any comment on it, because it's mostly about the certificate formats and such, and crypto-stuff is not something I have much expertise in. However, this caught my eye: > The way that RPKI works is by using a distributed repository where each > signed object (ie certificates, ioa, roas) mentions the location of its > repository. .. the RIR have a repository for the first two layers > of material (certificates to ISPs) but the ISP then can implement their > own CA and their own repository to host its signed objects (ie ioas). > The protocol propossed to fetch all these object from various > repositories is rsync and normally a relying party has a local cache > with all the material that has download. One thing that I was very concerned about was latency. Having signed mappings is not that useful if checking the signing requires another round-trip delay (after the pontetial round-trip delay to get the mapping to begin with) to get information needed to verify the signing. (Although I suppose one could start using the mapping, while checking it in parallel with that.) (The particular mechanism I came up with for CONS was intended to entirely eliminate such a delay; with it, an ITR needs only a small number of keys, which it can pre-load, to verify the signing on any mapping.) It wasn't clear to me, looking quickly at the draft, how the whole thing worked at a high level (e.g. 'ITR gets a mapping, it wants to check the signing, and the following N things happen'), so I don't know if that is an issue here. > There is a lap that by design we took as 24hs from time I update my > repository until every party has the latest copy. Doed everything get flooded out to all the repositories (i.e. every key)? The notion of tying things to the existing delegation at the RIRs is a good one, though. Noel From olivier.bonaventure@uclouvain.be Wed Mar 25 13:12:17 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335CA3A63D2 for ; Wed, 25 Mar 2009 13:12:17 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urTAGACbvRdZ for ; Wed, 25 Mar 2009 13:12:16 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id EE8103A68A7 for ; Wed, 25 Mar 2009 13:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=QqSGAZ3a1i/bb3UL8hoe1o1+98g=; b=f7Ws0/Q+sm eyZEgnqhh5+fV0fYSGHV8RsYishe0Z16wY4FKHDVL/UHpHH2RUkc8sEYM4vRYMRI UJEBisX1uSghJat6Ze4Wg80xEtQF/iz/uwTNANpWr7O7QNO5lVnA2DwhqKOYRxYd ztSKe87DdJEVuylIXLbN2mqhfVazYo5t4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=NkDBp 5qihhllZ17NSpYM2p+himKaSsKP2zGyvXofbw5BNbaMlVeottr/EckxoJ0N6d30w lGph621wqlDfuKjM3Dk5E0405PlKPOF2GZCFmWmDrW9ihVyf+Rq5/2rtNZtQ1feu WDicTdSw6NvzALTF2RTZ4l+FRRKdt+HXZ83ovI= Received: from mbpobo.local (ip-83-134-220-195.dsl.scarlet.be [83.134.220.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Wed, 25 Mar 2009 21:13:04 +0100 (CET) Message-ID: <49CA9048.7030502@uclouvain.be> Date: Wed, 25 Mar 2009 21:12:56 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Noel Chiappa References: <20090325154807.DF3336BE555@mercury.lcs.mit.edu> In-Reply-To: <20090325154807.DF3336BE555@mercury.lcs.mit.edu> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 6D8AACF314.A7B0D X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Using Signed object to validate entries in Mapping Database: draft-lisp-rgaglian-ioa-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 25 Mar 2009 20:12:17 -0000 Noel, > > From: Olivier Bonaventure > > > Securing the mapping system is an important problem that hasn't > > received enough attention on the lisp mailing list. > > On this list, no. But the problem of securing the system by signing bindings > has received a fair amount of attention, in particular in the context of > CONS. See, for instance, this message to the RRG mailing list: > > http://www.ietf.org/mail-archive/web/rrg/current/msg01077.html > > and following messages on that date and following days, starting here: > > http://www.ietf.org/mail-archive/web/rrg/current/mail142.html Thanks, I'll check these discussions. > I'm not sure how much security we need in this trial. I _do_ think (as > earlier messages indicated, peripherally) that we need to make _provision_ > for better security down the road (the 'authentication type/authentication > data' fields I mentioned), Having provision for authentication is the minimum, but I think that security could be part of the experiment. > but beyond that I think we can probably avoid > opening that can of worms for the moment. If we delay discussions about security problems, I guess that they will come back later and that we'll have lots of difficulty solving them. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From jnc@mercury.lcs.mit.edu Wed Mar 25 13:27:49 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22ADD3A6806 for ; Wed, 25 Mar 2009 13:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Orgm7CGwtRFe for ; Wed, 25 Mar 2009 13:27:48 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 5F4EA3A67F4 for ; Wed, 25 Mar 2009 13:27:48 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9554B6BE555; Wed, 25 Mar 2009 16:28:40 -0400 (EDT) To: lisp@ietf.org, Olivier.Bonaventure@uclouvain.be Message-Id: <20090325202840.9554B6BE555@mercury.lcs.mit.edu> Date: Wed, 25 Mar 2009 16:28:40 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Using Signed object to validate entries in Mapping Database: draft-lisp-rgaglian-ioa-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:27:49 -0000 > From: Olivier Bonaventure > If we delay discussions about security problems, I guess that they will > come back later and that we'll have lots of difficulty solving them. I agree we should make certain that LISP is _securable_, even if we don't actually deploy that securitization at this point. However, I wonder if such work would conflict with the limited WG charter? Although I suppose it could always be peformed as a non-WG activity. Another issue would be if there is some question about the performance impact, one which could only really be answered to everyone's satisfaction with actual emperical data (much as some people are concerned with mapping lookup delays, caching mappings, etc); we might have to do some deployment to fully answer that. Noel From roque@lacnic.net Wed Mar 25 13:43:55 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963263A6806 for ; Wed, 25 Mar 2009 13:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0ctaOn1+Mit for ; Wed, 25 Mar 2009 13:43:54 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id 2D80E3A67ED for ; Wed, 25 Mar 2009 13:43:54 -0700 (PDT) Received: from [IPv6:2001:13c7:7001:5064:323:45ff:fe67:78ab] (unknown [IPv6:2001:13c7:7001:5064:323:45ff:fe67:78ab]) by mail.lacnic.net.uy (Postfix) with ESMTP id DB58A3084D4; Wed, 25 Mar 2009 17:44:33 -0300 (UYT) Message-Id: <590FBEB1-826C-4C42-9A78-F88918CA0774@lacnic.net> From: Roque Gagliano To: Noel Chiappa In-Reply-To: <20090325200454.41D4A6BE555@mercury.lcs.mit.edu> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-51--138850222" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 13:44:31 -0700 References: <20090325200454.41D4A6BE555@mercury.lcs.mit.edu> X-Pgp-Agent: GPGMail d55 (v55, Leopard) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.930.3) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Cc: lisp@ietf.org Subject: Re: [lisp] Using Signed object to validate entries in Mapping Database: draft-lisp-rgaglian-ioa-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:43:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-51--138850222 Content-Type: multipart/alternative; boundary=Apple-Mail-50--138850282 --Apple-Mail-50--138850282 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Noel, You may want to read the following draft to get an idea of how the SIDR architecture works. Roque http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-06.txt > > >> There is a lap that by design we took as 24hs from time I update my >> repository until every party has the latest copy. > > Doed everything get flooded out to all the repositories (i.e. every > key)? > > > The notion of tying things to the existing delegation at the RIRs is a > good one, though. > > Noel --Apple-Mail-50--138850282 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable h= ttp://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-06.txt



There is a lap that by design we took as 24hs from time I = update my
repository until = every party has the latest copy.

Doed everything get = flooded out to all the repositories (i.e. every key)?


The = notion of tying things to the existing delegation at the RIRs is = a
good one, though.

= Noel

= --Apple-Mail-50--138850282-- --Apple-Mail-51--138850222 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknKl68ACgkQnk+WSgHpbO5yQACeNWa/gCV5N70AjdPAFcajQpqj yLoAoIwGRYJCXcZuAnq3eqU41nPmVD4I =jHcT -----END PGP SIGNATURE----- --Apple-Mail-51--138850222-- From hartmans@mit.edu Wed Mar 25 16:26:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255F13A6D9C for ; Wed, 25 Mar 2009 16:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIHjxrq2I5d4 for ; Wed, 25 Mar 2009 16:26:15 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.87.223]) by core3.amsl.com (Postfix) with ESMTP id 8BA7F3A6C3C for ; Wed, 25 Mar 2009 16:26:15 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 53363414C; Wed, 25 Mar 2009 19:27:08 -0400 (EDT) To: Dow Street References: <2ABFC26A-854D-416F-BB8B-2BFE60DCB812@linquest.com> From: Sam Hartman Date: Wed, 25 Mar 2009 19:27:08 -0400 In-Reply-To: <2ABFC26A-854D-416F-BB8B-2BFE60DCB812@linquest.com> (Dow Street's message of "Wed\, 25 Mar 2009 11\:06\:08 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Charter for discussion at today's meeting X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:26:16 -0000 Hi. based on your wording, I'm interpreting your proposal as a set of wording suggestions that you think may improve the charter, but not an objection to the current text. I'd appreciate comments on your rewording. However I'll note that you are rewording a fairly long-standing part of the charter and bringing up a bunch of words and issues that have falied to gain consensus in previous discussions. So, my guess is that we will not get consensus behind this. From hartmans@mit.edu Wed Mar 25 16:27:49 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5CB73A6AAF for ; Wed, 25 Mar 2009 16:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQQKvLSwADFc for ; Wed, 25 Mar 2009 16:27:49 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.87.223]) by core3.amsl.com (Postfix) with ESMTP id 5AAA73A680C for ; Wed, 25 Mar 2009 16:27:49 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 553B5414C; Wed, 25 Mar 2009 19:28:42 -0400 (EDT) To: David R Oran References: <426ADC97-57AF-4503-9495-AA7531218B56@cisco.com> From: Sam Hartman Date: Wed, 25 Mar 2009 19:28:42 -0400 In-Reply-To: <426ADC97-57AF-4503-9495-AA7531218B56@cisco.com> (David R. Oran's message of "Wed\, 25 Mar 2009 10\:21\:44 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] My comment at the mic during the WG meeting about evaluating/measuring complexity X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:27:50 -0000 Thanks for your criteria. I think it will be valuable to include these in our analysis of LISP. From hartmans@mit.edu Wed Mar 25 16:31:23 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0639928C171 for ; Wed, 25 Mar 2009 16:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKveHoV+iCNs for ; Wed, 25 Mar 2009 16:31:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.87.223]) by core3.amsl.com (Postfix) with ESMTP id 6E19928C24B for ; Wed, 25 Mar 2009 16:31:22 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 572B8414C; Wed, 25 Mar 2009 19:32:15 -0400 (EDT) To: HeinerHummel@aol.com References: From: Sam Hartman Date: Wed, 25 Mar 2009 19:32:15 -0400 In-Reply-To: (HeinerHummel@aol.com's message of "Wed\, 25 Mar 2009 15\:32\:52 EDT") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: rw@firstpr.com.au, lisp@ietf.org Subject: Re: [lisp] Consensus? EID and RLOC use of the same address = separate namespa... X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:31:23 -0000 What do you mean that no EID is also an RLOC? It's not clear to me that in interworking cases this is always true. From dino@cisco.com Wed Mar 25 18:29:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDA528C113 for ; Wed, 25 Mar 2009 18:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cegoffVw0eI for ; Wed, 25 Mar 2009 18:29:51 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 16A5828C10F for ; Wed, 25 Mar 2009 18:29:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,422,1233532800"; d="scan'208";a="68927394" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 26 Mar 2009 01:30:44 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2Q1UiZL004147; Wed, 25 Mar 2009 18:30:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2Q1Ui4h017174; Thu, 26 Mar 2009 01:30:44 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 18:30:43 -0700 Received: from dhcp-51cf.meeting.ietf.org ([10.21.124.160]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 18:30:43 -0700 Message-Id: From: Dino Farinacci To: David Meyer In-Reply-To: <20090325172041.GA14881@1-4-5.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Wed, 25 Mar 2009 18:30:43 -0700 References: <49CA6153.40801@joelhalpern.com> <20090325172041.GA14881@1-4-5.net> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 26 Mar 2009 01:30:43.0601 (UTC) FILETIME=[7AFDD810:01C9ADB2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=896; t=1238031044; x=1238895044; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Interworking=20-=20NAT |Sender:=20; bh=A8nTOFT6KGBcyDVs0BwnJ0+nVE7J8RWZMAcLU51QFlQ=; b=UA7Uir9QIfsvo+BF4vwZmv0sxoi1PCnEEaJDf7gGW34z47aXtpkgRg+J2n uAYfG+YVbCQzAdNkc5+J0YWY9VgexUx4EbxzHcO95zjnm4+kTLHPbp01E3yG 0Vsh0j4/bndU5IN1HGwBz71VsJCNSkC4aC1X2jKkGwXXfhnugyCeI=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Interworking - NAT X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:29:52 -0000 >> n contrast, if folks could get 1-1 NAT for IPv4 now then that would >> be >> a viable solution to a number of real world problems already. We >> as a >> community are looking are recommending something similar as part of >> IPv6 >> (NAT66). If that could be done for v4 in the current world, I am >> not at >> all clear on why a site would bother with the rest of LISP. Given >> typical site attitudes, that sort of NAT would seem sufficient for >> them. > > Perhaps, however, 1-1 NAT still carries a lot of > operational burden for sites deploying the > technology. Deploying PTR infrastructure eases this > burden, and provides quite a bit of additional > functionality. I think of it as a tool in the toolkit > that can be useful in some cases. Also NAT cannot describe TE policy and has issues with asymmetric paths in and out of a site. Dino From rw@firstpr.com.au Wed Mar 25 18:56:57 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E98C28C20F for ; Wed, 25 Mar 2009 18:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZVmPCKDhmV4 for ; Wed, 25 Mar 2009 18:56:55 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 5A8F73A680A for ; Wed, 25 Mar 2009 18:56:55 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 9CAE5175B7B; Thu, 26 Mar 2009 12:57:47 +1100 (EST) Message-ID: <49CAE11C.80802@firstpr.com.au> Date: Thu, 26 Mar 2009 12:57:48 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Consensus? EID and RLOC use of the same address = separate namespace X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:56:57 -0000 Short version: I am perplexed to be defending draft-farinacci-lisp's crystal clear definitions of EID and RLOC against misunderstandings. The definitions are at the end of this message. I am replying to Sam Hartman and John Zweibel. Dino, Vince, David and Darrel: You wrote draft- farinacci-lisp. Can you comment on this debate? Vince, can you describe the definition of "namespace" you used in your presentation today: http://www3.ietf.org/proceedings/09mar/slides/lisp-2.ppt which accords with the prohibition of using an EID as an RLOC? An example of the separate namespaces would help. According to my understanding of the accepted definition of "namespace": http://www.firstpr.com.au/ip/ivip/namespace/ the separate EID and RLOC namespaces you mention mean that a single numeric IP address could be used as both an EID and an RLOC at the same time - and that therefore there must be a mechanism or context by which any device (an ITR or ETR) which needs to distinguish between the two ways of interpreting the address can know whether the address is being used as an EID or as an RLOC. BTW, I haven't yet listened to today's meeting. Hi Sam, I don't understand how you decided, even tentatively, on rough consensus: http://www.ietf.org/mail-archive/web/lisp/current/msg00336.html I think there has been enough discussion on-list and other private comments that the rough consensus of the participants so far is that there will be cases where the same IP stands both as an EID and a RLOC. RFC 2418 considers rough consensus determinations only for mailing list discussions and face-to-face meetings. The "private comments" you mention are not part of either - and are not visible to me or other list participants. The only instance of a list message supporting the view that a single IP address could simultaneously be used as an EID and and RLOC seems to be from Noel: http://www.ietf.org/mail-archive/web/lisp/current/msg00332.html So if it's _possible_ to use the same bit pattern as both an EID and an RLOC, my guess is people will do it, no matter what the documents say. And my take is that, because of _other_ concerns * (e.g. limiting routing overhead), it will be technically * possible, which means people probably will do it no matter what we say in any documents. Noel provides no example of how this would work to counter my argument that it could not work: search for "an ITR will eat its own emitted encapsulated packet" in msg00338.html. You wrote: > What do you mean that no EID is also an RLOC? It's not clear to me > that in interworking cases this is always true. I don't see how "internetworking" affects the draft-farinacci-lisp prohibition of using any address as both an EID and RLOC. In the context of LISP I understand "internetworking" to mean arrangements to enable hosts in networks without ITRs to send packets successfully to host on EID addresses. Proxy Tunnel Routers (PTRs - equivalent to Ivip OITRDs) solve this problem as described in draft-lewis-lisp-interworking-02. Without PTRs (LISP before 2007-12-07) an EID address was not covered by any BGP advertised prefix. So hosts in networks (ISP and end-user) without ITRs could not send a packet to any host with an EID address. I proposed a solution to this on 2007-05-15: http://www.ietf.org/mail-archive/web/ram/current/msg01518.html and this appeared in the first Ivip I-D a month later, as "Anycast ITRs in the core/DFZ". Prompted by a LISP team member who repeatedly reminded that "anycast" was the wrong term, I renamed them to "Open ITRs in the DFZ" (OITRD) in 2008. PTRs and OITRDs are functionally identical, but the business and operational arrangements for LISP are less clear than for Ivip. With PTRs, LISP is potentially practical, since the EID address of some host in an a LISP-mapped EID prefix of an end-user network is part of a prefix which is advertised by one or ideally multiple PTRs in the DFZ. (For scaling reasons, this BGP advertised prefix should cover the EID space of many end-user networks, such as dozens to tens of thousands.) That does not make this host's EID address also an RLOC. The formal definition of RLOC is that it can't be an EID address and that RLOCs must be used for ITR and ETR addresses. As noted below, in actual usage in LISP discussion, I think "RLOC" has come to mean a broader set of IP addresses - I think every global unicast address which is not an EID. If you think that an IP address could be used both as an EID and an RLOC, please show where this is required or allowed for in the LISP I-Ds and give an example of how it would work, ideally in a way which disproves my "ITR will eat its own ..." argument. Hi John, You wrote: >> Since 2007-01 draft-farinacci-lisp-00 to 12 has this as an >> absolute requirement: >> >> EIDs MUST NOT be used as LISP RLOCs. > > This does not say you can't use the same IP address for an EID > and for an RLOC. This is exactly what it says and means. I am giving up my usual "I think ..." stuff because these definitions are completely unambiguous. In LISP (as a practical solution to the routing scaling problem) EIDs and RLOCs are two classes of address within the global unicast address ranges of IPv4 and IPv6. The definitions make it clear that "EID" and "RLOC" are two disjoint sets of addresses: EIDs MUST NOT be used as LISP RLOCs. In LISP discussions, "RLOC" has also frequently been used to refer to an IP address which are used by a host or ordinary router, but which is not an EID and which are not used for ITRs or ETRs. This extends the set of RLOC addresses well beyond those used for ITRs and ETRs. It is my impression that this broader definition of "RLOC" means something like: Any address in the global unicast set of addresses which is not an EID. An EID address is any address which matches a prefix in the mapping database. > It says EID and RLOC functions cannot be assigned to > the same interface at the same time. No it doesn't. EID and RLOC are two separated classes of address. The definitions are purely about addresses and how to use them. There is no mention of interfaces. An interface could have two IP addresses. Address A could be part of the EID subset of the address range and address B could be of the RLOC subset. Then the one interface can function perfectly well as both an RLOC (such as for an ITR or ETR or both functions combined, or as a host or router on non LISP-mapped address space) and also as an EID: as a host or router in an end-user network which uses LISP-mapped address space > Or, another way of looking at it, an interface cannot be in EID > space and in RLOC space. Yes it can, as just described. - Robin There have been no substantial changes in the definition of RLOC and EID since version 00 in January 2007. http://tools.ietf.org/html/draft-farinacci-lisp-12#page-8 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. From dino@cisco.com Wed Mar 25 19:09:09 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD573A6D9F for ; Wed, 25 Mar 2009 19:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycSGixjVsvKq for ; Wed, 25 Mar 2009 19:09:08 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7E42D3A6A10 for ; Wed, 25 Mar 2009 19:09:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,422,1233532800"; d="scan'208";a="161754887" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 26 Mar 2009 02:10:01 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2Q2A1wY012272; Wed, 25 Mar 2009 19:10:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2Q2A1nw020276; Thu, 26 Mar 2009 02:10:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 19:10:01 -0700 Received: from dhcp-51cf.meeting.ietf.org ([10.21.124.160]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 19:10:00 -0700 Message-Id: <95586A33-942B-4285-BDFF-525F56F9E602@cisco.com> From: Dino Farinacci To: Robin Whittle In-Reply-To: <49CAE11C.80802@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Wed, 25 Mar 2009 19:09:59 -0700 References: <49CAE11C.80802@firstpr.com.au> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 26 Mar 2009 02:10:00.0711 (UTC) FILETIME=[F7F04970:01C9ADB7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=648; t=1238033401; x=1238897401; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Consensus?=20EID=20and=20RLOC= 20use=20of=20the=20same=20address=20=3D=20separate=20namespa ce |Sender:=20; bh=tbyj5yAdKjDPiLg8/L+WlHseqwBhLyjpx8CpP3iYlw0=; b=AiqpI2GTQBm5/ZIjdaawCIlrPTghRD/EGnl5nn0POV+T7dKRGq42rWmn8/ Hu2Y6zaKX+T4nI+zEKH+4YEos/2CpUhPJNeRHwTvdiCN3uw9pJpvRShAv4fI 2IOrq4Wr+Ei5rXkeNKW1vIgTuxc0LXFQOY0/hOiYeHkXoM6Ro4D/o=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Consensus? EID and RLOC use of the same address = separate namespace X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:09:09 -0000 > Dino, Vince, David and Darrel: You wrote draft- > farinacci-lisp. Can you comment on this debate? No, I won't. I would rather work on more important problems. I will keep this simple: An EID is a 32-bit address used for socket-id identification in hosts. It is also an interface ID since the host can be multi-homed and attached to the subnets the IGP is routing within the site. An EID is not injected into BGP routing towards the core. An RLOC is the PA IP address assigned to the CE/PE interface of the LISP router that resides at the site. With all due respect, can we move on? Dino From rw@firstpr.com.au Wed Mar 25 19:40:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC0928C1AB for ; Wed, 25 Mar 2009 19:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC-IbzsA8F4f for ; Wed, 25 Mar 2009 19:40:51 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 7C3B23A6809 for ; Wed, 25 Mar 2009 19:40:51 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id C998C175A41; Thu, 26 Mar 2009 13:41:40 +1100 (EST) Message-ID: <49CAEB65.40805@firstpr.com.au> Date: Thu, 26 Mar 2009 13:41:41 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org References: <49CAE11C.80802@firstpr.com.au> <95586A33-942B-4285-BDFF-525F56F9E602@cisco.com> In-Reply-To: <95586A33-942B-4285-BDFF-525F56F9E602@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Consensus? EID and RLOC use of the same address = separate namespace X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:40:52 -0000 Hi Dino, The question of separate namespaces for EIDs and RLOCs is absolutely crucial to the difference between LISP and HIP. HIP requires a separate, new, namespace for EIDs and so cannot be introduced without altering hosts and (I am not sure) perhaps applications too. LISP could use separate namespaces, but for introduction on a voluntary basis for solving the routing scaling problem, it does not use separate namespaces (according to the only definition of the term I can find, and no-one has offered an alternative on this list). LISP EIDs are a subset of the global unicast range of addresses and RLOCs are either another subset, used just for ITRs and ETRs, or are all global unicast addresses which are not EIDs. This means that LISP is potentially practical for introducing on a global basis without upgrading all hosts and/or DFZ routers. LISP *potentially* has separate EID and RLOC namespaces, but that could only be useful in the distant future if there was either an upgrade to all hosts for a new EID namespace or an upgrade to all DFZ and some other routers so the IPv4, IPv6 or some other future global network supported addresses which used a new RLOC namespace. Since "Locator Identifier Separation Protocol" seems to cover the entire field of "Locator Identity Separation" while HIP is also another Locator Identity Split protocol, I and some other people think it is vital that the Charter mention this. While LISP could, in the future, involve separate namespaces, the fact that it can work fine with RLOCs and EIDs being separate subsets of the one global unicast address range (which is a single namespace) is what makes it potentially practical for solving the routing scaling problem. Assuming IPv4, and with the understanding that an EID is for a host in an end-user network using LISP-mapped addresses, your descriptions make sense to me and seem to accord with your I-Ds: > An EID is a 32-bit address used for socket-id identification in hosts. > It is also an interface ID since the host can be multi-homed and > attached to the subnets the IGP is routing within the site. An EID is > not injected into BGP routing towards the core. > > An RLOC is the PA IP address assigned to the CE/PE interface of the LISP > router that resides at the site. Can you comment on whether Noel and Sam are right to think that an EID address could also be used as an RLOC address, which I think is at odds with the definitions in draft-farinacci-lisp: http://www.ietf.org/mail-archive/web/lisp/current/msg00332.html NC So if it's _possible_ to use the same bit pattern as both an EID and an RLOC, my guess is people will do it, no matter what the documents say. And my take is that, because of _other_ concerns * (e.g. limiting routing overhead), it will be technically * possible, which means people probably will do it no matter what we say in any documents. http://www.ietf.org/mail-archive/web/lisp/current/msg00336.html SH I think there has been enough discussion on-list and other private comments that the rough consensus of the participants so far is that there will be cases where the same IP stands both as an EID and a RLOC. http://www.ietf.org/mail-archive/web/lisp/current/msg00365.html SH What do you mean that no EID is also an RLOC? It's not clear to me that in interworking cases this is always true. - Robin From rw@firstpr.com.au Wed Mar 25 20:13:01 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4033A6809 for ; Wed, 25 Mar 2009 20:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOnLm+-IsmXr for ; Wed, 25 Mar 2009 20:13:00 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id ED5E83A6DB3 for ; Wed, 25 Mar 2009 20:12:54 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id E5008175A41; Thu, 26 Mar 2009 14:13:46 +1100 (EST) Message-ID: <49CAF2EB.5050209@firstpr.com.au> Date: Thu, 26 Mar 2009 14:13:47 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org References: <2ABFC26A-854D-416F-BB8B-2BFE60DCB812@linquest.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Charter for discussion at today's meeting X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 03:13:01 -0000 Short version: I think there are some good aspects to Dow's new text for para 3, but I still prefer my suggested text, which is shorter. Links: Draft 00 (my numbering scheme) from Jari: http://www.ietf.org/mail-archive/web/lisp/current/msg00262.html March 13 My suggested changes to 00: http://www.ietf.org/mail-archive/web/lisp/current/msg00286.html March 19 Sam's versions 01 and 02: http://www.ietf.org/mail-archive/web/lisp/current/msg00314.html March 23 http://www.ietf.org/mail-archive/web/lisp/current/msg00342.html March 25 Dow's suggested changes to 02: http://www.ietf.org/mail-archive/web/lisp/current/msg00355.html March 25 Hi Dow, I think your new suggested text for the Charter is an attempt to mention in detail LISP's future potential for having separate namespaces for EIDs and RLOCs. As I have argued several times, most recently in a reply I just wrote to Dino (msg00369), according to my understanding of the accepted meaning of "namespace" http://www.firstpr.com.au/ip/ivip/namespace/#best as long as LISP is to be a practical method of solving the routing scaling problem, then both the EIDs and RLOC addresses for IPv4(6) need to be part of the global unicast address space of IPv4(6) and therefore must be separate subsets of this space. EIDs and RLOCs cannot have separate namespaces, since that would mean that a single numeric address could have two separate meanings depending on which namespace was applied when interpreting it. There is no way of doing this without upgrading either all the hosts and/or all the DFZ and other routers - which cannot be part of any practical solution to the routing scaling problem. I think your text is good in that it mentions that HIP always involves separate namespaces. However, I think your text is insufficiently clear about the restrictions that LISP must works under when it is deployed as a potentially practical solution to the routing scaling problem. The Charter is for a brief period of development on the path towards developing a fully fledged solution to the routing scaling problem. While I guess this period would not preclude LISP developing in a way which could, in the future, use separate namespaces, I don't think this needs to be mentioned at length in the Charter. I think some changes along the lines I proposed would be more concise, more helpful to the reader and more focused on the phase of LISP development which the Charter will apply to: http://www.ietf.org/mail-archive/web/lisp/current/msg00286.html Discussion: http://www.ietf.org/mail-archive/web/lisp/current/msg00298.html http://www.ietf.org/mail-archive/web/lisp/current/msg00309.html http://www.ietf.org/mail-archive/web/lisp/current/msg00335.html My rewrite of para 3 has 174 words and yours has 269. - Robin From rw@firstpr.com.au Wed Mar 25 21:02:31 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921733A6DC7 for ; Wed, 25 Mar 2009 21:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlA4QDA2L039 for ; Wed, 25 Mar 2009 21:02:30 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 438393A6DB3 for ; Wed, 25 Mar 2009 21:02:30 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 30AD2175A45; Thu, 26 Mar 2009 15:03:17 +1100 (EST) Message-ID: <49CAFE86.2020508@firstpr.com.au> Date: Thu, 26 Mar 2009 15:03:18 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] Ceasefire in the namespace & EID used as RLOC skirmish X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 04:02:31 -0000 Short version: No more LISP messages from me for a week. At: http://www.firstpr.com.au/ip/ivip/namespace/#20090319 are links to the 15 messages I have written to this list in the last week trying to get substantial responses to these concerns: 1 - Claims that LISP involves separate namespaces for EIDs and RLOCs are not true for any version of LISP which could be a practical solution to the routing scaling problem. 2 - Claims that an address could be used as both an EID and as an RLOC, in contradiction of this being ruled out by http://tools.ietf.org/html/draft-farinacci-lisp-12#page-8 "EIDs MUST NOT be used as LISP RLOCs." 3 - My attempt to improve the draft Charter in a number of respects: http://www.ietf.org/mail-archive/web/lisp/current/msg00286.html http://www.ietf.org/mail-archive/web/lisp/current/msg00298.html http://www.ietf.org/mail-archive/web/lisp/current/msg00309.html http://www.ietf.org/mail-archive/web/lisp/current/msg00335.html This also links to other people's messages in these threads. While Sam initially liked some of my suggested changes, he did not use any of them. His own replacement text gained criticism and no support, I think. (Links to the versions and suggestions are in: http://www.ietf.org/mail-archive/web/lisp/current/msg00370.html) While I may have prompted Dow into suggesting changes which deal more clearly with the question of namespaces, I have so far failed to prompt anyone who has made statements, written presentations etc. contrary to 1 and 2 above to argue their case, present a detailed practical example etc. in any substantial way. These three questions are clearly directly relevant to LISP development and to the final text in the Charter, since we need to distinguish LISP from other protocols, primarily HIP, which have a stronger claim to being a true "Locator Identifier Split" architecture, but which cannot be a practical solution to the routing scaling problem precisely *because* they involve the use of a new namespace for EIDs and/or RLOCs. No-one has argued why these questions are not important to LISP in general or to the wording of the Charter. Yet, so far, no-one has responded in a substantial manner. I will concentrate on paying work for a while and will maintain radio silence for a week. - Robin From dow.street@linquest.com Wed Mar 25 22:52:45 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890873A6DE7 for ; Wed, 25 Mar 2009 22:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8KfY9PDKQst for ; Wed, 25 Mar 2009 22:52:44 -0700 (PDT) Received: from smtp136.sat.emailsrvr.com (smtp136.sat.emailsrvr.com [66.216.121.136]) by core3.amsl.com (Postfix) with ESMTP id A5CB23A67D4 for ; Wed, 25 Mar 2009 22:52:44 -0700 (PDT) Received: from relay3.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay3.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 5FDDBC7B96; Thu, 26 Mar 2009 01:53:37 -0400 (EDT) Received: by relay3.relay.sat.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 0B736C764A; Thu, 26 Mar 2009 01:53:36 -0400 (EDT) Message-Id: From: Dow Street To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 22:53:35 -0700 References: <2ABFC26A-854D-416F-BB8B-2BFE60DCB812@linquest.com> X-Mailer: Apple Mail (2.930.3) Cc: lisp@ietf.org Subject: Re: [lisp] Charter for discussion at today's meeting X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 05:52:45 -0000 On Mar 25, 2009, at 4:27 PM, Sam Hartman wrote: > > > Hi. based on your wording, I'm interpreting your proposal as a set of > wording suggestions that you think may improve the charter, but not an > objection to the current text. > > I'd appreciate comments on your rewording. However I'll note that you > are rewording a fairly long-standing part of the charter and bringing > up a bunch of words and issues that have falied to gain consensus in > previous discussions. So, my guess is that we will not get consensus > behind this. Fair enough. My goal was simply to clarify the description and put this work in context, not necessarily change the scope or focus. However, if my proposed text raises terms/ideas for which there is not consensus, maybe that means we're still not entirely clear on the work about to be chartered. (I'm not sure if this is a problem or not with respect to moving ahead with a WG). If there are notable objections to my suggested revision, either due to content or process reasons (e.g., too big a change), I can suggest some smaller changes instead. I'm not even convinced (myself) that a charter should have as much "background" information as was in the text I drafted. I am just trying to get to a common understanding. My comment during the meeting about the identifier definition was basically coming from the following perspective: - there are lots of places in the architecture where you can introduce a point of indirection. - if we call such a point a "locator-identifier" split, that implies (to me) that the latter of the namespaces has properties well suited, or perhaps "tuned", for the identification role. In this regard, I think you could almost call the primary point of indirection in LISP more of a locator-locator split, or a global name - local name split. When viewed from the vantage point of the core, the second name in this pair does look a lot like a (site) identifier - it just doesn't look like an identifier from the edge site's perspective. Of course, if I understand things correctly, from the edge site's perspective the identifier name itself is something like a two-part name (locator +identifier), right? In any case, I took from the meeting comments (and some email comments) that the terminology ship has sailed on this. Maybe I'll just refer to it as the Locator Indirection for Scalability Protocol when I am talking to myself. R, Dow From dow.street@linquest.com Wed Mar 25 23:12:01 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF493A6A09 for ; Wed, 25 Mar 2009 23:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uycf-NDUeNRw for ; Wed, 25 Mar 2009 23:12:00 -0700 (PDT) Received: from smtp136.sat.emailsrvr.com (smtp136.sat.emailsrvr.com [66.216.121.136]) by core3.amsl.com (Postfix) with ESMTP id 71E823A698C for ; Wed, 25 Mar 2009 23:12:00 -0700 (PDT) Received: from relay3.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay3.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id DBCCCCC148; Thu, 26 Mar 2009 02:12:52 -0400 (EDT) Received: by relay3.relay.sat.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 85869CC140; Thu, 26 Mar 2009 02:12:52 -0400 (EDT) Message-Id: From: Dow Street To: Robin Whittle In-Reply-To: <49CAF2EB.5050209@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 23:12:51 -0700 References: <2ABFC26A-854D-416F-BB8B-2BFE60DCB812@linquest.com> <49CAF2EB.5050209@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) Cc: lisp@ietf.org Subject: Re: [lisp] Charter for discussion at today's meeting X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 06:12:01 -0000 Thanks for the comments, Robin. To be honest, I have been out of the gritty details of this for a while and am just now catching up. Please see my response to Sam's message regarding suggestions to the charter text. I was partly using a charter re-write as a (debatably poor) method for finding consensus on key points - and agree that in a real, final charter conciseness is a virtue. R, Dow On Mar 25, 2009, at 8:13 PM, Robin Whittle wrote: > Short version: I think there are some good aspects to Dow's new > text for para 3, but I still prefer my suggested > text, which is shorter. > > Links: > > Draft 00 (my numbering scheme) from Jari: > http://www.ietf.org/mail-archive/web/lisp/current/msg00262.html > March 13 > > My suggested changes to 00: > http://www.ietf.org/mail-archive/web/lisp/current/msg00286.html > March 19 > > Sam's versions 01 and 02: > http://www.ietf.org/mail-archive/web/lisp/current/msg00314.html > March 23 > http://www.ietf.org/mail-archive/web/lisp/current/msg00342.html > March 25 > > Dow's suggested changes to 02: > http://www.ietf.org/mail-archive/web/lisp/current/msg00355.html > March 25 > > > > Hi Dow, > > I think your new suggested text for the Charter is an attempt to > mention in detail LISP's future potential for having separate > namespaces for EIDs and RLOCs. > > As I have argued several times, most recently in a reply I just wrote > to Dino (msg00369), according to my understanding of the accepted > meaning of "namespace" > > http://www.firstpr.com.au/ip/ivip/namespace/#best > > as long as LISP is to be a practical method of solving the routing > scaling problem, then both the EIDs and RLOC addresses for IPv4(6) > need to be part of the global unicast address space of IPv4(6) and > therefore must be separate subsets of this space. EIDs and RLOCs > cannot have separate namespaces, since that would mean that a single > numeric address could have two separate meanings depending on which > namespace was applied when interpreting it. There is no way of doing > this without upgrading either all the hosts and/or all the DFZ and > other routers - which cannot be part of any practical solution to the > routing scaling problem. > > I think your text is good in that it mentions that HIP always involves > separate namespaces. However, I think your text is insufficiently > clear about the restrictions that LISP must works under when it is > deployed as a potentially practical solution to the routing scaling > problem. > > The Charter is for a brief period of development on the path towards > developing a fully fledged solution to the routing scaling problem. > > While I guess this period would not preclude LISP developing in a way > which could, in the future, use separate namespaces, I don't think > this needs to be mentioned at length in the Charter. > > I think some changes along the lines I proposed would be more concise, > more helpful to the reader and more focused on the phase of LISP > development which the Charter will apply to: > > http://www.ietf.org/mail-archive/web/lisp/current/msg00286.html > > Discussion: > > http://www.ietf.org/mail-archive/web/lisp/current/msg00298.html > http://www.ietf.org/mail-archive/web/lisp/current/msg00309.html > http://www.ietf.org/mail-archive/web/lisp/current/msg00335.html > > My rewrite of para 3 has 174 words and yours has 269. > > - Robin > From olivier.bonaventure@uclouvain.be Thu Mar 26 02:00:06 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2523A68A8 for ; Thu, 26 Mar 2009 02:00:06 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBMl9EFLetvu for ; Thu, 26 Mar 2009 02:00:05 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 2784A3A68A7 for ; Thu, 26 Mar 2009 02:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=PJY52Y+d55VyEV8BPdOV+QnggIs=; b=xvwR7g+W2s DAa46U37ZA67ctK0fzi711vAyo+p4y0y/K3msSyjQUcM2txEgj1Kog88QQWO2i+T hMa/7fgm/zcCIk8F+wbdZEhbjZWMzA7Rhd0t0J1IvbhSqtoD461vuSwZoUwxEZxp Oi/1YrP0EcOF34uXHJ3XQrJ1FD3BGvgeY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=jkrml 576P9Y06EkDyeWizGDHgSvoeGCXceg+TELCr7FTPPkXFAOkHdEPoG1KvJjFUiwBV VExRNMWYwxjmNXHScnAuBpGFbjZR3CzKRo+8LaijOW/q5Nn77EWOql9fsww33mPX yaZBgIkrIUb/vJWrY9t1nQKK2PlY80ngsDeiBw= Received: from mbpobo.local (ip-83-134-212-236.dsl.scarlet.be [83.134.212.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Thu, 26 Mar 2009 10:00:08 +0100 (CET) Message-ID: <49CB4412.9060503@uclouvain.be> Date: Thu, 26 Mar 2009 10:00:02 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Roque Gagliano References: <83B62425-E996-4A8C-9D7F-B78E363E3C3E@lacnic.net> <49C8F88C.9090404@uclouvain.be> <06A52779-0FF7-441C-9A85-5DF64BFADAD8@lacnic.net> In-Reply-To: <06A52779-0FF7-441C-9A85-5DF64BFADAD8@lacnic.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 96F161C9162.0A9C1 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Using Signed object to validate entries in Mapping Database: draft-lisp-rgaglian-ioa-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 26 Mar 2009 09:00:06 -0000 Roque, >> >> This is a possible approach. It would be interesting to discuss how the >> IOA would be discributed ? >> One option could be a central repository such as a RIR containing all >> the IOAs >> Another option could be to include the IOA in the mapping reply or the >> url of the IOA in the mapping reply. >> > > The way that RPKI works is by using a distributed repository where each > signed object (ie certificates, ioa, roas) mentions the location of its > repository. So, yes the RIR have a repository for the first two layers > of material (certificates to ISPs) but the ISP then can implement their > own CA and their own repository to host its signed objects (ie ioas). > > The protocol propossed to fetch all these object from various > repositories is rsync and normally a relying party has a local cache > with all the material that has download. There is a lap that by design > we took as 24hs from time I update my repository until every party has > the latest copy. I think that the rsync distribution method used by RPKI is valid for checking the BGP messages. As each ISP receives BGP advertisements for all prefixes, it needs to have all the certificates to validate the received BGP messages. For LISP, it is unclear to me whether this model is the most appropriate one. An ITR that sends mapping requests and wants to validate the mapping replies will usually not receive mapping replies from all over the world. In fact, small ITRs will only receive mapping replies from a small number of prefixes and only these replies need to be checked. For such small sites, it would be useful to have certificate repositories than can be checked online. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From olivier.bonaventure@uclouvain.be Thu Mar 26 02:58:40 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0CB3A69CE for ; Thu, 26 Mar 2009 02:58:40 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zp0gNDTGcIZ for ; Thu, 26 Mar 2009 02:58:39 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 587E23A6452 for ; Thu, 26 Mar 2009 02:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=mXPX+WGKWBwNClGTejgKgMEg7FQ=; b=dmL6WmBU7o g9SnLgfM08NRgGHXNIVFLZZP6MUenKlcFY8mA6kzbrYkHxOYX0FpJJVXthEYToCV 0Iw3KIIWGOFNXeG7sS0m/Ruv0Bs1Y2RFQIXbA1IYPJ3ESXuRU+2puMCcsqhla6s4 3xg8OZ0ZqwuKtuVdg98qldJTYUay94bEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=Sk8PD +9SlZGt2S3z0nfp83V91ZrdcOmzQIz1if67JKtcVPDONtnXZMyobDlqa/AEBlwYQ akkzYHdkPCIsUBk72TDqSjfJ1fsu97EZyRPv64WfmFTG5S9ouQ50VHyTuAWhlGAq O8PPJM6E6S4iJgzRwY2pwZt/76dpcVUW3tDHPU= Received: from mbpobo.local (ip-83-134-212-236.dsl.scarlet.be [83.134.212.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Thu, 26 Mar 2009 10:58:52 +0100 (CET) Message-ID: <49CB51D0.6090306@uclouvain.be> Date: Thu, 26 Mar 2009 10:58:40 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Noel Chiappa References: <20090325202840.9554B6BE555@mercury.lcs.mit.edu> In-Reply-To: <20090325202840.9554B6BE555@mercury.lcs.mit.edu> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 72D72F2140.EE331 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Using Signed object to validate entries in Mapping Database: draft-lisp-rgaglian-ioa-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 26 Mar 2009 09:58:40 -0000 Noel, > > From: Olivier Bonaventure > > > If we delay discussions about security problems, I guess that they will > > come back later and that we'll have lots of difficulty solving them. > > I agree we should make certain that LISP is _securable_, even if we don't > actually deploy that securitization at this point. However, I wonder if such > work would conflict with the limited WG charter? Although I suppose it could > always be peformed as a non-WG activity. I don't think that the securisation problem will be part of the (first) charter, but I hope that there will be technical discussions concerning this problem and that security will be included the next time the WG will revise its charter. > Another issue would be if there is some question about the performance > impact, one which could only really be answered to everyone's satisfaction > with actual emperical data (much as some people are concerned with mapping > lookup delays, caching mappings, etc); we might have to do some deployment > to fully answer that. We should encourage experimentation with different mapping systems to see the impact of securing these mappings. I hope that some researchers will be able to start from Luigi's implementation and perform useful experiments. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From olivier.bonaventure@uclouvain.be Thu Mar 26 07:48:42 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5020C3A6D82 for ; Thu, 26 Mar 2009 07:48:42 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiPdCXnN20qI for ; Thu, 26 Mar 2009 07:48:41 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 1E61B3A6884 for ; Thu, 26 Mar 2009 07:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:subject: content-type:content-transfer-encoding; q=dns/txt; s=selucl; bh= fYp26nnnBHRjj+UTpsNLnCrpY98=; b=g0A3P8wgxp2r82m3Lzhpu8pSsi6pn6s+ ZaLjFJ2/ThwCPlJWV0TNAo7xpLa/RzQ+myr4v0/CvDz9VevuvPXiQVEXiV9XSueW PfFbF1RhGkie2lUiBh+JVxY9ZwYxgeFBVQYdLC9qZUJTH0TnBiGQ+U7sKK/h9H76 xm8DhSGcNAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:subject:content-type: content-transfer-encoding; q=dns; s=selucl; b=BHxixdCHv1E7B7MF0T d66bd+qX8c2N7GDhYcu/r9iXO348n6Nqbgu9ZC47nQq4vMbd1aRJOBwjDEta0hAv XmmkGB3xCrl31SlBEz2fELBAKTX5UBRj+6tUOyT9Sf+FG6vzOvXZrr7O6ZzDCVNz wIPJkDSAfnI6rWXMugoD8InI0= Received: from mbpobo.local (ip-83-134-212-236.dsl.scarlet.be [83.134.212.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA for ; Thu, 26 Mar 2009 15:44:48 +0100 (CET) Message-ID: <49CB94D6.7050003@uclouvain.be> Date: Thu, 26 Mar 2009 15:44:38 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: lisp@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 5603FEBF65.588A7 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: [lisp] Comments on draft-fuller-lisp-ms X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 26 Mar 2009 14:48:42 -0000 Hello, I had a look at draft draft-fuller-lisp-ms-00. My first comment is that this is a very good addition to the set of LISP documents, this will allow the implementation of simpler xTRs and also allow people to experiment with mapping systems. I thus fully support this direction on work. However, I have some concerns about the details and the solution chosen in the draft. First, concerning the map register message defined in draft-farinacci-lisp-12 I completely agree that we need a method to authenticate the map register messages. Using AH with MD5 and a key shared between the ETR and the mapping server to authenticate the mapping register appears more like a quick hack than an implementation. Instead of using IPSec to authenticate the content of the map register, I would suggest that we consider adding authentication data inside the map register at least. The authentication data should be flexible and support different types of authentications. MD5 with a shared key could be a first example, but I think that we should also explore the possibility of using certificates that certify a binding between an EID prefix and a keypair and use this keypair to sign the mapping register. Second, the reliability of the transmission of the map register should be discussed. As map register messages are sent in normal IP packets, they may be dropped. One possibility could be that everytime an ETR sends a map-register to a mapping server, it should after a timeout send a map-request to this server to check that the map register sent has caused an update of the mapping server. Third, concerning the map-server processing, draft-fuller-lisp-ms explains that the map-server does not produce map replies, but only forwards the map-requests to the appropriate ETRs. This implies that the map-server does not need to store all the mapping information (i.e. rlocs, reachability, weight, priority, ...). In this case, then why does the ETR indicates all this information in the map register message ? Fourth, when an EID prefix is served by several ETRs, it seems useful to expect that the map-server will load balance the received request among the ETRs that it knows. Fifth, the ability of sending a negative map reply (with an empty locator set) is a useful addition. However, it may create risks of DoS attacks that would be useful to discuss in the security section. The verification of the contents of the map reply (source port, nonce) is very important. The draft suggest to send a negative map reply that contains the largest possible EID prefix. If an ITR accepts a negative reply containing 0.0.0.0/0, then it would consider that the entire IPv4 Internet is unreachable. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From hartmans@mit.edu Thu Mar 26 09:23:36 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515A628C0DE for ; Thu, 26 Mar 2009 09:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdX-4nEtC5Yg for ; Thu, 26 Mar 2009 09:23:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-46b4.meeting.ietf.org [130.129.70.180]) by core3.amsl.com (Postfix) with ESMTP id ACF323A698F for ; Thu, 26 Mar 2009 09:23:34 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 976C0414C; Thu, 26 Mar 2009 12:24:23 -0400 (EDT) To: Dow Street References: <2ABFC26A-854D-416F-BB8B-2BFE60DCB812@linquest.com> From: Sam Hartman Date: Thu, 26 Mar 2009 12:24:23 -0400 In-Reply-To: (Dow Street's message of "Wed\, 25 Mar 2009 22\:53\:35 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Charter for discussion at today's meeting X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:23:36 -0000 I do think your understanding is basically correct. And I think the current text is compatible with that understanding. And I think there is reasonably broad understanding among the core people who have worked on LISP about the points that are important to you. From dmm@1-4-5.net Thu Mar 26 09:25:33 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0903E28C0DE for ; Thu, 26 Mar 2009 09:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNKsEjAZ0Nmz for ; Thu, 26 Mar 2009 09:25:32 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 36DB128C0D6 for ; Thu, 26 Mar 2009 09:25:32 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n2QGQIDj012442; Thu, 26 Mar 2009 09:26:18 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n2QGQIqa012441; Thu, 26 Mar 2009 09:26:18 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 26 Mar 2009 09:26:18 -0700 From: David Meyer To: Dino Farinacci Message-ID: <20090326162618.GA12396@1-4-5.net> References: <49CA6153.40801@joelhalpern.com> <20090325172041.GA14881@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: lisp@ietf.org Subject: Re: [lisp] Interworking - NAT X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:25:33 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2009 at 06:30:43PM -0700, Dino Farinacci wrote: >>> n contrast, if folks could get 1-1 NAT for IPv4 now then that would =20 >>> be >>> a viable solution to a number of real world problems already. We as=20 >>> a >>> community are looking are recommending something similar as part of =20 >>> IPv6 >>> (NAT66). If that could be done for v4 in the current world, I am =20 >>> not at >>> all clear on why a site would bother with the rest of LISP. Given >>> typical site attitudes, that sort of NAT would seem sufficient for =20 >>> them. >> >> Perhaps, however, 1-1 NAT still carries a lot of >> operational burden for sites deploying the >> technology. Deploying PTR infrastructure eases this >> burden, and provides quite a bit of additional >> functionality. I think of it as a tool in the toolkit >> that can be useful in some cases. > > Also NAT cannot describe TE policy and has issues with asymmetric paths= =20 > in and out of a site. Yep, agreed. Dave --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknLrKoACgkQORgD1qCZ2KfEvgCcDHvBX+s8Wi2zsjNw5lsdRQxx Y3YAnjsAd/bjGUQKLP46gWclJUW7xybt =3rw0 -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From dino@cisco.com Thu Mar 26 22:18:16 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D923A67E6 for ; Thu, 26 Mar 2009 22:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WADy4nZVlP8S for ; Thu, 26 Mar 2009 22:18:15 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2767E3A67D9 for ; Thu, 26 Mar 2009 22:18:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,431,1233532800"; d="scan'208";a="147387223" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 27 Mar 2009 05:19:09 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2R5J9o2016779; Thu, 26 Mar 2009 22:19:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2R5J9Wu002404; Fri, 27 Mar 2009 05:19:09 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 22:19:09 -0700 Received: from dhcp-51cf.meeting.ietf.org ([10.21.95.4]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 22:19:08 -0700 Message-Id: <183D755D-BFD8-4057-B634-8F8B0D539D34@cisco.com> From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <49CB94D6.7050003@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 26 Mar 2009 22:19:08 -0700 References: <49CB94D6.7050003@uclouvain.be> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 27 Mar 2009 05:19:08.0743 (UTC) FILETIME=[8E4E4D70:01C9AE9B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4351; t=1238131149; x=1238995149; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Comments=20on=20draft-fuller-l isp-ms |Sender:=20; bh=+fb91e7GI0aAYZjMMTZApEyJmg/0dJp0BtjHppKudTw=; b=tfS1Tr2hzpcMrAMSnqrv0Nyof8BeShPIIwslExo8P4CX8jTAsR2G3Fzd1D S3t6cv9Nz9V6wRj9vwgv3gWbg5tiXcoJWZmag+qciogpaX9NMZKHMuNq/dxZ Lgq58Q4tnzS1ix4buc+fVe4fhv03nVNuYb4YCIk1RUwA4w6LzbULw=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Comments on draft-fuller-lisp-ms X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 05:18:16 -0000 > Hello, > > I had a look at draft draft-fuller-lisp-ms-00. > > My first comment is that this is a very good addition to the set of > LISP > documents, this will allow the implementation of simpler xTRs and also > allow people to experiment with mapping systems. I thus fully support > this direction on work. Thanks Olivier. > However, I have some concerns about the details and the solution > chosen > in the draft. > > First, concerning the map register message defined in > draft-farinacci-lisp-12 I completely agree that we need a method to > authenticate the map register messages. Using AH with MD5 and a key > shared between the ETR and the mapping server to authenticate the > mapping register appears more like a quick hack than an > implementation. It is simple and IPsec is suppose to be used for packet authentication. > Instead of using IPSec to authenticate the content of the map > register, > I would suggest that we consider adding authentication data inside the > map register at least. The authentication data should be flexible and > support different types of authentications. MD5 with a shared key > could > be a first example, but I think that we should also explore the > possibility of using certificates that certify a binding between an > EID > prefix and a keypair and use this keypair to sign the mapping > register. Since each side (the ETR side and the map-server side) needs explicit configuration, which aids in the security of both allowing the EID- prefix into the mapping system as well as authenticating the binding, you can also configure the HMAC used. In fact, it's just another element of a multi-tuple passphrase that can be used. > Second, the reliability of the transmission of the map register should > be discussed. As map register messages are sent in normal IP packets, > they may be dropped. One possibility could be that everytime an ETR > sends a map-register to a mapping server, it should after a timeout > send > a map-request to this server to check that the map register sent has > caused an update of the mapping server. Yes, we are considering this. > Third, concerning the map-server processing, draft-fuller-lisp-ms > explains that the map-server does not produce map replies, but only > forwards the map-requests to the appropriate ETRs. This implies that > the > map-server does not need to store all the mapping information (i.e. > rlocs, reachability, weight, priority, ...). In this case, then why > does > the ETR indicates all this information in the map register message ? Just so the implementation can remain simple and reuse code. Plus, if later we want the full mappings to be stored in the map-server, we already have the packet format supporting it. > Fourth, when an EID prefix is served by several ETRs, it seems > useful to > expect that the map-server will load balance the received request > among > the ETRs that it knows. Yes, we are planning on doing this. Plus we want each ETR at the site to register to more than one map-server for redundancy. > Fifth, the ability of sending a negative map reply (with an empty > locator set) is a useful addition. However, it may create risks of DoS It may be useful but we are proceeding with caution. There are many complications that may arise from it so it may be more cost than benefit. > attacks that would be useful to discuss in the security section. The > verification of the contents of the map reply (source port, nonce) is > very important. The draft suggest to send a negative map reply that > contains the largest possible EID prefix. If an ITR accepts a negative The largest possible prefix which would cover a non-EID-prefix. The point is to put the prefix in the map-cache, so when a packet matches it, that we can natively-forward the packet (to a non-LISP site). > reply containing 0.0.0.0/0, then it would consider that the entire > IPv4 > Internet is unreachable. No, it would consider the entire Internet as non-LISP capable. Dino > > > > Olivier > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Sun Mar 29 20:29:24 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA203A6CE7; Sun, 29 Mar 2009 20:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rATU2R7owAm; Sun, 29 Mar 2009 20:29:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (m463536d0.tmodns.net [208.54.53.70]) by core3.amsl.com (Postfix) with ESMTP id 6E56D3A6CD3; Sun, 29 Mar 2009 20:29:15 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6FB274182; Sun, 29 Mar 2009 23:29:56 -0400 (EDT) To: ietf@ietf.org,iesg@ietf.org From: Sam Hartman Date: Sun, 29 Mar 2009 23:29:56 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: [lisp] LISP: update to charter in external review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 03:29:24 -0000 I'd like to present the following revised charter to the community (and with Jari's approval) to the IESG for review. This charter represents discussion on the LISP list and in the LISP session at IETF 74. The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation". The basic idea behind the separation that the Internet architecture combines two functions, Routing Locators, (where you are attached to the network) and Identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the Internet address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of other approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the EID-to-RLOC mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications) as well as the manageability and operability of LISP. Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG as Experimental Mar 2010 Submit base ALT specification to the IESG as Experimental Mar 2010 Submit the LISP Interworking specification to the IESG as Experimental June 2010 Submit the LISP Map Server specification to the IESG as Experimental June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 Submit a preliminary analysis as Informational Dec 2010 Re-charter or close. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From dow.street@linquest.com Sun Mar 29 21:29:59 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48663A6A95; Sun, 29 Mar 2009 21:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JsoRlxdh1nW; Sun, 29 Mar 2009 21:29:58 -0700 (PDT) Received: from smtp156.sat.emailsrvr.com (smtp156.sat.emailsrvr.com [66.216.121.156]) by core3.amsl.com (Postfix) with ESMTP id 934C13A6BCE; Sun, 29 Mar 2009 21:29:58 -0700 (PDT) Received: from relay15.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id BE00F1C3DA9; Mon, 30 Mar 2009 00:30:55 -0400 (EDT) Received: by relay15.relay.sat.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 2F8E71C3D5F; Mon, 30 Mar 2009 00:30:55 -0400 (EDT) Message-Id: <969E87F8-3ED2-4550-BA18-240071FBC600@linquest.com> From: Dow Street To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 29 Mar 2009 21:30:54 -0700 References: X-Mailer: Apple Mail (2.930.3) Cc: lisp@ietf.org, ietf@ietf.org, iesg@ietf.org Subject: Re: [lisp] LISP: update to charter in external review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 04:29:59 -0000 On Mar 29, 2009, at 8:29 PM, Sam Hartman wrote: > I'd like to present the following revised charter to the community > (and with Jari's approval) to the IESG for review. This charter > represents discussion on the LISP list and in the LISP session at IETF > 74. > > > > > The IAB's October 2006 workshop on Routing and Addressing Workshop > (RFC > 4984) rekindled interest in scalable routing and addressing > architectures > for the Internet. Among the many issues driving this renewed > interest are > concerns about the scalability of the routing system and the impending > exhaustion of the IPv4 address space. Since the IAB workshop, several > proposals have emerged which attempt to address the concerns expressed > there and elsewhere. In general, these proposals are based on the > "Locator/Identifier separation". > > The basic idea behind the separation that the Internet architecture > combines two functions, Routing Locators, (where you are attached to > the network) and Identifiers (who you are) in one number > space: The IP address. I don't think the preceding lines form a sentence. Is there an "is" missing? Alternatively, here is possible substitute: Locator/Identifier separation approaches are rooted in the premise that the current Internet architecture often uses a single IP address (i.e. name) for two distinctly different roles: Routing Locators (which describe "where" you are attached to the network) and Identifiers (which describe "who" you are) > Proponents of the separation architecture > postulate that splitting these functions apart will yield several > advantages, including improved scalability for the routing system. > The separation aims to decouple locators and identifiers, thus > allowing > for efficient aggregation of the routing locator space and providing > persistent identifiers in the identifier space. > > LISP supports the separation of the Internet address space following a > network-based map-and-encapsulate scheme (RFC 1955). In LISP, both > identifiers and locators are IP addresses. In LISP, identifiers are > composed of two parts: a "global" portion that uniquely identifies a > particular site and a "local" portion that identifies an interface > within a site. The "local" portion may be subdivided to identify a > particular network within the site. For a given identifier, LISP maps > the "global" portion of the identifier into a set of locators that can > be used by de-capsulation devices to reach the identified interface; > as a consequence a host would > typically change identifiers when it moves from one site to another or > whenever it moves from one subnet to another within an > site. Typically, the same IP address will not be used as an identifier > and locator in LISP. > > LISP requires no changes to end-systems or to most routers. LISP aims > for an incrementally deployable protocol. > > A number of other approaches are being looked at in parallel in > the IRTF and IETF. At this time, these proposals are at an early > stage. > All proposals (including LISP) have potentially harmful side-effects > to > Internet traffic carried by the involved routers, have parts where > deployment incentives may be lacking, and are NOT RECOMMENDED for > deployment beyond experimental situations at this stage. Many of the > proposals have components (such as the EID-to-RLOC mapping system) > where > it is not yet known what kind of design alternative is the best one > among > many. > > However, despite these issues it would be valuable to write > concrete protocol specifications and develop implementations that > can be > used to understand the characteristics of these designs. The LISP WG > is > chartered to work on the LISP base protocol (draft-farinacci- > lisp-12.txt), > the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP > Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server > (draft-fuller-lisp-ms-00.txt), and LISP multicast > (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the > given > drafts as a starting point. > The working group will encourage and support > interoperable LISP implementations as well as defining requirements > for > alternate mapping systems. The Working Group will also develop > security > profiles for the ALT and/or other mapping systems. > > It is expected that the results of specifying, implementing, and > testing LISP will be fed to the general efforts at the IETF and IRTF > (e.g., the Routing Research Group) that attempts to understand which > type of a solution is optimal. The LISP WG is NOT chartered to develop > the final or standard solution for solving the routing scalability > problem. Its specifications are Experimental and labeled with accurate > disclaimers about their limitations and not fully understood > implications for Internet traffic. In addition, as these issues are > understood, the working group will analyze and document the > implications of LISP on Internet traffic, applications, routers, and > security. This analysis will explain what role LISP can play in > scalable routing. The analysis should also look at scalability and > levels of state required for encapsulation, decapsulation, liveness, > and so on (draft-meyer-loc-id-implications) as well as the > manageability and operability of LISP. > > Goals and Milestones: > > Mar 2010 Submit base LISP specification to the IESG as Experimental > > Mar 2010 Submit base ALT specification to the IESG as Experimental > > Mar 2010 Submit the LISP Interworking specification to the IESG as > Experimental > > June 2010 Submit the LISP Map Server specification to the IESG as > Experimental > > June 2010 Submit Recommendations for Securing the LISP Mapping > System to > the IESG as Experimental > > Jul 2010 Submit LISP for Multicast Environments to the IESG as > Experimental > > Dec 2010 Submit a preliminary analysis as Informational > > Dec 2010 Re-charter or close. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@uclouvain.be Sun Mar 29 23:33:51 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90603A6B9B for ; Sun, 29 Mar 2009 23:33:51 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxucLCs-a20P for ; Sun, 29 Mar 2009 23:33:51 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id D14523A68FD for ; Sun, 29 Mar 2009 23:33:50 -0700 (PDT) Received: from [130.104.228.30] (mimir2.dhcp.info.ucl.ac.be [130.104.228.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Mon, 30 Mar 2009 08:34:42 +0200 (CEST) Message-ID: <49D067FF.4050002@uclouvain.be> Date: Mon, 30 Mar 2009 08:34:39 +0200 From: Damien Saucez User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 0872E1C8F67.0E684 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] LISP: update to charter in external review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 06:33:51 -0000 Sam Hartman wrote: [snip] > Goals and Milestones: > > Mar 2010 Submit base LISP specification to the IESG as Experimental > > Mar 2010 Submit base ALT specification to the IESG as Experimental > > Would it be better to write "Submit mapping system(s) specification to the IESG as Experimental"? I think it would be interesting to propose ALT and an alternative to ALT. > Mar 2010 Submit the LISP Interworking specification to the IESG as > Experimental > > June 2010 Submit the LISP Map Server specification to the IESG as > Experimental > > June 2010 Submit Recommendations for Securing the LISP Mapping System to > the IESG as Experimental > > Can we really propose the LISP specification in March and wait June for the security? What if we need to modify some messages to support the security? Damien Saucez > Jul 2010 Submit LISP for Multicast Environments to the IESG as > Experimental > > Dec 2010 Submit a preliminary analysis as Informational > > Dec 2010 Re-charter or close. > [snip] From Fred.L.Templin@boeing.com Mon Mar 30 08:32:19 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9303A6AC0 for ; Mon, 30 Mar 2009 08:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8g0as-53wBr for ; Mon, 30 Mar 2009 08:32:14 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id EA0C33A6ABA for ; Mon, 30 Mar 2009 08:32:13 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2UFX6eF026350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Mar 2009 10:33:06 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2UFX5nV004751 for ; Mon, 30 Mar 2009 08:33:06 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2UFX2dM004642 for ; Mon, 30 Mar 2009 08:33:05 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 08:33:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Mar 2009 08:33:05 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105BE9BC4@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <49D067FF.4050002@uclouvain.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LISP MTU Handling Thread-Index: AcmxAaFtbEFNkSUyQI2UFsxN6e+1bwAR4Flg References: <49D067FF.4050002@uclouvain.be> From: "Templin, Fred L" To: X-OriginalArrivalTime: 30 Mar 2009 15:33:05.0281 (UTC) FILETIME=[D1D52F10:01C9B14C] Subject: [lisp] LISP MTU Handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 15:32:19 -0000 Folks, The subject of MTU handling in LISP has come up a number of times. Below is a proposed rewrite of Section 5.4 which I believe addresses the issues. Any comments? Fred fred.l.templin@boeing.com 5.4. LISP Tunnel MTU Determination 5.4.1 ITR Specification The inner IP layer presents packets of various sizes to the ITR for LISP encapsulation. These packets may be either fragmentable (i.e., an IPv4 packet with the Don't Fragment (DF) bit set to 0) or unfragmentable (i.e., an IPv6 packet, or an IPv4 packet with DF=3D1). For each packet, the inner IP layer must determine whether to 1) admit the packet into the tunnel, 2) fragment the packet, then admit each fragment into the tunnel, or 3) drop the packet and return an ICMP "Packet Too Big (PTB)" message to the original source. The tunnel interface maintains a static MTU (S_MTU) of 1500 bytes minus the size of the encapsulating LISP/UDP/IP headers. The tunnel MAY additionally maintain per-ETR MTUs (ETR_MTU) using dynamic MTU determination [RFC1191][RFC1981]. When the inner IP layer presents an unfragmentable packet to the tunnel, it admits the packet if it is no larger than MAX(S_MTU, ETR_MTU); otherwise, it drops the packet and returns an ICMP PTB message to the original source. When the inner IP layer presents a fragmentable packet to the tunnel, it first uses IP fragmentation if necessary to break the packet into fragments that are no larger than S_MTU, then admits each fragment into the tunnel. After a packet (or fragment) has been admitted into the tunnel, the ITR encapsulates it in the requisite LISP/UDP/IP headers and sets DF=3D0 in the outer IP header (when IPv4 is used as the outer IP protocol). The ITR then forwards the encapsulated packet to ETR. After sending packets, the ITR may receive LISP-encapsulated ICMP PTB messages from an ETR. The ITR verifies that the message corresponds to a packet it sent earlier by examining the LISP nonce, source and destination addresses, etc. in the packet-in- error. The ITR then sets ETR_MTU to the maximum of the MTU value encoded in the ICMP PTB message and S_MTU. It then transcribes the message into a corresponding PTB message to send back to the original source.=20 When IPv6 is used as the outer protocol, the ITR may also receive ICMP PTB messages from a router on the path the the ETR. The ITR verifies that the PTB corresponds to an actual data packet as above, and returns a transcribed ICMP PTB back to the original source. 5.4.2 ETR Specification =20 When the ETR receives an IP packet, it first checks whether it was fragmented in the network by examining the MF bit and Offset fields in the outer IP header. If the packet is the first-fragment (i.e., with MF=3D=3D1 and Offset=3D=3D0) of a LISP data packet addressed to one of the router's RLOC addresses, the ETR prepares a LISP- encapsulated ICMP PTB message to send back to the ITR (subject to rate limiting). The ETR copies the leading portion of the first-fragment into the packet-in-error field of the ICMP PTB message up to a total message size of 576 bytes minus the size of the encapsulating LISP/UDP/IP headers. The ETR then encapsulates the message in outer LISP/UDP/IP headers and sends it back to the ITR. Following the first-fragment processing described above, the ETR discards all IP fragments addressed to one of the its RLOC addresses. 5.4.3 MTU Probing The ITR may periodically probe the path MTU to the ETR by generating a dummy LISP packet wit MF=3D=3D1 and Offset=3D=3D0 in the outer IP header. (When IPv4 is used as the outer protocol, it also sets DF=3D0.) If the ETR receives the probe, it will discard it and return a LISP-encapsulated ICMP PTB message. From Dimitri.Papadimitriou@alcatel-lucent.be Mon Mar 30 10:32:32 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C877028C110; Mon, 30 Mar 2009 10:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ocs7q9i3dfa3; Mon, 30 Mar 2009 10:32:31 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 251C13A6B03; Mon, 30 Mar 2009 10:32:30 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2UHXRpi022144; Mon, 30 Mar 2009 19:33:27 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 19:33:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Mar 2009 19:33:24 +0200 Message-ID: <00275A5B436CA441900CB10936742A3801FD3652@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <969E87F8-3ED2-4550-BA18-240071FBC600@linquest.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP: update to charter in external review Thread-Index: Acmw8FWcH2YLbFm9SDe6p2nI+8RyogAIvVNQ References: <969E87F8-3ED2-4550-BA18-240071FBC600@linquest.com> From: "PAPADIMITRIOU Dimitri" To: "Dow Street" , "Sam Hartman" X-OriginalArrivalTime: 30 Mar 2009 17:33:27.0801 (UTC) FILETIME=[A2CA4690:01C9B15D] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: iesg@ietf.org, lisp@ietf.org, ietf@ietf.org Subject: Re: [lisp] LISP: update to charter in external review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 17:32:32 -0000 =20 > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 > Behalf Of Dow Street > Sent: Monday, March 30, 2009 6:31 AM > To: Sam Hartman > Cc: lisp@ietf.org; ietf@ietf.org; iesg@ietf.org > Subject: Re: [lisp] LISP: update to charter in external review >=20 >=20 > On Mar 29, 2009, at 8:29 PM, Sam Hartman wrote: >=20 > > I'd like to present the following revised charter to the community > > (and with Jari's approval) to the IESG for review. This charter > > represents discussion on the LISP list and in the LISP=20 > session at IETF > > 74. > > > > > > > > > > The IAB's October 2006 workshop on Routing and Addressing Workshop =20 > > (RFC > > 4984) rekindled interest in scalable routing and addressing =20 > > architectures > > for the Internet. Among the many issues driving this renewed =20 > > interest are > > concerns about the scalability of the routing system and=20 > the impending > > exhaustion of the IPv4 address space. Since the IAB=20 > workshop, several > > proposals have emerged which attempt to address the=20 > concerns expressed > > there and elsewhere. In general, these proposals are based on the > > "Locator/Identifier separation". > > > > The basic idea behind the separation that the Internet architecture > > combines two functions, Routing Locators, (where you are=20 > attached to > > the network) and Identifiers (who you are) in one number > > space: The IP address. >=20 > I don't think the preceding lines form a sentence. Is there an "is" =20 > missing? Alternatively, here is possible substitute: >=20 > Locator/Identifier separation approaches are rooted in the premise =20 > that the current Internet architecture often uses a single IP=20 > address =20 > (i.e. name) for two distinctly different roles: Routing Locators =20 > (which describe "where" you are attached to the network) and =20 > Identifiers (which describe "who" you are) in order to prevent confusion between a name and an address, it would be preferable to state: Locator/Identifier separation approaches are rooted in the premise that the current Internet architecture designates by a single number space, i.e., the IP address, two distinctly different roles: Routing Locators (which describe "where" you are attached to the network) and Identifiers (which describe "who" you are). Thanks, -dimitri. > > Proponents of the separation architecture > > postulate that splitting these functions apart will yield several > > advantages, including improved scalability for the routing system. > > The separation aims to decouple locators and identifiers, thus =20 > > allowing > > for efficient aggregation of the routing locator space and providing > > persistent identifiers in the identifier space. > > > > LISP supports the separation of the Internet address space=20 > following a > > network-based map-and-encapsulate scheme (RFC 1955). In LISP, both > > identifiers and locators are IP addresses. In LISP, identifiers are > > composed of two parts: a "global" portion that uniquely identifies a > > particular site and a "local" portion that identifies an interface > > within a site. The "local" portion may be subdivided to identify a > > particular network within the site. For a given=20 > identifier, LISP maps > > the "global" portion of the identifier into a set of=20 > locators that can > > be used by de-capsulation devices to reach the identified=20 > interface; =20 > > as a consequence a host would > > typically change identifiers when it moves from one site to=20 > another or > > whenever it moves from one subnet to another within an > > site. Typically, the same IP address will not be used as an=20 > identifier > > and locator in LISP. > > > > LISP requires no changes to end-systems or to most routers.=20 > LISP aims > > for an incrementally deployable protocol. > > > > A number of other approaches are being looked at in parallel in > > the IRTF and IETF. At this time, these proposals are at an early =20 > > stage. > > All proposals (including LISP) have potentially harmful=20 > side-effects =20 > > to > > Internet traffic carried by the involved routers, have parts where > > deployment incentives may be lacking, and are NOT RECOMMENDED for > > deployment beyond experimental situations at this stage. Many of the > > proposals have components (such as the EID-to-RLOC mapping system) =20 > > where > > it is not yet known what kind of design alternative is the=20 > best one =20 > > among > > many. > > > > However, despite these issues it would be valuable to write > > concrete protocol specifications and develop implementations that =20 > > can be > > used to understand the characteristics of these designs.=20 > The LISP WG =20 > > is > > chartered to work on the LISP base protocol (draft-farinacci-=20 > > lisp-12.txt), > > the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP > > Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server > > (draft-fuller-lisp-ms-00.txt), and LISP multicast > > (draft-farinacci-lisp-multicast-01.txt) for these purposes,=20 > with the =20 > > given > > drafts as a starting point. > > The working group will encourage and support > > interoperable LISP implementations as well as defining=20 > requirements =20 > > for > > alternate mapping systems. The Working Group will also develop =20 > > security > > profiles for the ALT and/or other mapping systems. > > > > It is expected that the results of specifying, implementing, and > > testing LISP will be fed to the general efforts at the IETF and IRTF > > (e.g., the Routing Research Group) that attempts to understand which > > type of a solution is optimal. The LISP WG is NOT chartered=20 > to develop > > the final or standard solution for solving the routing scalability > > problem. Its specifications are Experimental and labeled=20 > with accurate > > disclaimers about their limitations and not fully understood > > implications for Internet traffic. In addition, as these issues are > > understood, the working group will analyze and document the > > implications of LISP on Internet traffic, applications, routers, and > > security. This analysis will explain what role LISP can play in > > scalable routing. The analysis should also look at scalability and > > levels of state required for encapsulation, decapsulation, liveness, > > and so on (draft-meyer-loc-id-implications) as well as the > > manageability and operability of LISP. > > > > Goals and Milestones: > > > > Mar 2010 Submit base LISP specification to the IESG as Experimental > > > > Mar 2010 Submit base ALT specification to the IESG as Experimental > > > > Mar 2010 Submit the LISP Interworking specification to the IESG as > > Experimental > > > > June 2010 Submit the LISP Map Server specification to the IESG as > > Experimental > > > > June 2010 Submit Recommendations for Securing the LISP Mapping =20 > > System to > > the IESG as Experimental > > > > Jul 2010 Submit LISP for Multicast Environments to the IESG as > > Experimental > > > > Dec 2010 Submit a preliminary analysis as Informational > > > > Dec 2010 Re-charter or close. > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 From menth@informatik.uni-wuerzburg.de Mon Mar 30 15:23:26 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6C23A691C; Mon, 30 Mar 2009 15:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2JWre4lv6bJ; Mon, 30 Mar 2009 15:23:25 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id B64BC3A67B1; Mon, 30 Mar 2009 15:23:24 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3703CA0734; Tue, 31 Mar 2009 00:24:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 2A46BA0731; Tue, 31 Mar 2009 00:24:22 +0200 (CEST) Received: from [78.50.245.4] (f050245004.adsl.alicedsl.de [78.50.245.4]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id B833DA0707; Tue, 31 Mar 2009 00:24:21 +0200 (CEST) Message-ID: <49D14697.5070306@informatik.uni-wuerzburg.de> Date: Tue, 31 Mar 2009 00:24:23 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: lisp@ietf.org, ietf@ietf.org, iesg@ietf.org Subject: Re: [lisp] LISP: update to charter in external review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de 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, 30 Mar 2009 22:23:26 -0000 Hi Sam, Sam Hartman schrieb: > I'd like to present the following revised charter to the community > (and with Jari's approval) to the IESG for review. This charter > represents discussion on the LISP list and in the LISP session at IETF > 74. > > > > > The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC > 4984) rekindled interest in scalable routing and addressing architectures > for the Internet. Among the many issues driving this renewed interest are > concerns about the scalability of the routing system and the impending > exhaustion of the IPv4 address space. Since the IAB workshop, several > proposals have emerged which attempt to address the concerns expressed > there and elsewhere. In general, these proposals are based on the > "Locator/Identifier separation". > > The basic idea behind the separation that the Internet architecture > combines two functions, Routing Locators, (where you are attached to > the network) and Identifiers (who you are) in one number > space: The IP address. The sentence "who you are" is rather confusing to me although its intention is certainly to be a simple and catchy explanation. However, "you" - the user (?) is probably not an edge interface designator. "who you are" suggests that the identifier has something to do with the identity of some device or its owner (whoever "you" is) that would stay the same when moving around which is clearly not the case in this context. Wouldn't it be clearer to say: core Routing Locators (which describe "where" an edge network is attached to the Internet core) and edge interface designators (which describe to "which" interface a device is attached within an edge network)? I find this easier to understand and according to my understanding this is 100% in line with the third paragraph of the charter. What's LISP's intended functionality beyond a protocol to separate core routing locators (RLocs) and edge interface designators (EIDs)? At least, this way all acronyms can be saved without keeping the ambiguous and misleading word identifier. Or is that too narrow minded and am I missing potential future extensions of LISP that are not documented in the charter? Well, it's probably too late for changes anyway. Just my 2 cents, Michael > Proponents of the separation architecture > postulate that splitting these functions apart will yield several > advantages, including improved scalability for the routing system. > The separation aims to decouple locators and identifiers, thus allowing > for efficient aggregation of the routing locator space and providing > persistent identifiers in the identifier space. > > LISP supports the separation of the Internet address space following a > network-based map-and-encapsulate scheme (RFC 1955). In LISP, both > identifiers and locators are IP addresses. In LISP, identifiers are > composed of two parts: a "global" portion that uniquely identifies a > particular site and a "local" portion that identifies an interface > within a site. The "local" portion may be subdivided to identify a > particular network within the site. For a given identifier, LISP maps > the "global" portion of the identifier into a set of locators that can > be used by de-capsulation devices to reach the identified interface; as a consequence a host would > typically change identifiers when it moves from one site to another or > whenever it moves from one subnet to another within an > site. Typically, the same IP address will not be used as an identifier > and locator in LISP. > > LISP requires no changes to end-systems or to most routers. LISP aims > for an incrementally deployable protocol. > > A number of other approaches are being looked at in parallel in > the IRTF and IETF. At this time, these proposals are at an early stage. > All proposals (including LISP) have potentially harmful side-effects to > Internet traffic carried by the involved routers, have parts where > deployment incentives may be lacking, and are NOT RECOMMENDED for > deployment beyond experimental situations at this stage. Many of the > proposals have components (such as the EID-to-RLOC mapping system) where > it is not yet known what kind of design alternative is the best one among > many. > > However, despite these issues it would be valuable to write > concrete protocol specifications and develop implementations that can be > used to understand the characteristics of these designs. The LISP WG is > chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), > the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP > Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server > (draft-fuller-lisp-ms-00.txt), and LISP multicast > (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given > drafts as a starting point. > The working group will encourage and support > interoperable LISP implementations as well as defining requirements for > alternate mapping systems. The Working Group will also develop security > profiles for the ALT and/or other mapping systems. > > It is expected that the results of specifying, implementing, and > testing LISP will be fed to the general efforts at the IETF and IRTF > (e.g., the Routing Research Group) that attempts to understand which > type of a solution is optimal. The LISP WG is NOT chartered to develop > the final or standard solution for solving the routing scalability > problem. Its specifications are Experimental and labeled with accurate > disclaimers about their limitations and not fully understood > implications for Internet traffic. In addition, as these issues are > understood, the working group will analyze and document the > implications of LISP on Internet traffic, applications, routers, and > security. This analysis will explain what role LISP can play in > scalable routing. The analysis should also look at scalability and > levels of state required for encapsulation, decapsulation, liveness, > and so on (draft-meyer-loc-id-implications) as well as the > manageability and operability of LISP. > > Goals and Milestones: > > Mar 2010 Submit base LISP specification to the IESG as Experimental > > Mar 2010 Submit base ALT specification to the IESG as Experimental > > Mar 2010 Submit the LISP Interworking specification to the IESG as > Experimental > > June 2010 Submit the LISP Map Server specification to the IESG as > Experimental > > June 2010 Submit Recommendations for Securing the LISP Mapping System to > the IESG as Experimental > > Jul 2010 Submit LISP for Multicast Environments to the IESG as > Experimental > > Dec 2010 Submit a preliminary analysis as Informational > > Dec 2010 Re-charter or close. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From hartmans@mit.edu Mon Mar 30 19:40:02 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09C53A6C41 for ; Mon, 30 Mar 2009 19:40:02 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKSzZIRb1n8F for ; Mon, 30 Mar 2009 19:40:02 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id BCA873A6930 for ; Mon, 30 Mar 2009 19:40:01 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA02.westchester.pa.mail.comcast.net with comcast id ZRRm1b0051GhbT852egyyn; Tue, 31 Mar 2009 02:40:58 +0000 Received: from carter-zimmerman.suchdamage.org ([74.92.229.90]) by OMTA07.westchester.pa.mail.comcast.net with comcast id Zegx1b00A1xg5mq3Teh0sR; Tue, 31 Mar 2009 02:41:01 +0000 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8ECCC4182; Mon, 30 Mar 2009 22:40:55 -0400 (EDT) To: menth@informatik.uni-wuerzburg.de References: <49D14697.5070306@informatik.uni-wuerzburg.de> From: Sam Hartman Date: Mon, 30 Mar 2009 22:40:55 -0400 In-Reply-To: <49D14697.5070306@informatik.uni-wuerzburg.de> (Michael Menth's message of "Tue\, 31 Mar 2009 00\:24\:23 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org, ietf@ietf.org, iesg@ietf.org Subject: Re: [lisp] LISP: update to charter in external review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 02:40:02 -0000 >>>>> "Michael" == Michael Menth writes: Michael> The sentence "who you are" is rather confusing to me Michael> although its intention is certainly to be a simple and Michael> catchy explanation. However, "you" - the user (?) is Michael> probably not an edge interface designator. "who you are" Michael> suggests that the identifier has something to do with the Michael> identity of some device or its owner (whoever "you" is) Michael> that would stay the same when moving around which is Michael> clearly not the case in this context. Michael> Wouldn't it be clearer to say: core Routing Locators Michael> (which describe "where" an edge network is attached to Michael> the Internet core) and edge interface designators (which Michael> describe to "which" interface a device is attached within Michael> an edge network)? I find this easier to understand and Michael> according to my understanding this is 100% in line with Michael> the third paragraph of the charter. the second paragraph is intended to be far more general than LISP and carefully avoids using any LISP terms. I think it is accurate, although the pronoun "you" is unbound. For LISP, it's an edge network (in your vocabulary),a site in others' vocabulary, etc. For HIPP, you is bound to a something. Some people would probably say stack, although that's misleading as HIP explicitly supports stacks with multiple HITs. For shim6, you is bound to something close to stack, although it's a bit more complicated than that. The second paragraph has not undergone a lot of editing other than to remove LISP-specific terms from the general description. However, it also has not drawn a lot of fire. If you do try to build consensus behind a change, I strongly recommend against introducing new terms or acronym expansions. From hartmans@mit.edu Mon Mar 30 19:58:10 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E55E3A6930 for ; Mon, 30 Mar 2009 19:58:10 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO1TVytTMQyK for ; Mon, 30 Mar 2009 19:58:09 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 5A7913A65A6 for ; Mon, 30 Mar 2009 19:58:09 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id ZPNa1b00416AWCUA1eygqe; Tue, 31 Mar 2009 02:58:40 +0000 Received: from carter-zimmerman.suchdamage.org ([74.92.229.90]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id Zez21b00A1xg5mq8Sez861; Tue, 31 Mar 2009 02:59:08 +0000 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 93D684182; Mon, 30 Mar 2009 22:59:00 -0400 (EDT) To: Damien Saucez References: <49D067FF.4050002@uclouvain.be> From: Sam Hartman Date: Mon, 30 Mar 2009 22:59:00 -0400 In-Reply-To: <49D067FF.4050002@uclouvain.be> (Damien Saucez's message of "Mon\, 30 Mar 2009 08\:34\:39 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] LISP: update to charter in external review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 02:58:10 -0000 >>>>> "Damien" == Damien Saucez writes: Damien> Would it be better to write "Submit mapping system(s) Damien> specification to the IESG as Experimental"? I think it Damien> would be interesting to propose ALT and an alternative to Damien> ALT. Under the current charter, proposing an alternative mapping system besides alt is out of scope. At the meeting, Jari indicated that this is intentional and that he does not want to expand our scope to consider new mapping systems. Damien> Can we really propose the LISP specification in March and Damien> wait June for the security? What if we need to modify some Damien> messages to support the security? We'll have to be fairly careful about this. I'm assuming that security document is an analysis/description/future work document. To the extent that we need to do security work that affects protocol messages, it will need to be part of the base spec. From menth@informatik.uni-wuerzburg.de Tue Mar 31 13:43:52 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347843A67AE; Tue, 31 Mar 2009 13:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-0PqCET7cH6; Tue, 31 Mar 2009 13:43:51 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id BEC083A67B0; Tue, 31 Mar 2009 13:43:50 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 2A3EEA0707; Tue, 31 Mar 2009 22:44:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1D5B0A06F1; Tue, 31 Mar 2009 22:44:47 +0200 (CEST) Received: from [78.52.62.80] (unknown [78.52.62.80]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id C5245199093; Tue, 31 Mar 2009 22:44:46 +0200 (CEST) Message-ID: <49D280C0.3090804@informatik.uni-wuerzburg.de> Date: Tue, 31 Mar 2009 22:44:48 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Sam Hartman References: <49D14697.5070306@informatik.uni-wuerzburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: lisp@ietf.org, ietf@ietf.org, iesg@ietf.org Subject: Re: [lisp] LISP: update to charter in external review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de 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, 31 Mar 2009 20:43:52 -0000 Sam Hartman schrieb: >>>>>> "Michael" == Michael Menth writes: >>>>>> > > Michael> The sentence "who you are" is rather confusing to me > Michael> although its intention is certainly to be a simple and > Michael> catchy explanation. However, "you" - the user (?) is > Michael> probably not an edge interface designator. "who you are" > Michael> suggests that the identifier has something to do with the > Michael> identity of some device or its owner (whoever "you" is) > Michael> that would stay the same when moving around which is > Michael> clearly not the case in this context. > > Michael> Wouldn't it be clearer to say: core Routing Locators > Michael> (which describe "where" an edge network is attached to > Michael> the Internet core) and edge interface designators (which > Michael> describe to "which" interface a device is attached within > Michael> an edge network)? I find this easier to understand and > Michael> according to my understanding this is 100% in line with > Michael> the third paragraph of the charter. > > > the second paragraph is intended to be far more general than LISP and > carefully avoids using any LISP terms. Indeed, the second paragraph does not yet contain the word LISP, that's true, but somehow my expectation was that the second paragraph of the charter must be about LISP. And my expectation was confirmed by the word "Routing Locator" (uppercase) instead of simply "locator" (lowercase) and Identifier (uppercase) instead of "identifier" (lowercase). I read both uppercase words as proper names of a specific architecture which was LISP for me in this context. So, the removal of LISP-specific or LISP-like nomenclature was not yet fully successful. But I don't think that this was the major problem. > I think it is accurate, > although the pronoun "you" is unbound. For LISP, it's an edge network > (in your vocabulary),a site in others' vocabulary, etc. For HIPP, you > is bound to a something. Some people would probably say stack, > although that's misleading as HIP explicitly supports stacks with > multiple HITs. For shim6, you is bound to something close to stack, > although it's a bit more complicated than that. > > The second paragraph has not undergone a lot of editing other than to > remove LISP-specific terms from the general description. However, it > also has not drawn a lot of fire. The unbound pronoun "you" really puzzled me. Your interpretation of the "you" with the examples of the other architectures makes sense to me, but the text says nothing about them. I rather read the text "Identifier (who you are)" as an implicit definition of what an identifier is, namely a name that has something to do with my identity or that of my devices. I found this implicit definition a contradition to how an identifier is used in the third paragraph. I did not carefully follow all the discussions on this list, but I was curious about how the charter looks in the end. And when I saw the new charter I was just puzzled about the implicit definition of an identifier and its subsequent clarification of the opposite in LISP. I certainly do not want to propose a specific changes to the charter, I was just wondering and wanted to give you feedback. You can apply changes if you think that my misunderstanding has something to do with the text. Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From hartmans@mit.edu Tue Mar 31 16:15:21 2009 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8E23A6B0F; Tue, 31 Mar 2009 16:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYwU8+6MYyhU; Tue, 31 Mar 2009 16:15:21 -0700 (PDT) Received: from luminous.suchdamage.org (luminous.suchdamage.org [69.25.196.179]) by core3.amsl.com (Postfix) with ESMTP id 0409F3A6AB4; Tue, 31 Mar 2009 16:15:21 -0700 (PDT) Received: by luminous.suchdamage.org (Postfix, from userid 8042) id 74D8957C0C2; Tue, 31 Mar 2009 19:16:18 -0400 (EDT) From: Sam Hartman To: menth@informatik.uni-wuerzburg.de References: <49D14697.5070306@informatik.uni-wuerzburg.de> <49D280C0.3090804@informatik.uni-wuerzburg.de> Date: Tue, 31 Mar 2009 19:16:18 -0400 In-Reply-To: <49D280C0.3090804@informatik.uni-wuerzburg.de> (Michael Menth's message of "Tue, 31 Mar 2009 22:44:48 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org, ietf@ietf.org, iesg@ietf.org Subject: Re: [lisp] LISP: update to charter in external review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 23:15:21 -0000 Sorry, I didn't notice the upper case terms in the second paragraph. I definitely agree they should be removed.