From lisp-bounces@ietf.org Fri Jan 9 08:24:42 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D973A6A30; Fri, 9 Jan 2009 08:24:42 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD393A6994 for ; Fri, 9 Jan 2009 08:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 KeHhpT0T+exg for ; Fri, 9 Jan 2009 08:24:38 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 466F23A6B2A for ; Fri, 9 Jan 2009 08:24:38 -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 n09GO2iP025376; Fri, 9 Jan 2009 08:24:02 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n09GO2NC025375; Fri, 9 Jan 2009 08:24:02 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 9 Jan 2009 08:24:02 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090109162402.GA25242@1-4-5.net> MIME-Version: 1.0 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: thomas.r.henderson@boeing.com, jnc@mercury.lcs.mit.edu, eric.fleischman@boeing.com, Fred.L.Templin@boeing.com, jeanjour@comcast.net Subject: [lisp] regarding draft-meyer-loc-id-implications-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: , Content-Type: multipart/mixed; boundary="===============1308516428==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1308516428== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks, There are several ongoing threads on the contents of the included draft and what its implications are for the various locator/id separation approaches. I wanted to move the discussion to a more public forum. Please chime in with your thoughts/comment. Thanks, Dave --- Network Working Group D. Meyer Internet-Draft D. Lewis Intended status: Informational Cisco Expires: June 22, 2009 December 19, 2008 Architectural Implications of Locator/ID Separation draft-meyer-loc-id-implications-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 22, 2009. Abstract Recent work on Locator/ID Separation has focused primarily on the control plane protocols concerned with finding Identifier-to-Locator mappings. However, experience gained with a trial deployment of a system designed to implement Locator/ID Separation has revealed two general classes of problems which must be resolved after the mapping is found: The Locator Path Liveness Problem and the State Synchronization Problem. These problems have implications for the data plane as well as the control plane. Meyer & Lewis Expires June 22, 2009 [Page 1] Internet-Draft Loc/ID Split Implications December 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Problem Space . . . . . . . . . . . . . . . . . . . . . . 4 3. The Locator Path Liveness Problem . . . . . . . . . . . . . . 4 3.1. Complexity . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Complexity of Host-Based Probing . . . . . . . . . . . 7 3.1.2. Complexity of Network-Based Probing . . . . . . . . . 7 3.2. Possible Optimizations . . . . . . . . . . . . . . . . . . 7 3.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 9 4. Site-Based State Synchronization . . . . . . . . . . . . . . . 10 4.1. Complexity . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considersations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Meyer & Lewis Expires June 22, 2009 [Page 2] Internet-Draft Loc/ID Split Implications December 2008 1. Introduction Locator/ID Separation (hereafter Loc/ID split) has been proposed as an architectural enhancement to the Internet architecture to facilitate, among other things, scaling of the global routing system [RFC1498][Chiappa99][Fuller06][RFC4984]. The basic idea is that the current number space (the IPv4/IPv6 address space) is overloaded with both location and identity semantics. One consequence of this overloading is that it is difficult to assign routing locators (RLOCs) in a way that is congruent with the underlying network topology; this makes aggregation difficult (if not impossible). This property is sometimes referred to as Rekhter's Law, and is frequently formulated as follows: "Addressing can follow topology or topology can follow addressing. Choose one." Endpoint Identifiers (EIDs), on the other hand, are typically assigned without regard to the underlying network topology (e.g., Host Identity Tags [RFC4423]). This makes it difficult for a single numbering space to efficiently serve the routing locator and endpoint identifier roles. Locator/Identity Separation can be used to decouple the allocation of of EIDs from RLOCs, enabling the RLOC space to be aggressively aggregated (i.e., by aligning RLOC allocations with the underlying network topology). The positive effect of such aggregation would be to control the growth of global routing state (note that aggregation in the EID space may also an issue, but as of this writing hasn't been extensively explored). Recent work on Locator/ID Separation has focused almost exclusively on control plane protocols for finding Identifier-to-Locator mappings (for example, [I-D.fuller-lisp-alt][I-D.jen-apt] [I-D.lear-lisp-nerd]). However, experience gained with a trial deployment of a system designed to implement Locator/ID Separation has revealed two general classes of problems which must be resolved after the mapping is found: The Locator Path Liveness Problem and the State Synchronization Problem. These problems have implications for the data plane as well as the control plane. This document focuses on the Locator Path Liveness and State Synchronization problems, and is organized as follows: Section 2 provides an overview of the problem space. Section 3 discusses the Locator Path Liveness problem, and Section 4 discusses the State Synchronization problem. Finally, Section 5 provides a few conclusions. Meyer & Lewis Expires June 22, 2009 [Page 3] Internet-Draft Loc/ID Split Implications December 2008 2. The Problem Space Decoupling Location and Identity has profound implications both the control and data planes. In particular, decoupling location from identity leads to the two difficult problems: First, give a set of source locators and a set of destination locators, it must be possible to determine whether a particular destination locator is reachable. We refer to this general problem as the Locator Path Liveness Problem. The Locator Path Liveness Problem is exhibited in host-based architectures such as SHIM6 [I-D.ietf-shim6-proto]) and network-based architectures such as eFIT [EFIT] and [LISP]). The "Hybrid Rewriting" class of architectures (e.g., ,GSE [ODell97]) exhibit a slight variant on the problem. Locator Liveness is discussed in Section 3. The second problem is that mapping state may need to be shared among network elements (this is as opposed to the determining if the locator itself is up or down). This is referred to as the Site-Based State Synchronization Problem, and is specific to network-based architectures. The Site-Based State Synchronization problem is discussed in Section 4. 3. The Locator Path Liveness Problem The Locator Path Liveness Problem can be stated as follows: Given a set of source locators and a set of destination locators, can bidirectional connectivity be determined between the address pairs? A simple example illustrates the problem: Consider the scenario depicted in Figure 1. Here a site S0 is multihomed to provider A and provider B. Further, suppose that S0 has a Provider Assigned (PA) locator from provider A (call it La) and a PA locator, Lb, from provider B. Suppose that provider A peers with provider B. In this case, S0 might "advertise" that its EID-prefixes can be reached through nodes La and Lb (either via DNS, explicit protocol message such as a Map-Reply message [LISP], or other method) to its correspondent sites. Now, suppose that a correspondent site S1 is connected to provider C, and that S0 has told S1 that it can reach S0 on either La or Lb. Suppose further that S1 chooses La to reach S0, so that packets sourced from S1 destined for S0 traverse the path S1->C->B->A->S0. Note that if connectivity between provider B and provider A is disrupted (for either business or technical reasons), La will not be reachable from S1. In this case, S1 must detect that La is no longer Meyer & Lewis Expires June 22, 2009 [Page 4] Internet-Draft Loc/ID Split Implications December 2008 reachable and use Lb to restore connectivity (in the event that S1 wants to restore connectivity; in today's Internet, would S0 would continue to be unreachable). S1 | | C | | A-----------------B \ peering link / \ / \ / \ / \ / La Lb \ / S0 Figure 1: Reachibility Failure The Locator Path Liveness problem arises in subtly different ways, depending on the contents of the mapping database (i.e., EIDs, RLOCs, or some combination of these), who queries the database (host or network element), and how knowledge is distributed between hosts and routing. Note that in general, Locator Path Liveness must be tested in the data plane (although an implementation might take advantage of various "hints; see Section 3.2). Host-Based Architectures: In host-based architectures (e.g., SHIM6 [I-D.ietf-shim6-proto]), the problem arises because queries to the database (DNS in this case) return "addresses" which can be thought of as a concatenation of the RLOC and EID. Since a host is anticipated to have multiple such "addresses" (at least in the SHIM6 case), it must choose a working pair from among its potential source addresses and its correspondent destination addresses. REAP [I-D.ietf-shim6-failure-detection] is a probe-based reachability protocol which is designed to address this problem. Hybrid Network-Based Rewriting Archtectures: In hybrid network-based rewriting architectures (e.g., GSE [ODell97]), the problem arises because there is a knowledge asymmetry between the host and routing. Specifically, while the host is responsible for selecting the destination Routing Goop (RG) (i.e., the ingress point to the destination domain, essentially the destination RLOC), it is routing that selects the source RG. So while the IGP Meyer & Lewis Expires June 22, 2009 [Page 5] Internet-Draft Loc/ID Split Implications December 2008 routing in a domain can be intelligent about egress points from the domain, it is the destination address, chosen by the host, that selects the ingress point in the destination domain. However it is routing, and not the host, that knows if the destination is reachable or not. Section 4.2 of [Zhang06] discusses this issue from a slightly different point of view. This asymmetry gives rise to the following problem: Hosts will likely want information, at some granularity, about which pairs currently work. However, the host has no information about how many RGs are available to the site or if they are currently reachable. So the host can not test the set of pairs for active paths. On the other hand, the routing can't either, unless it snoops on TCP connections (which doesn't deal with asymmetric paths, UDP flows, or unidirectional flows). It is worth noting that unlike most "modern" descriptions of how GSE uses the DNS (e.g., [Zhang06]), the original GSE design [ODell97][ODell08] envisioned that the DNS would have a new resource record type, the RG record, to carry a site's RGs. Hosts would only have AAAA records. The idea was that for a given destination domain, a host in the source domain would compute the Cartesian Product {RGs}x{A4s}. Thus alternate path sensing would become a a matter of local policy, and not hard-wired by the destination domain (or whoever happens to be authoritative for the destination domain's names). Notice however that even the introduction of the RG resource record, the knowledge asymmetry remains. Network-Based Map-and-Encap Archtectures: In the case of map-and- encap network-based architectures, the problem arises because the mapping element (e.g., Ingress Tunnel Router, or ITR) must choose among the RLOCs it has learned for a given EID-prefix. Here since the ITR holds the mappings that knows the set of possible remote "addresses" and not the host, the host may choose among multiple EIDs, but it cannot choose among the possible RLOCs (the host has no access to that information). Hence if the ITR chooses a RLOC that may not be reachable, traffic to the destination site will be blackholed, and the host is left with no recourse. 3.1. Complexity The complexity of testing Locator Path Liveness in the data plane is roughly O(M*N), where there are M source addresses and N destination addresses. The following sections more closely analyze the complexity of host-based and network-based liveness probing. Meyer & Lewis Expires June 22, 2009 [Page 6] Internet-Draft Loc/ID Split Implications December 2008 3.1.1. Complexity of Host-Based Probing Host-based implementations must keep per-correspondent host liveness state. The complexity of probing in a host-based implementation can be though of as follows: Let C = the number of correspondent hosts Let D_i = the number of destination locators for host C_i Let S = the number of source locators Then the complexity of host-based probing, P_host, is O(P_host), where P_host = S*sum(D_i), i = 0...C-1 3.1.2. Complexity of Network-Based Probing Network-based implementations must keep per-destination egress point liveness. The complexity of probing in a network-based implementation can be thought of as follows: Let N = the number of EID-prefixes in a network element's cache Let L_i = the number of locators for EID-prefix N_i Let M = the number of source locators Then the complexity of network-based probing, P_network, can be described as O(P_network), where P_network = M*sum(L_i), i = 0...N-1 Note that a network-based probing scheme might have an advantage here since a single EID-prefix may cover many correspondent hosts. That is, sum(L_i), i = 0...N-1 < sum(D_i), i = 0...C-1 3.2. Possible Optimizations The previous sections analyzed the complexity of explicitly probing to assess Locator Path Liveness. In order to mitigate this complexity, an implementation might attempt to rely on the various "hints". The following sections, while not intended to be an exhaustive survey, outline some of the Locator Path Liveness hints an implementation may utilize. Data Traffic: When data is received, an implementation might assume that the source of that traffic is reachable, and as such probing might not be needed. Of course, this is at best a unidirectional "hint" that an implementation might use to determine locator liveness. Of course, only a complete round trip, wherein the Meyer & Lewis Expires June 22, 2009 [Page 7] Internet-Draft Loc/ID Split Implications December 2008 distant site says something back to the local site which the local site originally sent to the distant site, can one then guarantee that the distant site can hear the local site. A variation on this theme is to "piggyback" liveness testing on user data traffic, by adding a Solicit-User-Probe-Reply bit, which tells the far end to send back the next user data packet(s) with the outbound nonce, and a User-Probe-Reply bit set. Of course, this optimization depends on the existence of some traffic (even if not for the same connection) going between pairs of border elements. That is, if a particular pair has only traffic in one direction, this method fails. In addition, it requires extra processing on user data packets, extra overhead in the packets (a field, some bits), and extra protocol complication. Of course, such piggybacking only provides the view from remote domain, not whether the locator is actually reachable from the recipient of the "User-Probe-Bit". Protocol Control Messages: If a protocol control message is received (for example, a Map-Reply), an implementation may conclude that the source of that is reachable. Again, in the best case, this is only a hint, since receipt of the control message proves only unidirectional connectivity. Piggybacking Liveness Indications: A network-based architecture might piggyback indication of intra-domain locator liveness on other data and/or protocol messages. An example of this approach is LISP's use of loc-reach bits to indicate which Egress Tunnel Routers in a domain are up (from an inside the domain perspective). Existence of the Locator in underlying routing: A device which is responsible for locator liveness can utilize underlying routing to determine if the locator is at all available. If the network prefix (or a covering aggregate) for the destination locator is NOT found in underlying routing, then the path will not be available. This is at best a negative detection, it can show when a path is not available, but liveness of a particular locator. A given locator may still be unavailable and this not be shown in routing, due to data plane filtering, or the reachability being hidden by aggregation of the particular locator prefix. Positive Feedback From Other Protocols: An implementation may be able to deduce some forms of reachability from other protocols. For example, TCP might indicate to the IP layer that it believes that there is bidirectional connectivity between a given address pair. This might be signalled to the source when it receives a SYN-ACK from the destination RLOC. As pointed out in Meyer & Lewis Expires June 22, 2009 [Page 8] Internet-Draft Loc/ID Split Implications December 2008 [I-D.ietf-shim6-failure-detection], this is similar to how IPv6 Neighbor Unreachability Detection can be avoided when upper layers provide information about bidirectional connectivity [RFC4861]. If an implementation has access to higher layer protocols (e.g., BGP), it might get a hint as to the reachability of a given locator. In the case of BGP, an implementation might conclude that the locator is reachable if there is a covering prefix in the BGP Routing Information Base (RIB). Again, this is a hint, because the correspondent host may be down. Timeouts: An implementation may be able to deduce some forms of Unreachability from timeouts of other protocols.For example, TCP to indicate that there is a lack of connectivity because it is not getting ACKs (of course, the signal is overloaded: there may be congestion). ICMP Messages: While ICMP is an available signalling protocol, due to its lack of security (in particular, ease of spoofing [I-D.ietf-tcpm-icmp-attacks]) and the fact that common policy is to block or rate limited ICMP, its utility has been somewhat marginalized (see Section 3.3). As such, ICMP may perhaps be used as a hint but beyond that, an implementation can not rely on ICMP as a signalling mechanism. QQQ: Again, when do I know a locator is up? If I probe and the response is positive, does that mean its up (i.e., it can go down in the interim, so what is the time granularity, and what effect does that have on efficiency? In general, depending on end-to-end liveness indications is applicable to only to host-based solutions (e.g., [I-D.ietf-shim6-proto]). A network-based implementation may rely on higher layer protocols to indicate liveness (for example, an implementation may be able deduce a limited form of reachability from the existence of a BGP route covering the destination RLOC), but these too can only be used as hints. In the general case, however, an architecture that implements Loc/ID split (either host-based or network-based) will need to test Locator Path Liveness in the data plane 3.3. Security Issues Mere inspection of insecure traffic may lead to false negative detection due to the insertion of malicious traffic. For instance, packets that masquerade as coming from a site may tamper with the loc-reach-bits, making the site locators look unreachable where in fact they are reachable [LISP]. Meyer & Lewis Expires June 22, 2009 [Page 9] Internet-Draft Loc/ID Split Implications December 2008 ICMP Messages: ICMP messages are are easily spoofable [I-D.ietf-tcpm-icmp-attacks], so may be exploited to provide false negatives. However, they are also rate limited and often outright disabled, leaving a site sending data to a remote RLOC under the impression that the RLOC is reachable (as a false positive side effect). Existance of the Locator in the BGP RIB: This vulnerability is shared by non-Loc/ID split architectures (need reference to Pakistani-youtube example as a way compromised routing can break path liveness). Aside from the ability to mislead a poorly implemented probing mechanism with data spoofing, probing creates a fundamentally unscalable relationship between site pairs (see Section 3.1). This leads to both implicit (unscalable) and explicit (vulnerable to probe floods) Denial of Service vulnerability in the systems receiving probe requests. Finally, note that in the case of network-based Loc/ID split architectures, the RLOCs of border elements represent reachability on behalf of entire site. As a result, failure to detect path liveness can disrupt connectivity to the entire site. On the other hand, in host-based LIS, only individual hosts are compromised. 4. Site-Based State Synchronization The Site-Based State Synchronization problem is specific to network- based Loc/ID split architectures. There are two kinds of state synchronization that might need to be performed: mapping state synchronization and locator liveness synchronization. The Site-Based State Synchronization problem can most easily be demonstrated by a simple example. Consider the following case: A site has two ITRs; one ITR is on the active path and the other ITR is on a backup path. In this case, all traffic egressing from the site traverses the ITR on the active path, and as a result that ITR is caching the mapping state for all of the active flows. The ITR on the backup path has no mapping state. Now, when the ITR on the active path fails, traffic is naturally shifted to the ITR on the backup path. If the now active ITR hasn't synchronized its state with the previously active ITR(s), then the newly active ITR has to reconstruct the mapping state for the flows that were traversing the failed ITR. In particular, the failure, which is local to the site, requires the now active ITR to go off-site to reconstruct the state. Meyer & Lewis Expires June 22, 2009 [Page 10] Internet-Draft Loc/ID Split Implications December 2008 4.1. Complexity TBD 5. Conclusions Architectures that implement Locator/ID Separation (either host or network based) need to carefully evaluate the complexity inherent in determining Locator Path Liveness. The complexity of mapping state synchronization is an additional concern for network-based architectures. 6. Acknowledgments Scott Brim, Noel Chiappa, John Day, Dino Farinacci, Vince Fuller, Mike O'Dell, Andrew Partan, and John Zwiebel provided insightful comments on early versions of this document. 7. IANA Considersations This document creates no new requirements on IANA namespaces [RFC2434]. 8. References 8.1. Normative References [Chiappa99] Chiappa, N., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", xxx 1999. [EFIT] Massey, D., "A Proposal for Scalable Internet Routing & Addressing", Feb 2007. [Fuller06] Fuller, V., "Scaling issues with ipv6 routing+ multihoming", Oct 2006. [I-D.fuller-lisp-alt] Farinacci, D., "LISP Alternative Topology (LISP+ALT)", draft-fuller-lisp-alt-02 (work in progress), April 2008. [I-D.ietf-shim6-failure-detection] Arkko, J. and I. Beijnum, "Failure Detection and Locator Meyer & Lewis Expires June 22, 2009 [Page 11] Internet-Draft Loc/ID Split Implications December 2008 Pair Exploration Protocol for IPv6 Multihoming", draft-ietf-shim6-failure-detection-13 (work in progress), June 2008. [I-D.ietf-shim6-proto] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work in progress), February 2008. [I-D.ietf-tcpm-icmp-attacks] Gont, F., "ICMP attacks against TCP", draft-ietf-tcpm-icmp-attacks-03 (work in progress), March 2008. [I-D.jen-apt] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and L. Zhang, "APT: A Practical Transit Mapping Service", draft-jen-apt-01 (work in progress), November 2007. [I-D.lear-lisp-nerd] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-04 (work in progress), April 2008. [LISP] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-10 (work in progress), Oct 2008. [ODell08] Odell, M., "GSE - An Alternate Addressing Architecture for IPv6 (Private Communication)", Dec 2008. [ODell97] Odell, M., "GSE - An Alternate Addressing Architecture for IPv6", Oct 2006. [RFC1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Meyer & Lewis Expires June 22, 2009 [Page 12] Internet-Draft Loc/ID Split Implications December 2008 Workshop on Routing and Addressing", RFC 4984, September 2007. [Zhang06] Zhang, L., "An Overview of Multihoming and Open Issues in GSE", Sept 2006. 8.2. Informative References Authors' Addresses David Meyer Cisco Email: dmm@1-4-5.net Darrel Lewis Cisco Email: darlewis@cisco.com Meyer & Lewis Expires June 22, 2009 [Page 13] Internet-Draft Loc/ID Split Implications December 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Meyer & Lewis Expires June 22, 2009 [Page 14] --W/nzBZO5zC0uMSeA 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) iEYEARECAAYFAklneiIACgkQORgD1qCZ2KdyygCgjV69rNLaPtpTf8WDfVVn3ih4 xsoAn30m1ROm0gSSudjcA+sSacGmYL89 =AOmn -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- --===============1308516428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1308516428==-- From lisp-bounces@ietf.org Sun Jan 11 13:39:55 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CF53A6922; Sun, 11 Jan 2009 13:39:55 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8B23A6922 for ; Sun, 11 Jan 2009 13:39:53 -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 DLZFZjcEoeIM for ; Sun, 11 Jan 2009 13:39:52 -0800 (PST) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 63A383A67B6 for ; Sun, 11 Jan 2009 13:39:52 -0800 (PST) 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=SXJU+U/rWF5NrUvPllPkGZcFJFo=; b=AQH8HuNZzL /Z2kn+GmdQ1M6Lpcv2iMIvit6RsK4ax+Nfmqx7sT7t2O6TeFT/nv6KECBhfEAdIZ MMMtD1WPACKeZIfc0odt8t2E7Ud685b5gVZ3OhfowW4BW1Z2Cu/f3H9PkZ8KvFWN 93EFp1jrKswjq4i0dXnYzgImjsRfDHxOQ= 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=GfmMx JcVwLQ7DYqQL9C84K3h6wTFcfQw+z9hMupOepyBpoToVPbtoR3oqzUN2h+4OVdAL q8bUVm42s/bpdMZqsN6ZlFA57PY/miHBzB+M+OL18KVfARjqCTXQltoKvM+Vuh76 Bv4n4upV1ziDxH4l9JXQZbUw5kqZ+0VJCZZFPU= Received: from mbpobo.local (ip-83-134-192-129.dsl.scarlet.be [83.134.192.129]) (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; Sun, 11 Jan 2009 22:39:33 +0100 (CET) Message-ID: <496A6711.80201@uclouvain.be> Date: Sun, 11 Jan 2009 22:39:29 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: David Meyer References: <20090109162402.GA25242@1-4-5.net> In-Reply-To: <20090109162402.GA25242@1-4-5.net> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 655841C819E.A6228 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org, =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= Subject: Re: [lisp] regarding draft-meyer-loc-id-implications-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dave, > > There are several ongoing threads on the contents of the > included draft and what its implications are for the > various locator/id separation approaches. I wanted to > move the discussion to a more public forum. Please chime > in with your thoughts/comment. The draft asks important questions. Finding an answer to these questions will be key for a widespread deployment of solutions such as LISP. Concerning the discussion on host-based probing, you might be interested by the simulation studies and measurement studies made with REAP for shim6, see e.g. A. de la Oliva, M. Bagnulo, A. Garcia-Martinez, I. Soto, Performance Analysis of the REAchability Protocol for IPv6 Multihoming, Conference on Next Generation Teletraffic and Wired/Wireless Advanced Networking (NEW2AN 2007), September 2007 http://www.shim6.org/47120443.pdf S. Barre, O. Bonaventure, Improved Path Exploration in shim6-based multihoming, SIGCOMM 2007 Workshop, IPv6 and the Future of the Internet, August 2007 http://inl.info.ucl.ac.be/publications/improved-path-exploration-shim6-based There is an implementation of REAP running on the Linux kernel if someone wants to perform more experiments with REAP, see http://inl.info.ucl.ac.be/softwares/linshim6 Best regards, Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 12 08:12:17 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B686A3A6AFE; Mon, 12 Jan 2009 08:12:17 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F88528C0EF for ; Mon, 12 Jan 2009 08:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 JkEyT9Jws1gd for ; Mon, 12 Jan 2009 08:12:14 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id BF1B63A683A for ; Mon, 12 Jan 2009 08:12: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 n0CGC09T015679; Mon, 12 Jan 2009 08:12:00 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0CGC0xZ015678; Mon, 12 Jan 2009 08:12:00 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 12 Jan 2009 08:12:00 -0800 From: David Meyer To: Olivier Bonaventure Message-ID: <20090112161200.GA15655@1-4-5.net> References: <20090109162402.GA25242@1-4-5.net> <496A6711.80201@uclouvain.be> MIME-Version: 1.0 In-Reply-To: <496A6711.80201@uclouvain.be> 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, =?iso-8859-1?Q?S=E9bastien_Barr=E9?= Subject: Re: [lisp] regarding draft-meyer-loc-id-implications-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: , Content-Type: multipart/mixed; boundary="===============2002045851==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============2002045851== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 11, 2009 at 10:39:29PM +0100, Olivier Bonaventure wrote: > Dave, > >=20 > > There are several ongoing threads on the contents of the > > included draft and what its implications are for the > > various locator/id separation approaches. I wanted to > > move the discussion to a more public forum. Please chime > > in with your thoughts/comment. >=20 > The draft asks important questions. Finding an answer to these questions > will be key for a widespread deployment of solutions such as LISP. >=20 > Concerning the discussion on host-based probing, you might be interested > by the simulation studies and measurement studies made with REAP for > shim6, see e.g. >=20 > A. de la Oliva, M. Bagnulo, A. Garcia-Martinez, I. Soto, Performance > Analysis of the REAchability Protocol for IPv6 Multihoming, Conference > on Next Generation Teletraffic and Wired/Wireless Advanced Networking > (NEW2AN 2007), September 2007 > http://www.shim6.org/47120443.pdf >=20 > S. Barre, O. Bonaventure, Improved Path Exploration in shim6-based > multihoming, SIGCOMM 2007 Workshop, IPv6 and the Future of the Internet, > August 2007 > http://inl.info.ucl.ac.be/publications/improved-path-exploration-shim6-ba= sed >=20 > There is an implementation of REAP running on the Linux kernel if > someone wants to perform more experiments with REAP, see > http://inl.info.ucl.ac.be/softwares/linshim6 >=20 Thanks Olivier. I did a "lite" literature search for the draft, and this is very helpful. Dave --azLHFNyN32YCQGCU 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) iEYEARECAAYFAklra9AACgkQORgD1qCZ2KdFNQCcDTm2vrcsXePlTWvH95MY6/8f 1+sAniK0IfPScGMCcWrbY2qcbhZnydfZ =vIhu -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- --===============2002045851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============2002045851==-- From lisp-bounces@ietf.org Thu Jan 15 10:56:18 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4DFA28C278; Thu, 15 Jan 2009 10:56:18 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D4A3A6778; Thu, 15 Jan 2009 10:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 k4vAAeD+pqZj; Thu, 15 Jan 2009 10:56:16 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 138AF3A6774; Thu, 15 Jan 2009 10:56:16 -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 n0FIu09P020124; Thu, 15 Jan 2009 10:56:00 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0FIu01U020123; Thu, 15 Jan 2009 10:56:00 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 15 Jan 2009 10:56:00 -0800 From: David Meyer To: "Fleischman, Eric" Message-ID: <20090115185600.GA20104@1-4-5.net> References: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 In-Reply-To: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.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@irtf.org, lisp@ietf.org Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1935315869==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1935315869== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > subset of interested parties. Somebody (Dave Meyer??) requested that Guilty :-) But seriously, thanks Eric. Dave --YiEDa0DAkWCtVeE4 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) iEYEARECAAYFAklvhsAACgkQORgD1qCZ2KfjLQCfbsDTijzt4oy+IkLj8guFl/Bt WOAAoIT2FPd07Qg6eGneGi3h6+YLjIDr =h8u5 -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- --===============1935315869== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1935315869==-- From lisp-bounces@ietf.org Thu Jan 15 11:32:29 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168FC3A69EB; Thu, 15 Jan 2009 11:32:29 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E203A67AB for ; Thu, 15 Jan 2009 11:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WRv7LaAf9Sn for ; Thu, 15 Jan 2009 11:32:26 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 24A033A69EB for ; Thu, 15 Jan 2009 11:32:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,272,1231113600"; d="scan'208";a="33927483" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Jan 2009 19:32:10 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0FJWAGv003456; Thu, 15 Jan 2009 14:32:10 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0FJWAD7000377; Thu, 15 Jan 2009 19:32:10 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); Thu, 15 Jan 2009 14:32:10 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jan 2009 14:32:10 -0500 Date: Thu, 15 Jan 2009 14:32:05 -0500 From: Scott Brim To: "Fleischman, Eric" Message-ID: <20090115193205.GA49353@cisco.com> Mail-Followup-To: Scott Brim , "Fleischman, Eric" , lisp@ietf.org, rrg@irtf.org References: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 15 Jan 2009 19:32:10.0305 (UTC) FILETIME=[F590A310:01C97747] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org, lisp@ietf.org Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Excerpts from Fleischman, Eric on Thu, Jan 15, 2009 10:42:12AM -0800: > 5) In RLOC/EID separation systems like HIP, the RLOC and EID each occurs > on different layers of the protocol stack. Therefore, attempting to get > IP routing, which works on the IP layer (i.e., RLOC layer) to be aware > of multi-homing, which occurs on the EID layer (i.e., the session layer > within HIP), is a protocol layer violation. Nor should it. IP routing itself should deal with finding paths to destinations (and forwarding should deal with forwarding individual packets). Determining that that sending to either of two apparently different destinations gets the packet to the same higher layer entity has nothing to do with routing. > 6) IP routing is not equipped to natively be able to do multi-homing > and attempts to enhance it to do so further complicate the RLOC-EID > confusion and actively harm the Internet. Attempting to enhance > routers to handle multi-homing inherently violates the loc/ID split > concept. The desired distinction between EID and RLOC needlessly > becomes replaced by mutual dependencies between the two concepts. By > adding EID dependencies to RLOC, there cannot be "better aggregation > in the RLOC space" because no RLOC space can exist. Rather, that > space potentially becomes EID*RLOC space, which probably represents > significantly worse aggregation than the historic IP routing system. However, map-and-encap adds a new control and OAM relationship, between the "funnel" ingress and egress points. These are beyond the knowledge or control of endpoints, yet they promise to deliver packets, therefore they have a responsibility to find and use viable paths. They are not _just_ routers at this point. They are also endpoints in their own right. They are doing more than discovering paths and forwarding packets. Since _sites_ have multiple ingress points, multihoming applies here too, they have a responsibility to handle multihoming just as endpoint stacks do. Even if the session endpoints are already taking care of multihoming themselves, they are only capable of doing so over the choices that are given to them by the "funnel" endpoints. I don't think you can say the endpoints should take care of everything -- they can't. Anymore than the endpoints take care of everything when running over any underlying switched network. But the "funnel" endpoints do not know enough about what the session endpoints want or need -- is the endpoint already taking care of multipathing? Does it require session continuity and thus must have backup paths lined up at all times? And so on. Therefore the funnel endpoints overdo their responsibility. It's clear that pure endpoint-based multipathing, =E0 la Shim6 REAP, cannot scale. Putting path failure detection and recovery in ITRs instead of in the endpoints can greatly reduce the number of messages flying around, but a simple approach there doesn't scale either, and without information they don't have much choice. = One thing we could do is to couple them. The endpoint could periodically tell "the network" what it needs, so the network only needs to do just enough. = Another thing we can do is cut back on our requirements, at least for a while. > 7) The RLOC-EID split concept therefore means that multihoming needs to > be solved at a layer above the IP layer that can naturally see the EID. > Attempts to simultaneously achieve a Loc/Id split and have routing doing > multihoming are vectors that internally war with each other. The net > result are the types of problems identified in > draft-meyer-loc-id-implications-00.txt, problems that cannot occur if > the RLOC-EID distinction is done properly (i.e., RLOC and EID at > different layers of the protocol stack). > = > 8) When RLOC-EID is done properly (e.g., like HIP where each concept > appears on a different layer of the protocol stack), there is no > liveness problem (nor can there be one). Rather, the "liveness problem" > described in draft-meyer-loc-id-implications-00.txt is a generic problem > of map-and-encaps systems, not of RLOC-EID. The title and text of > draft-meyer-loc-id-implications-00.txt is therefore inappropriately > scoped as being caused by RLOC-EID when it is rather a common attribute > of map-and-encaps. Note that LISP is a map-and-encaps system. I don't see it. HIP properly removes dependency on location-based names from identification functions, but it does nothing to solve the multipath problem. You still need to find viable paths, ascertain that multiple locators refer to the same entity (difficult when one or both are moving -- rendezvous servers may be required, tsk), detect path failure and switch to another one. The same is true for Shim6, or Trilogy multipathing ... or anything where you have the chance of using multiple paths. A simple host in a simple PI-based AS can't, and therefore doesn't have a problem to solve. Adding HIP in fact makes the problem possible. > 9) It is useful to discuss both map-and-encaps and multihoming from the > insights contained within Fred Templin's VET/RANGER/SEAL I-D trilogy. > This trilogy discusses scalable map-and-encaps systems and indicates how > to resolve the liveness problem for those systems. It also provides an > important context for describing multihoming because it identifies the > recursive nature of the "enterprise" concept. Without leveraging the > insights of this trilogy, multihoming may appear to mean different > things in different contexts: Autonomous systems can be multihomed. > Mobile platforms can be multihomed. Hosts can be multihomed. Etc. These > different environments are recursive instances to different sized > "enterprise" entities. Failing to realize this complicates discussions > about multi-homing. I'm partway through them. Sorry for not being able to respond about this part. Scott _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 15 13:11:00 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5950C3A6A3E; Thu, 15 Jan 2009 13:11:00 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B00E3A6A3E for ; Thu, 15 Jan 2009 13:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 z2lF2BzMGFXn for ; Thu, 15 Jan 2009 13:10:58 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0B6EA3A67AB for ; Thu, 15 Jan 2009 13:10:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,272,1231113600"; d="scan'208";a="33941156" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Jan 2009 21:10:42 +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 n0FLAeEG031368; Thu, 15 Jan 2009 16:10:41 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0FLAe7m005946; Thu, 15 Jan 2009 21:10:40 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jan 2009 16:10:40 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jan 2009 16:10:40 -0500 Date: Thu, 15 Jan 2009 16:10:38 -0500 From: Scott Brim To: Pekka Nikander Message-ID: <20090115211038.GJ41383@cisco.com> Mail-Followup-To: Scott Brim , Pekka Nikander , "Fleischman, Eric" , rrg@irtf.org, lisp@ietf.org References: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> <20090115193205.GA49353@cisco.com> <9C72DD31-8EF8-484D-90F7-81BDBB5A28D2@nomadiclab.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9C72DD31-8EF8-484D-90F7-81BDBB5A28D2@nomadiclab.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 15 Jan 2009 21:10:40.0180 (UTC) FILETIME=[B81FFF40:01C97755] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: "Fleischman, Eric" , rrg@irtf.org, lisp@ietf.org Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Excerpts from Pekka Nikander on Thu, Jan 15, 2009 10:37:16PM +0200: >> It's clear that pure endpoint-based multipathing, a la Shim6 REAP, >> cannot scale. > > Would you please be more specific. It is not at all clear to me. > AFAIK, SCTP is doing essentially the same thing. (I can see the > signalling load there, causing potential packet storms; is that the > "scalability" problem you are referring to?) I should have done the math first but ... Let's assume, conservatively, on the order of ten billion communicating endpoint pairs and 2 locators per endpoint. How often do you test locator pairs that you are not using? Let's be very conservative and assume once per minute (endpoints can get away with this low level). Even so, that's an extra 2^10 packets per minute across the core ... when things are going perfectly, just for steady state maintenance. I can't characterize what percentage of traffic that is, because, for example, there may be plenty of HTTP sessions that are idle but being kept open. We could reduce that maintenance overhead. Then we add in what happens when there is a network problem. I suspect that because there are active sessions and data is flowing, you would try all alternative paths at once, with fast probes and duplicate data packets. I really don't know what would happen, but I'm awed at the thought. >> Putting path failure detection and recovery in ITRs instead of in >> the endpoints can greatly reduce the number of messages flying >> around, but a simple approach there doesn't scale either, and >> without information they don't have much choice. > > AFAICS, the fundamental problem here is that the network today (BGP) > cannot detect failures at the desired speed, leading to the > situation where the hosts (or your funnel points) need to overcome > the deficiency. Suppose I am at locators A and B, you are talking to me at locator A and A becomes unreachable. Regardless of how fast routing detects that, you (an endpoint) are going to need to detect it yourself, verify that B is reachable, and switch to B, so you need your own fault detection and recovery protocol. >>> 8) When RLOC-EID is done properly (e.g., like HIP where each >>> concept appears on a different layer of the protocol stack), there >>> is no liveness problem (nor can there be one). >> >> I don't see it. HIP properly removes dependency on location-based >> names from identification functions, but it does nothing to solve >> the multipath problem. You still need to find viable paths, >> ascertain that multiple locators refer to the same entity >> (difficult when one or both are moving -- rendezvous servers may be >> required, tsk), detect path failure and switch to another one. > > I mostly agree. In the HIP WG, years ago the decision was to leave > the problem of path failure detection to the SHIM6 WG, with the > intention to integrate REAP to HIP. However, with HIP (even LHIP) > verifying that the locators refer to the same entity is relatively > easy, as long as at least one of the parties retains at least one > stable locator. Rendezvous servers are a nice way to introduce > stable locator to an otherwise dynamic system... And then, under > those assumptions, finding paths and switching over is relatively > easy. Works very well in practise. We've multiple times tested it > with both proxies and individual hosts, using 2-3 different radio > interfaces at each mobile host/proxy, and moving at typical vehicle > speeds in difficult terrain. But I digress. That's not a digression, that's real evidence :-). My concern is not that "finding paths and switching over is relatively easy", but what happens when everyone does it. Scott _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 15 13:25:59 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15FE93A67EF; Thu, 15 Jan 2009 13:25:59 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80A1C3A6928 for ; Thu, 15 Jan 2009 13:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 ScJRqMEY-P40 for ; Thu, 15 Jan 2009 13:25:58 -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 629A03A67AB for ; Thu, 15 Jan 2009 13:25:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,272,1231113600"; d="scan'208";a="129109088" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 15 Jan 2009 21:24:43 +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 n0FLOhlg009767; Thu, 15 Jan 2009 13:24:43 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0FLOTVD007318; Thu, 15 Jan 2009 21:24:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jan 2009 16:24:40 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jan 2009 16:24:40 -0500 Date: Thu, 15 Jan 2009 16:24:31 -0500 From: Scott Brim To: marcelo bagnulo braun Message-ID: <20090115212431.GA52863@cisco.com> Mail-Followup-To: Scott Brim , marcelo bagnulo braun , Pekka Nikander , "Fleischman, Eric" , rrg@irtf.org, lisp@ietf.org References: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> <20090115193205.GA49353@cisco.com> <9C72DD31-8EF8-484D-90F7-81BDBB5A28D2@nomadiclab.com> <20090115211038.GJ41383@cisco.com> <496FA860.6060409@it.uc3m.es> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <496FA860.6060409@it.uc3m.es> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 15 Jan 2009 21:24:40.0107 (UTC) FILETIME=[ACC2AFB0:01C97757] Authentication-Results: sj-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: Pekka Nikander , "Fleischman, Eric" , rrg@irtf.org, lisp@ietf.org Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Excerpts from marcelo bagnulo braun on Thu, Jan 15, 2009 10:19:28PM +0100: > Scott Brim escribi=F3: >> Excerpts from Pekka Nikander on Thu, Jan 15, 2009 10:37:16PM +0200: >> = >>>> It's clear that pure endpoint-based multipathing, a la Shim6 REAP, >>>> cannot scale. >>>> = >>> Would you please be more specific. It is not at all clear to me. >>> AFAIK, SCTP is doing essentially the same thing. (I can see the >>> signalling load there, causing potential packet storms; is that the >>> "scalability" problem you are referring to?) >>> = >> >> I should have done the math first but ... Let's assume, >> conservatively, on the order of ten billion communicating endpoint >> pairs and 2 locators per endpoint. How often do you test locator >> pairs that you are not using? = > what do you mean by a "locator pairs that you are not using"? > > You mean a locator pair that is not the one that is the current locator = > pair, or do you mean the current locator pair, but that you don't have = > data packets to send in this moment? > regards, marcelo If one end has locators A and B, and the other end has C and D ... then unless you are multipathing you will use a single pair, e.g. A-C, while A-D and B-C are not being used, just checked for liveness in case a need arises. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 15 13:40:58 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647693A67EF; Thu, 15 Jan 2009 13:40:58 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041B83A67EC for ; Thu, 15 Jan 2009 13:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 FQ7AXwDpNNLh for ; Thu, 15 Jan 2009 13:40:56 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 0E1293A6783 for ; Thu, 15 Jan 2009 13:40:56 -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 n0FLeZhf024707; Thu, 15 Jan 2009 13:40:35 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0FLeZrR024706; Thu, 15 Jan 2009 13:40:35 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 15 Jan 2009 13:40:35 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090115214035.GA24689@1-4-5.net> MIME-Version: 1.0 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] For those of you not subscribed to the RRG list [brian.e.carpenter@gmail.com: Re: [rrg] No liveness requirement in the ID/Loc Split concept] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1869684331==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1869684331== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from Brian E Carpenter ----- > From: Brian E Carpenter > To: "Fleischman, Eric" > Cc: rrg@irtf.org > Subject: Re: [rrg] No liveness requirement in the ID/Loc Split concept > Date: Fri, 16 Jan 2009 08:36:16 +1300 >=20 > Eric, >=20 > (cross-post to lisp dropped) >=20 > On 2009-01-16 07:42, Fleischman, Eric wrote: > ... > > 8) When RLOC-EID is done properly (e.g., like HIP where each concept > > appears on a different layer of the protocol stack), there is no > > liveness problem (nor can there be one). Rather, the "liveness problem" > > described in draft-meyer-loc-id-implications-00.txt is a generic problem > > of map-and-encaps systems, not of RLOC-EID. The title and text of > > draft-meyer-loc-id-implications-00.txt is therefore inappropriately > > scoped as being caused by RLOC-EID when it is rather a common attribute > > of map-and-encaps. Note that LISP is a map-and-encaps system. >=20 > I've said from day one that LISP's use of the term 'EID' is incorrect, > and it should be replaced by something like 'local locator' or > 'level 0 locator' or some such. So a more positive spin on your > subject line is 'Liveness requirement in multi-locator architectures'. > Which is of course something that has been discovered many times > and is very widely implemented in robust distributed systems. >=20 > Another positive spin is 'Mapping requirement in ID/Loc split concept'. >=20 > Brian > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg ----- End forwarded message ----- --h31gzZEtNLTqOjlF 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) iEYEARECAAYFAklvrVMACgkQORgD1qCZ2KesfACffXbaYKUHiDEnR54yZKXu/qVj ViEAn2qkujVn/XVcN0DvTSLumw9zzOPr =eBoa -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- --===============1869684331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1869684331==-- From lisp-bounces@ietf.org Thu Jan 15 13:41:07 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE2B28C108; Thu, 15 Jan 2009 13:41:07 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DCA28C114 for ; Thu, 15 Jan 2009 13:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 8vNoYEqrZWYp for ; Thu, 15 Jan 2009 13:41:05 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 3A9143A6783 for ; Thu, 15 Jan 2009 13:41:05 -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 n0FLeiAB024724; Thu, 15 Jan 2009 13:40:44 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0FLeiHQ024723; Thu, 15 Jan 2009 13:40:44 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 15 Jan 2009 13:40:44 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090115214044.GB24689@1-4-5.net> MIME-Version: 1.0 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] [swb@employees.org: Re: [rrg] No liveness requirement in the ID/Loc Split concept] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0668622861==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0668622861== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="24zk1gE8NUlDmwG9" Content-Disposition: inline --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from Scott Brim ----- > From: Scott Brim > To: Brian E Carpenter > Cc: rrg@irtf.org > Subject: Re: [rrg] No liveness requirement in the ID/Loc Split concept > Date: Thu, 15 Jan 2009 14:46:15 -0500 > Mail-Followup-To: Scott Brim , > Brian E Carpenter , > "Fleischman, Eric" , rrg@irtf.org >=20 > Excerpts from Brian E Carpenter on Fri, Jan 16, 2009 08:36:16AM +1300: > > On 2009-01-16 07:42, Fleischman, Eric wrote: ... > > > 8) When RLOC-EID is done properly (e.g., like HIP where each > > > concept appears on a different layer of the protocol stack), there > > > is no liveness problem (nor can there be one). Rather, the > > > "liveness problem" described in > > > draft-meyer-loc-id-implications-00.txt is a generic problem of > > > map-and-encaps systems, not of RLOC-EID. The title and text of > > > draft-meyer-loc-id-implications-00.txt is therefore > > > inappropriately scoped as being caused by RLOC-EID when it is > > > rather a common attribute of map-and-encaps. Note that LISP is a > > > map-and-encaps system. > >=20 > > I've said from day one that LISP's use of the term 'EID' is > > incorrect, and it should be replaced by something like 'local > > locator' or 'level 0 locator' or some such. So a more positive spin > > on your subject line is 'Liveness requirement in multi-locator > > architectures'. Which is of course something that has been > > discovered many times and is very widely implemented in robust > > distributed systems. >=20 > Identifier/locator separation makes the problem possible, and it can > make it possible at any point in the network. At any point we can > have a separation of=20 >=20 > - a name the packets are trying to get to > - a name for a point in the network via which they can be delivered >=20 > and the problems are similar in all cases, whether you use > "identifier" and "locator" to name the things or not. >=20 > > Another positive spin is 'Mapping requirement in ID/Loc split > > concept'. >=20 > Mapping is just part of the problem. You can map to all possible > paths, but you have to establish a session in the face of all the > choices, and track and recover from failures. >=20 > Scott > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg ----- End forwarded message ----- --24zk1gE8NUlDmwG9 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) iEYEARECAAYFAklvrVwACgkQORgD1qCZ2KcosQCfcPPF691MYWE1lq/Vtv2fvzqo G7AAn1/6JCOXli1Zjo84wBRwwQ0FhjJl =FGLD -----END PGP SIGNATURE----- --24zk1gE8NUlDmwG9-- --===============0668622861== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0668622861==-- From lisp-bounces@ietf.org Thu Jan 15 20:11:41 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B081D3A688A; Thu, 15 Jan 2009 20:11:41 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F122A3A68C7 for ; Thu, 15 Jan 2009 20:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.322, 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 XPNt0ojAoB98 for ; Thu, 15 Jan 2009 20:11:38 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 09CFB3A688A for ; Thu, 15 Jan 2009 20:11:37 -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 C3867175EC2; Fri, 16 Jan 2009 14:54:02 +1100 (EST) Message-ID: <49700462.9020605@firstpr.com.au> Date: Fri, 16 Jan 2009 14:52:02 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> <20090115193205.GA49353@cisco.com> <474EEBD229DF754FB83D256004D021080AEBC96B@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D021080AEBC96B@XCH-NW-6V1.nw.nos.boeing.com> Cc: Pekka Nikander , rrg@irtf.org, lisp@ietf.org Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org I am responding to Eric Fleishman and Scott Brim, regarding: http://tools.ietf.org/html/draft-meyer-loc-id-implications-00 My previous RRG message explains the following taxonomy: Elimination (genuine, host-based, ID/Loc split): HIP, Six/One, SHIM6 and ILNP. Separation (network based ITRs and ETRs using a mapping system - with no host involvement in multihoming. Arguably not a true ID/Loc Split arrangement): Map-Encap: LISP, APT, TRRP and Ivip using encapsulation. Map-Forward: Ivip's two Forwarding modes. (Modified IP headers and DFZ routers.) Map-Rewrite: Six/One Router. Eric wrote: > the "liveness problem" described in > draft-meyer-loc-id-implications-00.txt is a generic problem > of map-and-encaps systems, not of RLOC-EID. The title and text of > draft-meyer-loc-id-implications-00.txt is therefore inappropriately > scoped as being caused by RLOC-EID when it is rather a common > attribute of map-and-encaps. Note that LISP is a map-and-encaps > system. I disagree that the objectionable scaling problems which are the main concern in the "locator liveness problem" are inherent in map-encap systems. Ivip in both its map-encap and its (modified IP header) forwarding modes does not have this scaling problem because the ITRs are not responsible for deciding which LOC address to tunnel the traffic packets to. In Ivip, the mapping information for each micronet (roughly equivalent to a LISP EID prefix) consists of a single LOC address - the address of the ETR by which the destination network can currently be reached. The destination multihomed end-user network is responsible for probing the reachability of their network via its two or more ETRs - and for changing the mapping of their micronets in real-time so that when the current ETR becomes unreachable, all ITRs will use another ETR address instead. Therefore, there is no scaling problem with thousands or hundreds of thousands or whatever ITRs all simultaneously trying to test reachability to the two or ETRs of this destination multihomed end-user network. The formal definition of the problem from the I-D is: Given a set of source locators and a set of destination locators, can bidirectional connectivity be determined between the address pairs? (Strictly speaking, it is not necessarily to determine a single path for bidirectional communication. For instance, it is OK for packets to flow like this, if the connectivity permits: CEA -> ITR1 -> ETR3 -> CEB CEA <- ETR2 <- ITR4 <- CEB ) Here is a diagram relevant to Core-Edge Separation schemes, depicting two hosts, in separate multihomed end-user networks NA and NB, each with two upstream ISPs: ~~~~~~~~~~~ NA ISP1 ~ ~ ISP3 NB PE1 BR1--- ---BR3 PE3 ........ / ITR1 ~\ /~ ITR3 \ ........ . . / ETR1 ~ \ / ~ ETR3 \ . . . HA---CEA ~ DFZ ~ CEB---HB . . . \ ~ / \ ~ / . . ........ \ ISP2 ~/ \~ ISP4 / ........ PE2 BR2--- ---BR4 PE4 ITR2 ~ ~ ITR4 ETR2 ~~~~~~~~~~~ ETR4 (Fig 1) If the packet flow is NA --> NB, then CEA could send the packet to either upstream ISP. So for LISP etc. (not Ivip) either of both ITR1 and ITR2 need to continually check reachability to both ETR3 and ETR4 - or rather that firstly whether ETR3 and ETR4 can be reached and secondly, that each ETR can reach the Customer Edge router of NB: CEB. In practice, if CEA only sends packets addressed to HB out via the ISP1 link then ITR2 never sees them, does not get mapping for HB's EID prefix, and does not have to keep checking reachability to the ETR addresses (LOCs) listed in the mapping. Ivip's real-time mapping gives all the involved ITRs (ITR1 and/or ITR2 in the above HA -> HB example) the information they need to be able to tunnel packets to an ETR by which HB can be reached. So Ivip ITRs do no reachability checking. Neither LISP etc. nor Ivip solve the problem of telling CEA which upstream link to send packets from. The CEA router needs to do its own reachability testing to its two upstream ISPs, and ideally would also determine whether each ISP was functioning in terms of forwarding packets correctly to all destinations. The real "locator liveness" problem is a scaling problem. It occurs in LISP etc. when there are host in thousands or hundreds of thousands of networks such as NA sending packets to NB. Since each such sending host network will have one, two or more ITRs, the scaling problem is the vast number of ITRs which need to be continually probing reachability to both ETR3 and ETR4. Ivip has no such problem because, irrespective of how many ITRs are sending packets to the micronet in which HB is located, the reachability testing is done by whatever purpose-built system the NB uses. The most likely arrangement is for NB to contract the services of a company which specialises in this reachability testing, from multiple locations in the DFZ. The typical arrangement would be for NB to give that company the credentials it needs to change the mapping of NB's micronets in order to spread incoming load over NB's upstream links, and to restore connectivity if an ISP or a link to and ISP, fails. This way, the mapping is changed quickly without any reliance on NB's network being reachable at all. Of course, NB could use one or more such reachability testing companies and use the results in its own servers to make the final mapping decisions. Placing those servers in its own network would be tricky, since they need to function reliably at times of partial network failure. It would be better to rely on the distributed, highly robust, purpose built system of a company which specialises in reachability testing. Scott wrote: > It's clear that pure endpoint-based multipathing, =E0 la Shim6 REAP, > cannot scale. Yes, for SHIM6, HIP, ILNP or whatever elimination scheme it is, the problem is likely to be worse than depicted above using ITRs and ETRs. With the above example, there could be 100 hosts in NA sending packets to one or more hosts in NB, and there would be no extra burden of probing traffic etc. - since the same number of ITRs (ITR1 and/or ITR2) are involved. With HIP, or any other host-based Elimination scheme, the diagram looks like this: ~~~~~~~~~~~ NA ISP1 ~ ~ ISP3 NB PE1 BR1--- ---BR3 PE3 ........ / ~\ /~ \ ........ . . / ~ \ / ~ \ . . . HA---CEA ~ DFZ ~ CEB---HB . . . \ ~ / \ ~ / . . ........ \ ISP2 ~/ \~ ISP4 / ........ PE2 BR2--- ---BR4 PE4 ~ ~ ~~~~~~~~~~~ HA's addresses: HB's addresses: wwww (from ISP1) yyyy (from ISP3) xxxx (from ISP2) zzzz (from ISP4) (Fig 2) HA needs to probe reachability in these paths: wwww -> yyyy (presumably, with confirmation packets coming back via xxxx <- yyyy) wwww -> zzzz (ditto wwww <- zzzz) xxxx -> yyyy (ditto xxxx <- yyyy) xxxx -> zzzz (ditto xxxx <- zzzz) This exact situation is comparable to that depicted in Fig 1. The number of probes is roughly the same and the burden they place on the DFZ is about the same. The probing is more thorough, because it tests complete host-to-host reachability, thereby picking up any problems between each host and its CE router - which are not picked up in LISP etc. or typically by the systems which would be used by Ivip. There are at least two reasons why the "locator liveness" problem is worse for HIP, ILNP etc. (any host-based Elimination scheme) compared to LISP etc. (any Separation scheme in which the mapping lists multiple ETR addresses and requires each ITR to test reachability to them): 1 - The probe traffic goes all the way to and from the hosts. This is a major burden on any host on an expensive, slow and/or congested link - as is typically the case with any physically mobile device using one or more wireless links. 2 - There is an additional scaling factor in comparison to Fig 1 when there are multiple hosts in each end-user network. For LISP etc. those additional hosts do not cause any burden on the probing effort. For HIP etc. the load multiplied directly with the number of hosts. Point 1 is one of the aspects of my critique: Fundamental objections to a host-based scalable routing solution http://www.irtf.org/pipermail/rrg/2008-November/000233.html and HIP, with all its cryptography, host-to-host handshaking before any user traffic can proceed etc. exemplifies my other critiques about delaying communications and burdening all hosts with excessive protocol and computational complexity. Point 2, I think, is what Scott is referring to regarding REAP not scaling. > Putting path failure detection and recovery in ITRs instead of in > the endpoints can greatly reduce the number of messages flying > around, Yes, as illustrated above, for multiple sending hosts in one end-user network. > but a simple approach there doesn't scale either, Yes: LISP, APT, TRRP and Six/One Router - or any scheme where the ITRs are given non-real-time mapping and so need to continually find out for themselves, independently, which ETRs are reachable. > and without information they don't have much choice. Ivip gives the ITRs the information in real-time - so the ITR has no such choices to make. > One thing we could do is to couple them. The endpoint could > periodically tell "the network" what it needs, so the network only > needs to do just enough. More and more complexity . . . > Another thing we can do is cut back on our requirements, at least > for a while. I don't see how, other than by making LISP into something less robust than it is intended to be. No-one would want to invest in a system which provides multihoming "sometimes". Scott also criticised HIP's reliance on rendezvous servers to cope with the messy situation of both hosts trying to retain consistent communications at the HIT level when their underlying LOC addresses are in flux, as will often be the case in the future as more and more mobile devices are used. > rendezvous servers may be required, tsk "tsk" seems rather reserved. How about: More and more complexity and management traffic . . . Arrrggg!!!! - Robin _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 16 08:03:57 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7B43A6943; Fri, 16 Jan 2009 08:03:57 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02CF28C294; Thu, 15 Jan 2009 10:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUzwxX5tdq59; Thu, 15 Jan 2009 10:42:42 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id A81DA28C278; Thu, 15 Jan 2009 10:42:42 -0800 (PST) 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 n0FIgEi1001873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Jan 2009 12:42:14 -0600 (CST) 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 n0FIgEU9000698; Thu, 15 Jan 2009 12:42:14 -0600 (CST) 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 n0FIgBCE000572; Thu, 15 Jan 2009 12:42:14 -0600 (CST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 10:42:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jan 2009 10:42:12 -0800 Message-ID: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: No liveness requirement in the ID/Loc Split concept Thread-Index: Acl3QPrVUmF2Ehb1QAOVLgoB8peYCQ== From: "Fleischman, Eric" To: X-OriginalArrivalTime: 15 Jan 2009 18:42:13.0377 (UTC) FILETIME=[FB41B710:01C97740] X-Mailman-Approved-At: Fri, 16 Jan 2009 08:03:57 -0800 Cc: rrg@irtf.org Subject: [lisp] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Coworkers, In response to the draft-meyer-loc-id-implications-00.txt I-D, I sent private observations to the authors of that I-D together with a small subset of interested parties. Somebody (Dave Meyer??) requested that this private dialog should rather be moved to this email list for participation of the larger community. Towards that end, I would like to summarize the view from my knothole about the RLOC/EID split issue to this list: 1) Routing systems using RLOCs naturally reference RLOCs for routing aggregation. Every network system that I have worked with except for IP (e.g., OSI, SNA, BSC, XNS, etc.) instead does routing on EIDs. These latter systems do not recognize RLOCs. 2) In historic IP, IP addresses became semantically overloaded with both RLOC and EID semantics. I surmise that the IP designers originally thought they were doing EIDs like every other protocol then existing but they actually invented RLOCs, without recognizing the implications of the difference. Regardless, both semantic concepts became located within the IP layer. In practice this meant that EIDs were not operative for IP routing at all: EID is usually NULL for traditional IP routing; EID primarily semantically appears for protocols operating above the IP layer, causing cross-layer protocol dependencies in such systems. 3) IP combined the RLOC and EID concepts into a single system that lacked the ability to disambiguate between them. Consequently, some systems (e.g., routing) presumed that they were talking with an RLOC and other systems presumed that they were talking with an EID. The IP system didn't provide any assurance that either reference or presumption was actually the case (e.g., anycast). This became known as the "IP identity problem", which is a fundamental and pervasive security flaw within IP systems that is solved by the RLOC/EID split concept (e.g., HIP). Within historic IP we either locate something without identifying it or else we identify it without locating it. This provides the foundation for "Rekhter's Law". That we cannot authoritatively know which reference is operative provides the foundation for the "IP identity problem". 4) Multihoming is an EID concept. EID-based routing systems naturally and transparently support multihoming. RLOC-based routing systems cannot naturally support multihoming because they lack the information to be able to naturally recognize the occurrence of multihoming. 5) In RLOC/EID separation systems like HIP, the RLOC and EID each occurs on different layers of the protocol stack. Therefore, attempting to get IP routing, which works on the IP layer (i.e., RLOC layer) to be aware of multi-homing, which occurs on the EID layer (i.e., the session layer within HIP), is a protocol layer violation. 6) IP routing is not equipped to natively be able to do multi-homing and attempts to enhance it to do so further complicate the RLOC-EID confusion and actively harm the Internet. Attempting to enhance routers to handle multi-homing inherently violates the loc/ID split concept. The desired distinction between EID and RLOC needlessly becomes replaced by mutual dependencies between the two concepts. By adding EID dependencies to RLOC, there cannot be "better aggregation in the RLOC space" because no RLOC space can exist. Rather, that space potentially becomes EID*RLOC space, which probably represents significantly worse aggregation than the historic IP routing system. 7) The RLOC-EID split concept therefore means that multihoming needs to be solved at a layer above the IP layer that can naturally see the EID. Attempts to simultaneously achieve a Loc/Id split and have routing doing multihoming are vectors that internally war with each other. The net result are the types of problems identified in draft-meyer-loc-id-implications-00.txt, problems that cannot occur if the RLOC-EID distinction is done properly (i.e., RLOC and EID at different layers of the protocol stack). 8) When RLOC-EID is done properly (e.g., like HIP where each concept appears on a different layer of the protocol stack), there is no liveness problem (nor can there be one). Rather, the "liveness problem" described in draft-meyer-loc-id-implications-00.txt is a generic problem of map-and-encaps systems, not of RLOC-EID. The title and text of draft-meyer-loc-id-implications-00.txt is therefore inappropriately scoped as being caused by RLOC-EID when it is rather a common attribute of map-and-encaps. Note that LISP is a map-and-encaps system. 9) It is useful to discuss both map-and-encaps and multihoming from the insights contained within Fred Templin's VET/RANGER/SEAL I-D trilogy. This trilogy discusses scalable map-and-encaps systems and indicates how to resolve the liveness problem for those systems. It also provides an important context for describing multihoming because it identifies the recursive nature of the "enterprise" concept. Without leveraging the insights of this trilogy, multihoming may appear to mean different things in different contexts: Autonomous systems can be multihomed. Mobile platforms can be multihomed. Hosts can be multihomed. Etc. These different environments are recursive instances to different sized "enterprise" entities. Failing to realize this complicates discussions about multi-homing. --Eric _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 16 08:03:57 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98F328C25C; Fri, 16 Jan 2009 08:03:57 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579363A6823; Thu, 15 Jan 2009 10:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.118 X-Spam-Level: X-Spam-Status: No, score=-6.118 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiPevTw0QMWF; Thu, 15 Jan 2009 10:48:41 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 3DB093A6774; Thu, 15 Jan 2009 10:48:41 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n0FImHl4028153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 10:48:21 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n0FImHsd013430; Thu, 15 Jan 2009 10:48:17 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n0FImF5Z013349; Thu, 15 Jan 2009 10:48:17 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 10:48:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jan 2009 10:48:15 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1056E76B6@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] No liveness requirement in the ID/Loc Split concept Thread-Index: Acl3QPrVUmF2Ehb1QAOVLgoB8peYCQAAGgBg References: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> From: "Templin, Fred L" To: "Fleischman, Eric" , X-OriginalArrivalTime: 15 Jan 2009 18:48:16.0488 (UTC) FILETIME=[D3B00E80:01C97741] X-Mailman-Approved-At: Fri, 16 Jan 2009 08:03:57 -0800 Cc: rrg@irtf.org Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Eric, >-----Original Message----- >From: Fleischman, Eric >Sent: Thursday, January 15, 2009 10:42 AM >To: lisp@ietf.org >Cc: rrg@irtf.org >Subject: [rrg] No liveness requirement in the ID/Loc Split concept > >Coworkers, > >In response to the draft-meyer-loc-id-implications-00.txt I-D, I sent >private observations to the authors of that I-D together with a small >subset of interested parties. Somebody (Dave Meyer??) requested that >this private dialog should rather be moved to this email list for >participation of the larger community. Towards that end, I would like to >summarize the view from my knothole about the RLOC/EID split issue to >this list: > >1) Routing systems using RLOCs naturally reference RLOCs for routing >aggregation. Every network system that I have worked with except for IP >(e.g., OSI, SNA, BSC, XNS, etc.) instead does routing on EIDs. These >latter systems do not recognize RLOCs. > >2) In historic IP, IP addresses became semantically overloaded with both >RLOC and EID semantics. I surmise that the IP designers originally >thought they were doing EIDs like every other protocol then existing but >they actually invented RLOCs, without recognizing the implications of >the difference. Regardless, both semantic concepts became located within >the IP layer. In practice this meant that EIDs were not operative for IP >routing at all: EID is usually NULL for traditional IP routing; EID >primarily semantically appears for protocols operating above the IP >layer, causing cross-layer protocol dependencies in such systems. > >3) IP combined the RLOC and EID concepts into a single system that >lacked the ability to disambiguate between them. Consequently, some >systems (e.g., routing) presumed that they were talking with an RLOC and >other systems presumed that they were talking with an EID. The IP system >didn't provide any assurance that either reference or presumption was >actually the case (e.g., anycast). This became known as the "IP identity >problem", which is a fundamental and pervasive security flaw within IP >systems that is solved by the RLOC/EID split concept (e.g., HIP). Within >historic IP we either locate something without identifying it or else we >identify it without locating it. This provides the foundation for >"Rekhter's Law". That we cannot authoritatively know which reference is >operative provides the foundation for the "IP identity problem". > >4) Multihoming is an EID concept. EID-based routing systems naturally >and transparently support multihoming. RLOC-based routing systems cannot >naturally support multihoming because they lack the information to be >able to naturally recognize the occurrence of multihoming. > >5) In RLOC/EID separation systems like HIP, the RLOC and EID each occurs >on different layers of the protocol stack. Therefore, attempting to get >IP routing, which works on the IP layer (i.e., RLOC layer) to be aware >of multi-homing, which occurs on the EID layer (i.e., the session layer >within HIP), is a protocol layer violation. > >6) IP routing is not equipped to natively be able to do multi-homing and >attempts to enhance it to do so further complicate the RLOC-EID >confusion and actively harm the Internet. Attempting to enhance routers >to handle multi-homing inherently violates the loc/ID split concept. The >desired distinction between EID and RLOC needlessly becomes replaced by >mutual dependencies between the two concepts. By adding EID dependencies >to RLOC, there cannot be "better aggregation in the RLOC space" because >no RLOC space can exist. Rather, that space potentially becomes EID*RLOC >space, which probably represents significantly worse aggregation than >the historic IP routing system. > >7) The RLOC-EID split concept therefore means that multihoming needs to >be solved at a layer above the IP layer that can naturally see the EID. >Attempts to simultaneously achieve a Loc/Id split and have routing doing >multihoming are vectors that internally war with each other. The net >result are the types of problems identified in >draft-meyer-loc-id-implications-00.txt, problems that cannot occur if >the RLOC-EID distinction is done properly (i.e., RLOC and EID at >different layers of the protocol stack). > >8) When RLOC-EID is done properly (e.g., like HIP where each concept >appears on a different layer of the protocol stack), there is no >liveness problem (nor can there be one). Rather, the "liveness problem" >described in draft-meyer-loc-id-implications-00.txt is a generic problem >of map-and-encaps systems, not of RLOC-EID. The title and text of >draft-meyer-loc-id-implications-00.txt is therefore inappropriately >scoped as being caused by RLOC-EID when it is rather a common attribute >of map-and-encaps. Note that LISP is a map-and-encaps system. > >9) It is useful to discuss both map-and-encaps and multihoming from the >insights contained within Fred Templin's VET/RANGER/SEAL I-D trilogy. >This trilogy discusses scalable map-and-encaps systems and indicates how >to resolve the liveness problem for those systems. It also provides an >important context for describing multihoming because it identifies the >recursive nature of the "enterprise" concept. Without leveraging the >insights of this trilogy, multihoming may appear to mean different >things in different contexts: Autonomous systems can be multihomed. >Mobile platforms can be multihomed. Hosts can be multihomed. Etc. These >different environments are recursive instances to different sized >"enterprise" entities. Failing to realize this complicates discussions >about multi-homing. FWIW, this is completely consistent with the latest version of VET that I have just posted: http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-27.txt but I think you will find that the new version is much more comprehensive in terms of PI addressing, site multi-homing, ingress filtering, routing scaling suppression, MTU robustness, locator liveness determination, etc. etc.) Thanks - Fred fred.l.templin@boeing.com > >--Eric > > >_______________________________________________ >rrg mailing list >rrg@irtf.org >http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 16 08:03:57 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E643428C268; Fri, 16 Jan 2009 08:03:57 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A823A6A7E for ; Thu, 15 Jan 2009 13:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 tSlWODwxlZrO for ; Thu, 15 Jan 2009 13:20:18 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 259103A6A5D for ; Thu, 15 Jan 2009 13:20:18 -0800 (PST) Received: from r190-135-12-111.dialup.adsl.anteldata.net.uy (unknown [163.117.203.90])by smtp01.uc3m.es (Postfix) with ESMTP id 0F222B47B1F; Thu, 15 Jan 2009 22:19:29 +0100 (CET) Message-ID: <496FA860.6060409@it.uc3m.es> Date: Thu, 15 Jan 2009 22:19:28 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Scott Brim , Pekka Nikander , "Fleischman, Eric" , rrg@irtf.org, lisp@ietf.org References: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boei ng.com> <20090115193205.GA49353@cisco.com> <9C72DD31-8EF8-484D-90F7-81BDBB5 A28D2@nomadiclab.com> <20090115211038.GJ41383@cisco.com> In-Reply-To: <20090115211038.GJ41383@cisco.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-15.2475 TC:1F TRN:66 TV:5.5.1026(16404.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Mailman-Approved-At: Fri, 16 Jan 2009 08:03:57 -0800 Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Scott Brim escribi=F3: > Excerpts from Pekka Nikander on Thu, Jan 15, 2009 10:37:16PM +0200: > = >>> It's clear that pure endpoint-based multipathing, a la Shim6 REAP, >>> cannot scale. >>> = >> Would you please be more specific. It is not at all clear to me. >> AFAIK, SCTP is doing essentially the same thing. (I can see the >> signalling load there, causing potential packet storms; is that the >> "scalability" problem you are referring to?) >> = > > I should have done the math first but ... Let's assume, > conservatively, on the order of ten billion communicating endpoint > pairs and 2 locators per endpoint. How often do you test locator > pairs that you are not using? = what do you mean by a "locator pairs that you are not using"? You mean a locator pair that is not the one that is the current locator = pair, or do you mean the current locator pair, but that you don't have = data packets to send in this moment? regards, marcelo > Let's be very conservative and assume > once per minute (endpoints can get away with this low level). Even > so, that's an extra 2^10 packets per minute across the core ... when > things are going perfectly, just for steady state maintenance. > I > can't characterize what percentage of traffic that is, because, for > example, there may be plenty of HTTP sessions that are idle but being > kept open. We could reduce that maintenance overhead. Then we add in > what happens when there is a network problem. I suspect that because > there are active sessions and data is flowing, you would try all > alternative paths at once, with fast probes and duplicate data > packets. I really don't know what would happen, but I'm awed at the > thought. > > = >>> Putting path failure detection and recovery in ITRs instead of in >>> the endpoints can greatly reduce the number of messages flying >>> around, but a simple approach there doesn't scale either, and >>> without information they don't have much choice. >>> = >> AFAICS, the fundamental problem here is that the network today (BGP) >> cannot detect failures at the desired speed, leading to the >> situation where the hosts (or your funnel points) need to overcome >> the deficiency. >> = > > Suppose I am at locators A and B, you are talking to me at locator A > and A becomes unreachable. Regardless of how fast routing detects > that, you (an endpoint) are going to need to detect it yourself, > verify that B is reachable, and switch to B, so you need your own > fault detection and recovery protocol. > > = >>>> 8) When RLOC-EID is done properly (e.g., like HIP where each >>>> concept appears on a different layer of the protocol stack), there >>>> is no liveness problem (nor can there be one). >>>> = >>> I don't see it. HIP properly removes dependency on location-based >>> names from identification functions, but it does nothing to solve >>> the multipath problem. You still need to find viable paths, >>> ascertain that multiple locators refer to the same entity >>> (difficult when one or both are moving -- rendezvous servers may be >>> required, tsk), detect path failure and switch to another one. >>> = >> I mostly agree. In the HIP WG, years ago the decision was to leave >> the problem of path failure detection to the SHIM6 WG, with the >> intention to integrate REAP to HIP. However, with HIP (even LHIP) >> verifying that the locators refer to the same entity is relatively >> easy, as long as at least one of the parties retains at least one >> stable locator. Rendezvous servers are a nice way to introduce >> stable locator to an otherwise dynamic system... And then, under >> those assumptions, finding paths and switching over is relatively >> easy. Works very well in practise. We've multiple times tested it >> with both proxies and individual hosts, using 2-3 different radio >> interfaces at each mobile host/proxy, and moving at typical vehicle >> speeds in difficult terrain. But I digress. >> = > > That's not a digression, that's real evidence :-). My concern is not > that "finding paths and switching over is relatively easy", but what > happens when everyone does it. > > Scott > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > > = _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 16 08:03:57 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA0328C271; Fri, 16 Jan 2009 08:03:57 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84713A67AB; Thu, 15 Jan 2009 13:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 AGJl1miH2vQg; Thu, 15 Jan 2009 13:36:23 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 12EF13A6783; Thu, 15 Jan 2009 13:36:23 -0800 (PST) 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 n0FLZuxv007355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 13:35:58 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n0FLZuUB021869; Thu, 15 Jan 2009 13:35:56 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n0FLZo5L021620; Thu, 15 Jan 2009 13:35:56 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 13:35:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jan 2009 13:35:54 -0800 Message-ID: <474EEBD229DF754FB83D256004D021080AEBC805@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <20090115193205.GA49353@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] No liveness requirement in the ID/Loc Split concept Thread-Index: Acl3R/edsjtEHhWmThePy7KEy+cClgACX9+w References: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> <20090115193205.GA49353@cisco.com> From: "Fleischman, Eric" To: "Scott Brim" X-OriginalArrivalTime: 15 Jan 2009 21:35:55.0896 (UTC) FILETIME=[3F8FE780:01C97759] X-Mailman-Approved-At: Fri, 16 Jan 2009 08:03:57 -0800 Cc: rrg@irtf.org, lisp@ietf.org Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Scott, >>Eric Fleischman wrote: >> appears on a different layer of the protocol stack), there is no >> liveness problem (nor can there be one). Rather, the "liveness problem" >> described in draft-meyer-loc-id-implications-00.txt is a generic >> problem of map-and-encaps systems, not of RLOC-EID. The title and text >> of draft-meyer-loc-id-implications-00.txt is therefore inappropriately >> scoped as being caused by RLOC-EID when it is rather a common >> attribute of map-and-encaps. Note that LISP is a map-and-encaps system. >Scott Brim wrote: >I don't see it. HIP properly removes dependency on location-based >names from identification functions, but it does nothing to solve >the multipath problem. You still need to find viable paths, ascertain >that multiple locators refer to the same entity (difficult when one or >both are moving -- rendezvous servers may be required, tsk), detect path >failure and switch to another one. The same is true for Shim6, or >Trilogy multipathing ... or anything where you have the chance of using >multiple paths. A simple host in a simple PI-based AS can't, and therefore >doesn't have a problem to solve. Adding HIP in fact makes the problem possible. Thank you for sharing your insights. Concerning this specific insight, I believe that what RLOC-EID split systems like HIP primarily do is to disambiguate the semantic confusion so that routing (i.e., RLOC) issues are local to the IP layer and EID concepts are local to the HIP session layer. I fully concur with you that the IP (routing) layer is responsible to find viable paths between RLOCs, which can be challenging in the highly mobile environments in which I primarily focus. Our research has demonstrated that a key benefit of HIP in highly mobile environments is that the HIP session layer provides a buffer that shields the transport and application layers from network effects such as multihoming and mobility. Our experiments have demonstrated session persistence even within highly unstable network environments caused by substantial MANET mobility. We have demonstrated that HIP session layers simply need not care about underlying IP layer issues such as whether the underlying network is using IPv4 or IPv6. We've demonstrated HIP sessions that cleanly and transparently persisted through real-time underlying network swaps from IPv4 to IPv6 and back. In our private discussions I observed that because routing can only see RLOCs and therefore can't discern the existence of multihoming, multihoming needs to be handled at a layer that has visibility into EIDs where it can be seen. I received strong push-back on that private list to my suggestion that multihoming should be an optional service function of the session layer, perhaps using an optional timer value in the session layer to substitute a different RLOC source ID value in the underlying local IP layer if the current RLOC hasn't received any traffic in a given time quantum. I am comfortable receiving push-back on my suggestion in the previous paragraph because this idea of mine hasn't been adequately examined. What I am not comfortable with is any approach that attempts to solve multi-homing at the IP layer because I believe that routing should solely aggregate and forward packets based on RLOCs -- anything else needlessly complicates routing and harms Internet performance and scaling. Therefore, multihoming is not a function of the IP layer. I realize that this belief of mine conflicts with IETF work and thought (e.g., the domain discussed by draft-meyer-loc-id-implications-00.txt), but this nevertheless is how I see things. --Eric _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 16 08:03:58 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B3428C277; Fri, 16 Jan 2009 08:03:58 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E857728C108 for ; Thu, 15 Jan 2009 13:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.315 X-Spam-Level: X-Spam-Status: No, score=-5.315 tagged_above=-999 required=5 tests=[AWL=1.284, 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 k7ElUydXXGhD for ; Thu, 15 Jan 2009 13:46:18 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id AA89528C0F8 for ; Thu, 15 Jan 2009 13:46:18 -0800 (PST) Received: from r190-135-12-111.dialup.adsl.anteldata.net.uy (unknown [163.117.203.90]) by smtp03.uc3m.es (Postfix) with ESMTP id BCAD1731748; Thu, 15 Jan 2009 22:37:31 +0100 (CET) Message-ID: <496FAC99.4020602@it.uc3m.es> Date: Thu, 15 Jan 2009 22:37:29 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Scott Brim , marcelo bagnulo braun , Pekka Nikander , "Fleischman, Eric" , rrg@irtf.org, lisp@ietf.org References: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> <20090115193205.GA49353@cisco.com> <9C72DD31-8EF8-484D-90F7-81BDBB5A28D2@nomadiclab.com> <20090115211038.GJ41383@cisco.com> <496FA860.6060409@it.uc3m.es> <20090115212431.GA52863@cisco.com> In-Reply-To: <20090115212431.GA52863@cisco.com> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16404.002 X-Mailman-Approved-At: Fri, 16 Jan 2009 08:03:57 -0800 Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Scott Brim escribi=F3: > Excerpts from marcelo bagnulo braun on Thu, Jan 15, 2009 10:19:28PM +0100: > = >> Scott Brim escribi=F3: >> = >>> Excerpts from Pekka Nikander on Thu, Jan 15, 2009 10:37:16PM +0200: >>> = >>> = >>>>> It's clear that pure endpoint-based multipathing, a la Shim6 REAP, >>>>> cannot scale. >>>>> = >>>>> = >>>> Would you please be more specific. It is not at all clear to me. >>>> AFAIK, SCTP is doing essentially the same thing. (I can see the >>>> signalling load there, causing potential packet storms; is that the >>>> "scalability" problem you are referring to?) >>>> = >>>> = >>> I should have done the math first but ... Let's assume, >>> conservatively, on the order of ten billion communicating endpoint >>> pairs and 2 locators per endpoint. How often do you test locator >>> pairs that you are not using? = >>> = >> what do you mean by a "locator pairs that you are not using"? >> >> You mean a locator pair that is not the one that is the current locator = >> pair, or do you mean the current locator pair, but that you don't have = >> data packets to send in this moment? >> regards, marcelo >> = > > If one end has locators A and B, and the other end has C and D ... > then unless you are multipathing you will use a single pair, e.g. A-C, > while A-D and B-C are not being used, just checked for liveness in > case a need arises. > > > = That's not how REAP works REAP does not probes for liveness of unused paths AFAICT Regards, marcelo _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 16 08:03:58 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E77128C27B; Fri, 16 Jan 2009 08:03:58 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C761C28C156; Thu, 15 Jan 2009 15:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 aIKSZukJr9qq; Thu, 15 Jan 2009 15:46:39 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id C7EE63A6405; Thu, 15 Jan 2009 15:46:39 -0800 (PST) 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 n0FNk9Wx011101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Jan 2009 17:46:19 -0600 (CST) 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 n0FNk93G018474; Thu, 15 Jan 2009 17:46:09 -0600 (CST) 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 n0FNk3Cc018327; Thu, 15 Jan 2009 17:46:08 -0600 (CST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 15:46:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jan 2009 15:46:03 -0800 Message-ID: <474EEBD229DF754FB83D256004D021080AEBC96B@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] No liveness requirement in the ID/Loc Split concept Thread-Index: Acl3R/edsjtEHhWmThePy7KEy+cClgACX9+wAASBkaA= References: <474EEBD229DF754FB83D256004D021080AE7ACF9@XCH-NW-6V1.nw.nos.boeing.com> <20090115193205.GA49353@cisco.com> From: "Fleischman, Eric" To: X-OriginalArrivalTime: 15 Jan 2009 23:46:06.0691 (UTC) FILETIME=[6F28A330:01C9776B] X-Mailman-Approved-At: Fri, 16 Jan 2009 08:03:57 -0800 Cc: rrg@irtf.org Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org >From: Fleischman, Eric >In our private discussions I observed that because routing can >only see RLOCs and therefore can't discern the existence of >multihoming, multihoming needs to be handled at a layer that has >visibility into EIDs where it can be seen. I received strong push-back >on that private list to my suggestion that multihoming should be an >optional service function of the session layer, perhaps using an >optional timer value in the session layer to substitute a different >RLOC source ID value in the underlying local IP layer if the current >RLOC hasn't received any traffic in a given time quantum. >I am comfortable receiving push-back on my suggestion in the previous >paragraph because this idea of mine hasn't been adequately examined. >What I am not comfortable with is any approach that attempts to solve >multi-homing at the IP layer because I believe that routing should >solely aggregate and forward packets based on RLOCs -- anything else >needlessly complicates routing and harms Internet performance and >scaling. Therefore, multihoming is not a function of the IP layer. I >realize that this belief of mine conflicts with IETF work and thought >(e.g., the domain discussed by draft-meyer-loc-id-implications-00.txt), >but this nevertheless is how I see things. Scott Brim and I had a private discussion concerning the impact of HIP on RLOC-EID liveness. As part of that discussion, he recommended that I forward to the list my following additional opinion concerning the above first paragraph: My suggestion in my first paragraph above was a possible extension to HIP or other EID-RLOC separation systems. HIP doesn't do liveness now in the base HIP specs. However, the HIP community is currently considering eventually possibly adopting two different liveness alternatives: using SIP's ICE for NAT traversal and SHIM6's REAP for multihoming -- I believe these proposed approaches are unacceptably resource consumptive, which is why I made the above suggestion. Regardless, HIP doesn't do either today but it currently does protect the transport layer and above from having to care about multihoming or network issues. Specifically, the session doesn't care what RLOC is used to support that session at the IP layer -- any packet duplications will be handled at the transport or application layer. It's simply not a problem. My previous suggestion (above) was how to respond to the liveness problem for HIP should the current network path fail in multihoming environments. Currently, if the routing layer doesn't have a live path to an RLOC supporting that EID, then the session is not receiving packets. If the network layer is not aware of an alternative RLOC (which is what I expect to be the norm), then it can't use that alternative remote multihomed RLOC unless it is redirected to it by a mechanism that is unrelated to routing tables (i.e., routers should only deal with RLOCs). My original paragraph above suggested a way to alert the remote peer to the existence of another RLOC supporting that EID so that it could try that alternative path. This presumes a non-symmetric routing blockage (i.e., not due to a blockage affecting all of a peer's transmissions regardless). Regardless, I believe that the id/loc split concept presumes that the session layer needs to handle multihoming and the IP layer need to handle routing between RLOCs. The two concepts (RLOC, EID) need to remain separated without becoming confused by needless dependencies. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 16 09:22:50 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B25D3A69DF; Fri, 16 Jan 2009 09:22:50 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C1D3A6907 for ; Fri, 16 Jan 2009 09:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 eihDWW1HjzOd for ; Fri, 16 Jan 2009 09:22:48 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 03EAD28C13E for ; Fri, 16 Jan 2009 09:22:47 -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 n0GHMQ4X019186; Fri, 16 Jan 2009 09:22:26 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0GHMQkq019185; Fri, 16 Jan 2009 09:22:26 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 16 Jan 2009 09:22:26 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090116172226.GA19152@1-4-5.net> MIME-Version: 1.0 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] FYI -- Noel on "names" [jnc@mercury.lcs.mit.edu: Re: [rrg] No liveness requirement in the ID/Loc Split concept] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0717082748==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0717082748== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from Noel Chiappa ----- > From: Noel Chiappa > To: rrg@irtf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [rrg] No liveness requirement in the ID/Loc Split concept > Date: Fri, 16 Jan 2009 00:46:47 -0500 (EST) >=20 > > From: Brian E Carpenter >=20 > > I've said from day one that LISP's use of the term 'EID' is incorre= ct, > > and it should be replaced by something like 'local locator' or 'lev= el 0 > > locator' or some such.=20 >=20 > Sorry, but it's _not_ a locator, and more an 'endpoint identifier' than > anything else - at least, as far as the original definitions of those ter= ms > go. >=20 > (And might I remind people that the term "locator" came from Nimrod, and = "EID" > from you-know-where. So excuse me if I get a little cranky with people tr= ying > to tell me whether or not they are applicable to something, when I am > perfectly darned happy with their use in that context.) >=20 > The thing that people seem to be forgetting, in making this claim, is that > it's also important _what kind of thing_ is being named, not just _the > attributes of the name itself_. Those are two orthagonal axes, and people > still don't seem to be clearly understanding/remembering that most concept > terms being thrown around here, such as locator, EID, etc, generally invo= lves > a _set_ of choices, one on each axis. >=20 > There seems to be a tendency to think 'locator' means 'name with topologi= cal > significance', and that's _not_ what it was defined as - it meant '_inter= face > name_ with topological significance'. (Actually, it was defined to be > 'interface name with topological significance which does not appear in all > packets', since people seemed terminally unable to wrap their minds aroun= d the > concept of an 'address' that didn't appear in all packets.) Similarly, an > 'EID' is an '_endpoint_ identifier without topological significance', not= just > 'name with no topological significance'. >=20 > We don't really have a generally-accepted term for 'endpoint name with > topological significance'; 'address' has some of that flavour, but in > e.g. IPv4 it also 'sort of' names an interface. >=20 >=20 > With all this in hand, it's clear that a LISP EID does _not_ name an > interface, but rather a 'stack' - i.e. an endpoint, with a collection of = TCP > connections. So to say that it's a 'locator' is wholly incorrect - it is > _exactly_ an 'endpoint name', as that term was formally defined. >=20 > There is no one-word description/term which _exactly_ describes a LISP EI= D; > it's a bit of a kludge (precisely because of installed base issues). To be > maximally precise, a LISP 'EID' is 'a globally-unique endpoint name with > topological significance within a local scope only'. >=20 > Noel > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg ----- End forwarded message ----- --HlL+5n6rz5pIUxbD 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) iEYEARECAAYFAklwwlIACgkQORgD1qCZ2KdEfQCfeuzH6d1y/jqbGt1p7fY9uI+i KikAmgPkWsulKozEZpKOITPoFXmkgE86 =v5F4 -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- --===============0717082748== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0717082748==-- From lisp-bounces@ietf.org Fri Jan 16 09:23:18 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C35F3A69F2; Fri, 16 Jan 2009 09:23:18 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96FBC3A69DF for ; Fri, 16 Jan 2009 09:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 tADBUz1r9yzG for ; Fri, 16 Jan 2009 09:23:15 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 73E883A6907 for ; Fri, 16 Jan 2009 09:23:15 -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 n0GHN0j2019204 for ; Fri, 16 Jan 2009 09:23:00 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0GHN02b019203 for lisp@ietf.org; Fri, 16 Jan 2009 09:23:00 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 16 Jan 2009 09:23:00 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090116172300.GB19152@1-4-5.net> References: <20090116054647.626B56BE594@mercury.lcs.mit.edu> <39C363776A4E8C4A94691D2BD9D1C9A1056E7C04@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1056E7C04@XCH-NW-7V2.nw.nos.boeing.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: [lisp] Fred Templin's response to Noel [Re: [rrg] No liveness requirement in the ID/Loc Split concept] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0886870625==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0886870625== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 16, 2009 at 09:16:11AM -0800, Templin, Fred L wrote: > Hi Noel, >=20 > >-----Original Message----- > >From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > >Sent: Thursday, January 15, 2009 9:47 PM > >To: rrg@irtf.org > >Cc: jnc@mercury.lcs.mit.edu > >Subject: Re: [rrg] No liveness requirement in the ID/Loc Split concept > > > > > > > From: Brian E Carpenter > > > > > I've said from day one that LISP's use of the term 'EID' is > incorrect, > > > and it should be replaced by something like 'local locator' or > 'level 0 > > > locator' or some such. > > > >Sorry, but it's _not_ a locator, and more an 'endpoint identifier' than > >anything else - at least, as far as the original definitions of those > terms > >go. > > > >(And might I remind people that the term "locator" came from Nimrod, > and "EID" > >from you-know-where. So excuse me if I get a little cranky with people > trying > >to tell me whether or not they are applicable to something, when I am > >perfectly darned happy with their use in that context.) > > > >The thing that people seem to be forgetting, in making this claim, is > that > >it's also important _what kind of thing_ is being named, not just _the > >attributes of the name itself_. Those are two orthagonal axes, and > people > >still don't seem to be clearly understanding/remembering that most > concept > >terms being thrown around here, such as locator, EID, etc, generally > involves > >a _set_ of choices, one on each axis. > > > >There seems to be a tendency to think 'locator' means 'name with > topological > >significance', and that's _not_ what it was defined as - it meant > '_interface > >name_ with topological significance'. (Actually, it was defined to be > >'interface name with topological significance which does not appear in > all > >packets', since people seemed terminally unable to wrap their minds > around the > >concept of an 'address' that didn't appear in all packets.) Similarly, > an > >'EID' is an '_endpoint_ identifier without topological significance', > not just > >'name with no topological significance'. > > > >We don't really have a generally-accepted term for 'endpoint name with > >topological significance'; 'address' has some of that flavour, but in > >e.g. IPv4 it also 'sort of' names an interface. > > > > > >With all this in hand, it's clear that a LISP EID does _not_ name an > >interface, but rather a 'stack' - i.e. an endpoint, with a collection > of TCP > >connections. >=20 > I think that depends on where you assign the EID (using "EID" > and "RLOC" in the LISP sense of the words for the purpose of > this message). If you assign the EID to an interface used > for forwarding packets to the outside world (e.g., an interface > attached to an ethernet link, a tunnel virtual interface, etc.) > then it names the interface in the traditional sense. If you > instead assign the EID to an internal virtual interface (e.g., > a loopback interface), then in some sense it could be > considered as naming the stack. But... >=20 > > So to say that it's a 'locator' is wholly incorrect - it is > >_exactly_ an 'endpoint name', as that term was formally defined. >=20 > ...it is still a routing locator at least within a limited scope. >=20 > LISP RLOCs are routing locators within the interdomain region, > and LISP EIDs appear in mapping tables within the interdomain > region. However, the EIDs are still routing locators within > edge networks even if the "edge network" consists of a > singleton end system. >=20 > IMHO, there is no escaping the fact that LISP EIDs are still > IP addresses that name interfaces, even though we have these > "special" interfaces like loopbacks that can in some sense > be considered as a "handle" for naming a stack. >=20 > HIP HITs on the other hand are true endpoint identifiers > that name end systems only, and cannot be used as routing > locators in any scope. >=20 > Fred > fred.l.templin@boeing.com > =20 > >There is no one-word description/term which _exactly_ describes a LISP > EID; > >it's a bit of a kludge (precisely because of installed base issues). To > be > >maximally precise, a LISP 'EID' is 'a globally-unique endpoint name > with > >topological significance within a local scope only'. > > > > Noel > >_______________________________________________ > >rrg mailing list > >rrg@irtf.org > >http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg --cmJC7u66zC7hs+87 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) iEYEARECAAYFAklwwnQACgkQORgD1qCZ2Kfg0gCfX+BEdm7DK9B81ghsycKWikTO 95EAoIPbvF2jMggQKnemeeJomNJmzJvd =oCqE -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- --===============0886870625== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0886870625==-- From lisp-bounces@ietf.org Fri Jan 16 09:32:52 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433CF28C2A4; Fri, 16 Jan 2009 09:32:52 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B827828C2A3 for ; Fri, 16 Jan 2009 09:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.593 X-Spam-Level: X-Spam-Status: No, score=-4.593 tagged_above=-999 required=5 tests=[AWL=-1.994, 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 iFUt7A711j72 for ; Fri, 16 Jan 2009 09:32:50 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id D11D328C2A1 for ; Fri, 16 Jan 2009 09:32:50 -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 n0GHWZcL019845 for ; Fri, 16 Jan 2009 09:32:35 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0GHWZ8Y019844 for lisp@ietf.org; Fri, 16 Jan 2009 09:32:35 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Resent-From: dmm@1-4-5.net Resent-Date: Fri, 16 Jan 2009 09:32:35 -0800 Resent-Message-ID: <20090116173235.GA19806@1-4-5.net> Resent-To: lisp@ietf.org Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0GHQx6C019416; Fri, 16 Jan 2009 09:27:19 -0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B029C3A69F2; Fri, 16 Jan 2009 09:27:08 -0800 (PST) X-Original-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916BE28C277 for ; Fri, 16 Jan 2009 09:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 bqz0G1A2UskY for ; Fri, 16 Jan 2009 09:27:06 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 9E12228C257 for ; Fri, 16 Jan 2009 09:27:06 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 489456BE5B7; Fri, 16 Jan 2009 12:26:48 -0500 (EST) To: rrg@irtf.org Message-Id: <20090116172648.489456BE5B7@mercury.lcs.mit.edu> Date: Fri, 16 Jan 2009 12:26:48 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list MIME-Version: 1.0 Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [rrg] No liveness requirement in the ID/Loc Split concept X-BeenThere: lisp@ietf.org List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > From: jnc@mercury.lcs.mit.edu (Noel Chiappa) > a LISP EID does _not_ name an interface, but rather a 'stack' - i.e. an > endpoint, with a collection of TCP connections. A private reply pointed out that a LISP EID in fact _also_ names an interface, just like an IPv4 address. That's a consequence of the fact that a LISP design goal was to allow unmodified hosts, so one can only change the semantics of existing namespaces a little. Interesting historical note: the Nimrod deployment plan: http://ana-3.lcs.mit.edu/~jnc/nimrod/deploy.txt looked a lot like LISP's deployment plan - the existing IP layer was 'jacked up' and a new layer inserted underneath; unmodified hosts were unaware that this all was happening, and continued to emit and receive classic IPv4 packet; Nimrod agent-routers were responsible for invisibly translating the IPv4 'addresses' in those packets into Nimrod locators, and doing the encapsulation. Although the Nimrod deployment plan spoke of turning IPv4 'addresses' into endpoint names (EIDs, to be exact - ironically), it's clear that there, IPv4 addresses also retained minimal interface naming semantics. It's almost inevitable, in any plan which supports unmodified hosts, that the IPvN addresses used by those hosts will retain the basic semantics of IPvN addresses. Noel _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 16 09:44:29 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9277728C273; Fri, 16 Jan 2009 09:44:29 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A2328C13E for ; Fri, 16 Jan 2009 09:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.206, 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 9HAXTmv8sjO3 for ; Fri, 16 Jan 2009 09:44:28 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id D915228C273 for ; Fri, 16 Jan 2009 09:44:27 -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 n0GHiC0M021022 for ; Fri, 16 Jan 2009 09:44:12 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0GHiCGh021021 for lisp@ietf.org; Fri, 16 Jan 2009 09:44:12 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 16 Jan 2009 09:44:12 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090116174412.GA20971@1-4-5.net> MIME-Version: 1.0 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 charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============0751657784==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0751657784== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable We're looking at doing a WG forming BOF at the next IETF meeting, and the below is a draft of what such a WG charter would look like.=20 Comments please. Thnx, Dave LISP (Locator/ID Separation Protocol) Last Modified: 2009-01-16 Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Secretary(ies): TBD =20 Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: LISP and companion documents (see below) are proposals that respond to the problems discussed at the IAB's October, 2006 Routing and Addressing Workshop [0]. The purpose of the BOF is to form a working group whose charter (see below) is to work on the design on the LISP base protocol [1], the LISP+ALT mapping system [2], LISP Interworking [4] and LISP multicast [6]. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. 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. Mar 2010 Re-charter or close. Internet-Drafts: draft-farinacci-lisp-11.txt draft-farinacci-lisp-multicast-00.txt draft-fuller-lisp-alt-03.txt draft-lewis-lisp-interworking-02.txt Request For Comments: None References ---------- [0] Meyer, D. et. al., "Report from the IAB Workshop on Routing and Addressing", RFC 4984. [1] Farinacci, D. et. al., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-11.txt. [2] Fuller, V., et. al., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-03.txt [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-01.txt. [4] Lewis, D., et. al., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-02.txt. [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt. [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-00.txt. =20 --ZPt4rx8FFjLCG7dd 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) iEYEARECAAYFAklwx2wACgkQORgD1qCZ2KdmGgCcChKy3aMn8CKGHGAAz7zxRwwV JDUAnj87/H3YRN8NcbkM0kCubtnYTulV =RlUh -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- --===============0751657784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0751657784==-- From lisp-bounces@ietf.org Fri Jan 16 09:49:11 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB9F928C2A7; Fri, 16 Jan 2009 09:49:11 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD7D28C2A4 for ; Fri, 16 Jan 2009 09:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 0q89-Q49-LbJ for ; Fri, 16 Jan 2009 09:49:09 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 6E25628C2A7 for ; Fri, 16 Jan 2009 09:49:09 -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 n0GHmsfe021914 for ; Fri, 16 Jan 2009 09:48:54 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0GHmsrQ021913 for lisp@ietf.org; Fri, 16 Jan 2009 09:48:54 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 16 Jan 2009 09:48:54 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090116174854.GA21892@1-4-5.net> MIME-Version: 1.0 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] another interesting comment from Noel on naming... 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: , Content-Type: multipart/mixed; boundary="===============1107671333==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1107671333== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from Noel Chiappa ----- > From: Noel Chiappa > To: rrg@irtf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [rrg] No liveness requirement in the ID/Loc Split concept > Date: Fri, 16 Jan 2009 12:26:48 -0500 (EST) >=20 > > From: jnc@mercury.lcs.mit.edu (Noel Chiappa) >=20 > > a LISP EID does _not_ name an interface, but rather a 'stack' - i.e= =2E an > > endpoint, with a collection of TCP connections. >=20 > A private reply pointed out that a LISP EID in fact _also_ names an > interface, just like an IPv4 address. That's a consequence of the fact th= at a > LISP design goal was to allow unmodified hosts, so one can only change the > semantics of existing namespaces a little. >=20 >=20 > Interesting historical note: the Nimrod deployment plan: >=20 > http://ana-3.lcs.mit.edu/~jnc/nimrod/deploy.txt >=20 > looked a lot like LISP's deployment plan - the existing IP layer was 'jac= ked > up' and a new layer inserted underneath; unmodified hosts were unaware th= at > this all was happening, and continued to emit and receive classic IPv4 > packet; Nimrod agent-routers were responsible for invisibly translating t= he > IPv4 'addresses' in those packets into Nimrod locators, and doing the > encapsulation. Although the Nimrod deployment plan spoke of turning IPv4 > 'addresses' into endpoint names (EIDs, to be exact - ironically), it's cl= ear > that there, IPv4 addresses also retained minimal interface naming semanti= cs. >=20 >=20 > It's almost inevitable, in any plan which supports unmodified hosts, that > the IPvN addresses used by those hosts will retain the basic semantics of > IPvN addresses. >=20 > Noel > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg ----- End forwarded message ----- --IJpNTDwzlM2Ie8A6 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) iEYEARECAAYFAklwyIYACgkQORgD1qCZ2Kc9XwCfUXic50Klj7m1lqPUfx3SeYHA caEAnRMhTbcdtlB2GnM4UVOY1Aa1jVGP =776r -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- --===============1107671333== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1107671333==-- From lisp-bounces@ietf.org Fri Jan 16 13:17:59 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD2228C0EA; Fri, 16 Jan 2009 13:17:59 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676C428C0EA for ; Fri, 16 Jan 2009 13:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=-0.217, 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 dY3Bg9rZoUhF for ; Fri, 16 Jan 2009 13:17:57 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3287028B56A for ; Fri, 16 Jan 2009 13:17:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,278,1231113600"; d="scan'208";a="34062730" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Jan 2009 21:17:41 +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 n0GLHfOq032034; Fri, 16 Jan 2009 16:17:41 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0GLHfGo015801; Fri, 16 Jan 2009 21:17:41 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 16:17:41 -0500 Received: from cisco.com ([10.86.240.176]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jan 2009 16:17:40 -0500 Date: Fri, 16 Jan 2009 16:17:31 -0500 From: Scott Brim To: David Meyer Message-ID: <20090116211731.GA83278@cisco.com> References: <20090116174412.GA20971@1-4-5.net> MIME-Version: 1.0 In-Reply-To: <20090116174412.GA20971@1-4-5.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 16 Jan 2009 21:17:40.0789 (UTC) FILETIME=[DD3D9650:01C9781F] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: lisp@ietf.org Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============0010851805==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0010851805== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dave. Multicast is listed as a draft to work on but is not in the milestonesm, even though all the others are. Excerpts from David Meyer on Fri, Jan 16, 2009 09:44:12AM -0800: > We're looking at doing a WG forming BOF at the next IETF > meeting, and the below is a draft of what such a WG > charter would look like.=20 >=20 > Comments please. >=20 > Thnx, >=20 > Dave >=20 >=20 > LISP (Locator/ID Separation Protocol) >=20 > Last Modified: 2009-01-16 >=20 > Chair(s): > TBD >=20 > Internet Area Director(s): > TBD >=20 > Routing Area Advisor: > TBD >=20 > Secretary(ies): > TBD > =20 > Mailing Lists: > General Discussion: lisp@ietf.org >=20 > Description of Working Group: >=20 > LISP and companion documents (see below) are proposals that > respond to the problems discussed at the IAB's October, 2006 > Routing and Addressing Workshop [0]. The purpose of the BOF is to > form a working group whose charter (see below) is to work on the > design on the LISP base protocol [1], the LISP+ALT mapping system > [2], LISP Interworking [4] and LISP multicast [6]. The working > group will encourage and support interoperable LISP > implementations as well as defining requirements for alternate > mapping systems. >=20 > Goals and Milestones: >=20 > Mar 2010 Submit base LISP specification to the IESG for > Experimental. >=20 > Mar 2010 Submit base ALT specification to the IESG for > Experimental. >=20 > Mar 2010 Submit the LISP Interworking specification to the IESG > for Experimental. >=20 > Mar 2010 Re-charter or close. >=20 > Internet-Drafts: > draft-farinacci-lisp-11.txt > draft-farinacci-lisp-multicast-00.txt > draft-fuller-lisp-alt-03.txt > draft-lewis-lisp-interworking-02.txt >=20 > Request For Comments: > None >=20 >=20 > References > ---------- > [0] Meyer, D. et. al., "Report from the IAB Workshop on > Routing and Addressing", RFC 4984. >=20 > [1] Farinacci, D. et. al., "Locator/ID Separation Protocol > (LISP)", draft-farinacci-lisp-11.txt. >=20 > [2] Fuller, V., et. al., "LISP Alternative Topology > (LISP-ALT)", draft-fuller-lisp-alt-03.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. >=20 > [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, > "LISP for Multicast Environments", > draft-farinacci-lisp-multicast-00.txt. =20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAklw+WsACgkQF0TR2hENFARmXwCfXk1NFc2/9AcPFmBX09OBzG2g ygYAnjRd0tp8O9bBC+YqMZHGp0JHZGOp =XbV7 -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- --===============0010851805== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0010851805==-- From lisp-bounces@ietf.org Sat Jan 17 02:43:39 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21AA3A6802; Sat, 17 Jan 2009 02:43:39 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC8F3A6802 for ; Sat, 17 Jan 2009 02:43:38 -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 lnl9+ROt1cxw for ; Sat, 17 Jan 2009 02:43:37 -0800 (PST) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 8F8143A67B2 for ; Sat, 17 Jan 2009 02:43:37 -0800 (PST) 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=AUnVFF0Zi1Ml2amHbYwVKhG352k=; b=Ri9GJDcyFl p4LEeKm4SZxoCdaZhp8VNB2LBYfaEnYodlNiYX4fy7i7alTcFPx7CftIdw5nrird qydH0obOiN+XbkBF3E7S1+HTmmtCT0bs55HoHhUfN03ProdH71RsebtT5IJJ9I4v NTyygpiAfG6zCcrJDMc9TpOEPsY8FE7Y0= 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=CFqY0 VZhVp9gclBJ+WTnt3bTUzSdSfmOY6uDJvXAy4yffvlQm92Xhay/aM2y1eFgcUwtq zWxOkm2EwDZopGZnU7At+1r4mJU71R7PIo16UaqjUBnzsXKXwTyb2LxtWVGlRjkI aNe8UN3+T0Y4nprP/HS7hm8o0EjFqVls+QxYXM= Received: from mbpobo.local (ip-83-134-217-129.dsl.scarlet.be [83.134.217.129]) (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; Sat, 17 Jan 2009 11:43:15 +0100 (CET) Message-ID: <4971B641.20503@uclouvain.be> Date: Sat, 17 Jan 2009 11:43:13 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: David Meyer References: <20090116174412.GA20971@1-4-5.net> In-Reply-To: <20090116174412.GA20971@1-4-5.net> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: ADA43EDDC3.55EEA 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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dave, > 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. Although ALT is the first deployed mapping proposal, I don't think that a LISP working group should only consider this approach. I think that the WG should work on Mapping systems in general and ALT could be one of the solutions, but I would not restrict this in the description. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sun Jan 18 03:12:48 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852F83A68E3; Sun, 18 Jan 2009 03:12:48 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D3428C0D8 for ; Sun, 18 Jan 2009 03:12:48 -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=[AWL=0.000, 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 7SZ4ncFu4Bee for ; Sun, 18 Jan 2009 03:12:47 -0800 (PST) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 0F3E83A6839 for ; Sun, 18 Jan 2009 03:12:46 -0800 (PST) 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= pmsOFdCxUggbL9ZHEO1hMAD0s9Y=; b=LsPMUHBPYl2ECWNPc76H7k8euOcEXGcV ELX87ucxMKt6jmcJC0EC3RQNn5U7Vi8O2tmTpvbLO0fLa+l5WBuYpfDsC2VPkyyu bfEfiE8xEjiw0JiUZCtAB/aPGmoBWDMOzpuZHnwLl4Cc3D8A1QXLbNeBBCwxkQJD au8wxc71GeI= 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=coc6Rc9WZ9NbCT6BLa /KHnhPOyW0Cx1X5vZkrwNEBer+V0fSBSempl4cz8sCyYtJqH34dtYxk/9y2JhRGa GwFtJZXmYPzpyZ6AbBJJ4OTkGr9ofKIeNkzDGwCwbSSR5HPUbQqO9Bw+lGqcDI2M R3+7lXqVmBTAZIFU5Bvqgas+s= Received: from mbpobo.local (ip-83-134-194-224.dsl.scarlet.be [83.134.194.224]) (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 ; Sun, 18 Jan 2009 12:12:26 +0100 (CET) Message-ID: <49730E98.1030101@uclouvain.be> Date: Sun, 18 Jan 2009 12:12:24 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: lisp@ietf.org X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: D30F9EB42B.24054 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: [lisp] Locator liveness problem 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Hello, draft-meyer-loc-id-implications-00 discusses the locator liveness problem and several possible solutions. I think that there are several related issues that need to be discussed : 1- What are the types of failures that we consider and want to be able to detect : a. Failure of an ETR b. Failure of (one of the link) directly attached to an ETR to its provider c. Failure or misconfiguration of some intermediate links that causes some ETR to become unreachable from some ITRs although the ETR and its links are up. Failures of type C are the more general, but also the most complex to handle. There has been some work on detecting such failures/misconfigurations ( see e.g. A. Dhamdhere, R. Teixeira, C. Dovrolis, and C. Diot - "NetDiagnoser:Troubleshooting network unreachabilities using end-to-end probes and routing data", in Proc. of CoNEXT, December 2007 ) , but I don't think that we could reliably detect them in a LISP world. I would suggest to focus the discussion on failures of type A and type B. 2- The focus of LISP should be to forward packets despite of failures of an ETR or failures of a link that is attached to an ETR and not to detect failures. I think that we should also consider network design best practices and fast reroute techniques that could allow the EIDs served by the ETR to remain reachable although an ETR or a link failed. First, if a set of EID prefixes is served only by a single-homed ETR, then the failure of the ETR or of the link that attaches the ETR to its provider will cause a failure of the EID. Such a failure will be eventually detected by ICMP destination unreachable messages. This is the same case as today when a router attached to a single subnet which is part of a larger aggregate fails. In this case, BGP does not inform the entire Internet about the failure as the aggregate remains reachable. Second, we should consider dual-homed ETRs. There are two subcases : a- Two ETRs attached to the same provider b- Two ETRs attached to different providers In subcase a, the two ETRs could be configured in anycast so that the provider redirects the packets to the other ETR in case of failure of one ETR or one of its links. In subcase b, a cooperation among the two providers could ensure that the two RLOCs remain reachable even if one of the links or one of the ETR fails. A possible solution to this problem could be based on the BGP fast reroute technique described in http://inl.info.ucl.ac.be/publications/achieving-sub-50-milliseconds-recove-0 but other solutions are possible as well I think that we should explore the utilisation of such network design and fast reroute techniques to ensure that LISP encapsulated packets are delivered even in case of failures instead of discussing the detection of the failures themselves. If we cannot find enough network design and fast reroute techniques, then we'll have to define ways to detect failures. Best regards, Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sun Jan 18 12:26:03 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3A83A6B4D; Sun, 18 Jan 2009 12:26:03 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9693A6951 for ; Sun, 18 Jan 2009 12:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 4JvCCyLg2yyd for ; Sun, 18 Jan 2009 12:26:01 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id F2B043A6877 for ; Sun, 18 Jan 2009 12:26:00 -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 n0IKPjMp025821; Sun, 18 Jan 2009 12:25:45 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0IKPguO025820; Sun, 18 Jan 2009 12:25:42 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sun, 18 Jan 2009 12:25:42 -0800 From: David Meyer To: Olivier Bonaventure Message-ID: <20090118202542.GA25786@1-4-5.net> References: <20090116174412.GA20971@1-4-5.net> <4971B641.20503@uclouvain.be> MIME-Version: 1.0 In-Reply-To: <4971B641.20503@uclouvain.be> 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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============0325168648==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0325168648== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Oliver, > Although ALT is the first deployed mapping proposal, I don't think that > a LISP working group should only consider this approach. I think that > the WG should work on Mapping systems in general and ALT could be one of > the solutions, but I would not restrict this in the description. Well taken. I'll modify the text to reflect that. Dave --WIyZ46R2i8wDzkSu 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) iEYEARECAAYFAklzkEYACgkQORgD1qCZ2KeMEACfS3qT7ruViUKORjhrfrTxbbXd UIUAnRwd0ekBavjpfEStvt382lrxivnN =UnPA -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- --===============0325168648== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0325168648==-- From lisp-bounces@ietf.org Sun Jan 18 14:29:11 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE9228C101; Sun, 18 Jan 2009 14:29:11 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC8528C11A for ; Sun, 18 Jan 2009 14:29:10 -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 llmEz0kIrdok for ; Sun, 18 Jan 2009 14:29:09 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id CF0C728C0E4 for ; Sun, 18 Jan 2009 14:29:08 -0800 (PST) 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=KX64ujPe0gEfPUtTrPuioQeR8bU=; b=t6HLEQQUTr OkMk68AKOo6jOpXs+7aPL3jrX6yOL8VY9MAoXawztDghnByHNLNa/GuHpcTzitwt vBTkpX5LIY1lfpPX+WToZsDwAruYhawQmiojqKa9WiGo7qT90Ma/Olb0NIQ95z3d pzKf7sJf/fNvGTZ5xi0RaO/LhJ3/ztARI= 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=YhZpZ TY/Y09N6o/RXx9ZUjKfAFpwyhPl9qrGKOi/YmppazbL8ww9DeK3046yEUTgZFUB3 oIQSq8qEhNUEBXF1w1Bach8fw+AXMXYo++WZC6dRz1ML2W85hWLAAn9v2hPwGlga pr7jPPeEF7cHwzOKmUCuMC94/C5EfopCrZrBpo= Received: from mbpobo.local (ip-83-134-194-224.dsl.scarlet.be [83.134.194.224]) (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; Sun, 18 Jan 2009 23:28:57 +0100 (CET) Message-ID: <4973AD19.6020706@uclouvain.be> Date: Sun, 18 Jan 2009 23:28:41 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: David Meyer References: <20090116174412.GA20971@1-4-5.net> In-Reply-To: <20090116174412.GA20971@1-4-5.net> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 27FD1F18FA.B331C 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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dave, > We're looking at doing a WG forming BOF at the next IETF > meeting, and the below is a draft of what such a WG > charter would look like. Another point that should be discussed in a LISP WG is how locators and EIDs should be allocated. This is more a policy than a protocol issue, but I think that it will have an impact on the long-term scalablity of a solution such as LISP. Concerning the allocation of the EIDs, the issues to be discussed are at least the following : - size of an EID allocation - lifetime of an EID allocation Concerning the locators, an important requirement for the scalability of the underlying routing system is that it should be possible to allocate locators in a way that follows the network topology. In practice, this implies that locators will have a limited lifetime and that all xTR (and the supporting services including the mapping system) should be prepared for a change of their locator. Locator renumbering should be part of the standardised solution from day one. Otherwise, we'll be stuck in the same situation as with IPv6 today where renumbering is still not solved and network operators are changing the policies of the RIRs to ensure that they will not need to renumber. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sun Jan 18 20:11:12 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA9B3A676A; Sun, 18 Jan 2009 20:11:12 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF59B3A676A for ; Sun, 18 Jan 2009 20:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 hducBdYUwl-C for ; Sun, 18 Jan 2009 20:11:09 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 859903A6452 for ; Sun, 18 Jan 2009 20:11:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,286,1231113600"; d="scan'208";a="123624664" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 19 Jan 2009 04:10:54 +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 n0J4AsFY000880; Sun, 18 Jan 2009 20:10:54 -0800 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 n0J4AsCu018321; Mon, 19 Jan 2009 04:10:54 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, 18 Jan 2009 20:10:53 -0800 Received: from [192.168.1.4] ([10.21.86.199]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Jan 2009 20:10:53 -0800 Message-Id: <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <4973AD19.6020706@uclouvain.be> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 18 Jan 2009 20:10:52 -0800 References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 19 Jan 2009 04:10:53.0463 (UTC) FILETIME=[EBA6EA70:01C979EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1713; t=1232338254; x=1233202254; 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]=20draft=20charter=20for=20a=20LI SP=20BOF/WG=20--=20please=20comment |Sender:=20; bh=Vk7TT+dX/pAEkFU17ZZ1LTzcHKZ9VZ9tzkL4RULVZtA=; b=z1OlRb/IgrPR4wbexnwgc2eoPVHMezIfE/9eikOL/AB4INyrjRSLSpr65+ X4Td37giJyQ7+Pr3gvMBxWZqvnYsFgw3hpJZ3tRe1RyOqQhObFhGOOrfuTZJ eI+jwjgd6Z; 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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > Dave, >> We're looking at doing a WG forming BOF at the next IETF >> meeting, and the below is a draft of what such a WG >> charter would look like. > > Another point that should be discussed in a LISP WG is how locators > and > EIDs should be allocated. This is more a policy than a protocol issue, > but I think that it will have an impact on the long-term scalablity > of a > solution such as LISP. So, do you think the working group should have in it's charter to work on both protocols and operational practices? > Concerning the allocation of the EIDs, the issues to be discussed > are at > least the following : > - size of an EID allocation > - lifetime of an EID allocation > > Concerning the locators, an important requirement for the > scalability of > the underlying routing system is that it should be possible to > allocate > locators in a way that follows the network topology. In practice, this > implies that locators will have a limited lifetime and that all xTR > (and > the supporting services including the mapping system) should be > prepared > for a change of their locator. Locator renumbering should be part of > the standardised solution from day one. Otherwise, we'll be stuck in > the > same situation as with IPv6 today where renumbering is still not > solved > and network operators are changing the policies of the RIRs to ensure > that they will not need to renumber. Definitely agree. Dino > > > > > Olivier > > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium > _______________________________________________ > 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 lisp-bounces@ietf.org Mon Jan 19 00:04:02 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D48503A6A15; Mon, 19 Jan 2009 00:04:02 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF44028C0E2 for ; Mon, 19 Jan 2009 00:04:01 -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 P6vWgW4Ezb2T for ; Mon, 19 Jan 2009 00:04:00 -0800 (PST) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 6FB3F3A68BA for ; Mon, 19 Jan 2009 00:04:00 -0800 (PST) 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=oScE58/PFek35uT0WwWJzecBlSI=; b=dTm4jsyBOZ /o/mS7gKgQSwHaC3rQ4yZ/Or3TJX8pS62lO+Tg2tKpwyMVCmD8Le18UhG7nrD/sA AjX40noSvdTZOcM1l0hMIoRGd5bHEBozoJIfBizaV/wALgyVLd9wfYjCNtAkLo24 0HWL3tLSoNqVbGiDlxbcGtmVVQo5dxs8Y= 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=gdYWZ sXHfi6xG35YduvPQVoeuxsIDgxQrQIlw4pzyMMSAP09S75OpRrB3GfHJLaYbJBgy rTvNCAOzz/lBbNzdU7MeJvXEzptzHjmtQYVK2ESo47VQ3iOtefeer0oUiudFlexE xPIjYEFKjGXmPN79ZYSDYnYzNmD9owO55zmeow= Received: from mbpobo.dhcp.info.ucl.ac.be (unknown [130.104.228.96]) (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; Mon, 19 Jan 2009 09:03:40 +0100 (CET) Message-ID: <497433D8.30600@uclouvain.be> Date: Mon, 19 Jan 2009 09:03:36 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dino Farinacci References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> In-Reply-To: <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 5253CEDB77.94D10 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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dino, >>> We're looking at doing a WG forming BOF at the next IETF >>> meeting, and the below is a draft of what such a WG >>> charter would look like. >> >> Another point that should be discussed in a LISP WG is how locators and >> EIDs should be allocated. This is more a policy than a protocol issue, >> but I think that it will have an impact on the long-term scalablity of a >> solution such as LISP. > > So, do you think the working group should have in it's charter to work > on both protocols and operational practices? Usually, protocols and operational practices are decoupled as we need some time to learn from the actual deployment to document operationnal practices. However, in the case of LISP, if the objective is a set of Experimental RFCs, then having experimental operationnal practices that are documented would be useful. This might be done by asking IANA for a small reserved block of addresses to be used as EIDs for a limited time and the establishment of an experimental registry (e.g. within an existing RIR willing to experiment) to also evaluate this part of the solution. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 19 08:43:27 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0683A6A04; Mon, 19 Jan 2009 08:43:27 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9D53A698B for ; Mon, 19 Jan 2009 08:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 JlkUus8qWTic for ; Mon, 19 Jan 2009 08:43:26 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 4B7133A6918 for ; Mon, 19 Jan 2009 08:43:26 -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 n0JGh4cX014175; Mon, 19 Jan 2009 08:43:04 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0JGh2fN014174; Mon, 19 Jan 2009 08:43:02 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 19 Jan 2009 08:43:02 -0800 From: David Meyer To: Olivier Bonaventure Message-ID: <20090119164302.GA14152@1-4-5.net> References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> MIME-Version: 1.0 In-Reply-To: <4973AD19.6020706@uclouvain.be> 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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============1027202095==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1027202095== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 18, 2009 at 11:28:41PM +0100, Olivier Bonaventure wrote: > Dave, > > We're looking at doing a WG forming BOF at the next IETF > > meeting, and the below is a draft of what such a WG > > charter would look like.=20 >=20 > Another point that should be discussed in a LISP WG is how locators and > EIDs should be allocated. This is more a policy than a protocol issue, > but I think that it will have an impact on the long-term scalablity of a > solution such as LISP. >=20 > Concerning the allocation of the EIDs, the issues to be discussed are at > least the following : > - size of an EID allocation > - lifetime of an EID allocation >=20 > Concerning the locators, an important requirement for the scalability of > the underlying routing system is that it should be possible to allocate > locators in a way that follows the network topology. In practice, this > implies that locators will have a limited lifetime and that all xTR (and > the supporting services including the mapping system) should be prepared > for a change of their locator. Locator renumbering should be part of > the standardised solution from day one. Otherwise, we'll be stuck in the > same situation as with IPv6 today where renumbering is still not solved > and network operators are changing the policies of the RIRs to ensure > that they will not need to renumber. Agree. I'll also add that. Dave --W/nzBZO5zC0uMSeA 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) iEYEARECAAYFAkl0rZYACgkQORgD1qCZ2KetfACePrFHCeS99EHodxquVIEFIoLt /4QAnRHgcdHLQN7CtLlaQhtGtzU5tWwe =JP2i -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- --===============1027202095== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1027202095==-- From lisp-bounces@ietf.org Mon Jan 19 08:53:17 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C0CA3A69AC; Mon, 19 Jan 2009 08:53:17 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2CC03A6943 for ; Mon, 19 Jan 2009 08:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 XdG0NhAdMakC for ; Mon, 19 Jan 2009 08:53:14 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E305A3A69AC for ; Mon, 19 Jan 2009 08:53:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="34219092" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Jan 2009 16:52:55 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0JGqtBq010201; Mon, 19 Jan 2009 11:52:55 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0JGqtkv024278; Mon, 19 Jan 2009 16:52:55 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); Mon, 19 Jan 2009 11:52:55 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 11:52:54 -0500 Date: Mon, 19 Jan 2009 11:52:47 -0500 From: Scott Brim To: Olivier Bonaventure Message-ID: <20090119165247.GF85912@cisco.com> References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4973AD19.6020706@uclouvain.be> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 19 Jan 2009 16:52:54.0833 (UTC) FILETIME=[5FB65210:01C97A56] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: lisp@ietf.org Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Excerpts from Olivier Bonaventure on Sun, Jan 18, 2009 11:28:41PM +0100: > Concerning the locators, an important requirement for the > scalability of the underlying routing system is that it should be > possible to allocate locators in a way that follows the network > topology. In practice, this implies that locators will have a > limited lifetime and that all xTR (and the supporting services > including the mapping system) should be prepared for a change of > their locator. Locator renumbering should be part of the > standardised solution from day one. Otherwise, we'll be stuck in the > same situation as with IPv6 today where renumbering is still not > solved and network operators are changing the policies of the RIRs > to ensure that they will not need to renumber. When you say locators, I hope you mean the core-facing RLOCs. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 19 08:55:10 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B24E3A6B7F; Mon, 19 Jan 2009 08:55:10 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82ABF3A6B7F for ; Mon, 19 Jan 2009 08:55:09 -0800 (PST) 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 Rc2j+I-p-bsv for ; Mon, 19 Jan 2009 08:55:08 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id A21073A69AC for ; Mon, 19 Jan 2009 08:55:08 -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 n0JGsQRG014434; Mon, 19 Jan 2009 08:54:26 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0JGsQ9U014433; Mon, 19 Jan 2009 08:54:26 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 19 Jan 2009 08:54:26 -0800 From: David Meyer To: Olivier Bonaventure Message-ID: <20090119165426.GA14305@1-4-5.net> References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> <497433D8.30600@uclouvain.be> MIME-Version: 1.0 In-Reply-To: <497433D8.30600@uclouvain.be> 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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============0029533185==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0029533185== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Usually, protocols and operational practices are decoupled as we need > some time to learn from the actual deployment to document operationnal > practices. However, in the case of LISP, if the objective is a set of > Experimental RFCs, then having experimental operationnal practices that > are documented would be useful. This might be done by asking IANA for a > small reserved block of addresses to be used as EIDs for a limited time > and the establishment of an experimental registry (e.g. within an > existing RIR willing to experiment) to also evaluate this part of the > solution. As you may (or may not) know, we do have both IPv4 and IPv6 EID prefixes in use now (153.16/16 and 2610:D0:/32). It would be great if an RIR would pick up allocation of their part of the address space. The current model has RIPE, ARIN, LACNIC (actually UY) at the top of the aggregation hierarchy, and each has a /20 (from 153.16/16) and a /36 (2610:D0:/32). We're also working with folks at APNIC, and hope to have them going soon. So there is a kind of "square" at the top of the ALT hierarchy consisting of RIPE, ARIN, APNIC, and LACNIC.=20 So much of this is built (at least on the scale we could with a /16, for example). What you suggest that isn't done is that no RIR has picked up allocating this space. So I agree it would be a very good thing if one or more of the RIRs would pick up allocating these (that is exactly the kind of experience we'd like to get). That said, perhaps the charter should include a work item that looks something like "guidelines for allocating IPv4 and IPv6 EID prefixes" or something similar. What do folks think? Dave --fUYQa+Pmc3FrFX/N 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) iEYEARECAAYFAkl0sEIACgkQORgD1qCZ2KdVmwCeNaJ2UmWl7VoQ0V/GpptBmDQl CBsAn1xmo5CPCnp0lZHtB2rzaO2WXpZw =UMM/ -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- --===============0029533185== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0029533185==-- From lisp-bounces@ietf.org Mon Jan 19 08:55:14 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7F03A6AEE; Mon, 19 Jan 2009 08:55:14 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67A23A6AEE for ; Mon, 19 Jan 2009 08:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 mb0Ese+sfu6W for ; Mon, 19 Jan 2009 08:55:12 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E503B3A6B92 for ; Mon, 19 Jan 2009 08:55:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="34181539" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2009 16:54:55 +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 n0JGst1Z010933 for ; Mon, 19 Jan 2009 11:54:55 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0JGst1i028084 for ; Mon, 19 Jan 2009 16:54: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); Mon, 19 Jan 2009 11:54:55 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 11:54:54 -0500 Date: Mon, 19 Jan 2009 11:54:54 -0500 From: Scott Brim To: lisp@ietf.org Message-ID: <20090119165454.GG85912@cisco.com> References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> <497433D8.30600@uclouvain.be> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <497433D8.30600@uclouvain.be> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 19 Jan 2009 16:54:55.0003 (UTC) FILETIME=[A756CEB0:01C97A56] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Excerpts from Olivier Bonaventure on Mon, Jan 19, 2009 09:03:36AM +0100: > >> Another point that should be discussed in a LISP WG is how locators and > >> EIDs should be allocated. This is more a policy than a protocol issue, > >> but I think that it will have an impact on the long-term scalablity of a > >> solution such as LISP. > > > > So, do you think the working group should have in it's charter to work > > on both protocols and operational practices? > > Usually, protocols and operational practices are decoupled as we need > some time to learn from the actual deployment to document operationnal > practices. However, in the case of LISP, if the objective is a set of > Experimental RFCs, then having experimental operationnal practices that > are documented would be useful. This might be done by asking IANA for a > small reserved block of addresses to be used as EIDs for a limited time > and the establishment of an experimental registry (e.g. within an > existing RIR willing to experiment) to also evaluate this part of the > solution. I am hesitant to mix this all together. Of course we need an allocation scheme for the experiment to go forward, but that is not the same as deciding how things will be allocated in production. There is a lot of politics there. I would say that all we need is an existence proof that there is a way to allocate EIDs and RLOCs, but we don't need to come up with a recommendation on what the Internet / RIRs should do. I hope. Scott _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 19 08:59:00 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7713A6B96; Mon, 19 Jan 2009 08:59:00 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25573A6B8D for ; Mon, 19 Jan 2009 08:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 CRo6eCc4dRu1 for ; Mon, 19 Jan 2009 08:58:59 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 14EFC3A6B9B for ; Mon, 19 Jan 2009 08:58:59 -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 n0JGwgnT014491; Mon, 19 Jan 2009 08:58:42 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0JGwg9v014490; Mon, 19 Jan 2009 08:58:42 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 19 Jan 2009 08:58:42 -0800 From: David Meyer To: Scott Brim Message-ID: <20090119165842.GB14305@1-4-5.net> References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <20090119165247.GF85912@cisco.com> MIME-Version: 1.0 In-Reply-To: <20090119165247.GF85912@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: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============1306779452==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1306779452== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline --V0207lvV8h4k8FAm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable All, > > Concerning the locators, an important requirement for the > > scalability of the underlying routing system is that it should be > > possible to allocate locators in a way that follows the network > > topology. In practice, this implies that locators will have a > > limited lifetime and that all xTR (and the supporting services > > including the mapping system) should be prepared for a change of > > their locator. Locator renumbering should be part of the > > standardised solution from day one. Otherwise, we'll be stuck in the > > same situation as with IPv6 today where renumbering is still not > > solved and network operators are changing the policies of the RIRs > > to ensure that they will not need to renumber. >=20 > When you say locators, I hope you mean the core-facing RLOCs. =20 That is how I read it, and there are various proposals around for how to do this.=20 Do folks want to have an independent work item (i.e., draft) for this, or do you envision that xTR renumbering be folded into the base spec? Dave --V0207lvV8h4k8FAm 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) iEYEARECAAYFAkl0sUIACgkQORgD1qCZ2Kfd5ACfQhGOzGvjXKcqyVWqhTkdzOw/ 8sIAn0NwU3dYDmhqwB1oPFpfPyAm8cUX =EhS0 -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- --===============1306779452== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1306779452==-- From lisp-bounces@ietf.org Mon Jan 19 09:02:13 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B793A6904; Mon, 19 Jan 2009 09:02:13 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BAFE3A6904 for ; Mon, 19 Jan 2009 09:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_BIZOP=0.7] 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 kCqUw8x47PjE for ; Mon, 19 Jan 2009 09:02:10 -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 A76463A6805 for ; Mon, 19 Jan 2009 09:02:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="129625440" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 19 Jan 2009 17:01:55 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n0JH1sK4009322; Mon, 19 Jan 2009 09:01:54 -0800 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 n0JH1trP008878; Mon, 19 Jan 2009 17:01:55 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); Mon, 19 Jan 2009 09:01:54 -0800 Received: from [192.168.5.238] ([10.21.121.234]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 09:01:54 -0800 Message-Id: <5C6B1851-EA75-4265-AD93-4E101DC849DE@cisco.com> From: Dino Farinacci To: Scott Brim In-Reply-To: <20090119165454.GG85912@cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 19 Jan 2009 09:01:54 -0800 References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> <497433D8.30600@uclouvain.be> <20090119165454.GG85912@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 19 Jan 2009 17:01:54.0400 (UTC) FILETIME=[A151B600:01C97A57] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2601; t=1232384514; x=1233248514; c=relaxed/simple; s=sjdkim4002; 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]=20draft=20charter=20for=20a=20LI SP=20BOF/WG=20--=20please=20comment |Sender:=20; bh=SpnyHO3L8qfxdHhkQIEzh3IQ+e/AceppxAozGX7cobQ=; b=gFTwpZ3ds4c1/VKkAxqa92S0ZmnrFl9ohFfvRuPLGc/RIEHqgm5OkXvHs0 64Kbw2hJVVFg8f+iJdjC5g/gTI0m8SMAm8rPj4X1iVpc7/Q0+i0WGsKb+0ed kcuPSN8wco; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > Excerpts from Olivier Bonaventure on Mon, Jan 19, 2009 09:03:36AM > +0100: >>>> Another point that should be discussed in a LISP WG is how >>>> locators and >>>> EIDs should be allocated. This is more a policy than a protocol >>>> issue, >>>> but I think that it will have an impact on the long-term >>>> scalablity of a >>>> solution such as LISP. >>> >>> So, do you think the working group should have in it's charter to >>> work >>> on both protocols and operational practices? >> >> Usually, protocols and operational practices are decoupled as we need >> some time to learn from the actual deployment to document >> operationnal Yes, and we have a mix of success this way. >> practices. However, in the case of LISP, if the objective is a set of >> Experimental RFCs, then having experimental operationnal practices >> that >> are documented would be useful. This might be done by asking IANA >> for a >> small reserved block of addresses to be used as EIDs for a limited >> time >> and the establishment of an experimental registry (e.g. within an >> existing RIR willing to experiment) to also evaluate this part of the >> solution. > > I am hesitant to mix this all together. Of course we need an I think if we want to build practical solutions, we need the protocol designers to listen and work with the operational folks. And we need the operational folks help with designing the protocols. There are good minds that have the capability to "cross over". I, personally, have done this in the past and practical solutions do result. In fact, we find out way early when we make mistakes. > allocation scheme for the experiment to go forward, but that is not > the same as deciding how things will be allocated in production. Scott, let's at least get going with some model that is reasonable. We don't need to wait or delay or add more process if we don't have to. > There is a lot of politics there. I would say that all we need is an > existence proof that there is a way to allocate EIDs and RLOCs, but we > don't need to come up with a recommendation on what the Internet / > RIRs should do. I hope. We need the entropy factor in this as well. So we need to deploy something so people understand how existing deployment models will change, if they change at all and if new deployment models and business opportunities develop. Dino > > > Scott > _______________________________________________ > 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 lisp-bounces@ietf.org Mon Jan 19 09:04:37 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF033A69AC; Mon, 19 Jan 2009 09:04:37 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB79B3A69AC for ; Mon, 19 Jan 2009 09:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 q7BNS4sryB2s for ; Mon, 19 Jan 2009 09:04:36 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E31223A6918 for ; Mon, 19 Jan 2009 09:04:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="34182215" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2009 17:03:05 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0JH35kL014186; Mon, 19 Jan 2009 12:03:05 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0JH356N027016; Mon, 19 Jan 2009 17:03:05 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); Mon, 19 Jan 2009 12:03:05 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 12:03:04 -0500 Date: Mon, 19 Jan 2009 12:02:59 -0500 From: Scott Brim To: David Meyer Message-ID: <20090119170259.GH85912@cisco.com> References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <20090119165247.GF85912@cisco.com> <20090119165842.GB14305@1-4-5.net> MIME-Version: 1.0 In-Reply-To: <20090119165842.GB14305@1-4-5.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 19 Jan 2009 17:03:05.0034 (UTC) FILETIME=[CB6B9AA0:01C97A57] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============0106877646==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0106877646== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Excerpts from David Meyer on Mon, Jan 19, 2009 08:58:42AM -0800: > > > Concerning the locators, an important requirement for the > > > scalability of the underlying routing system is that it should > > > be possible to allocate locators in a way that follows the > > > network topology. In practice, this implies that locators will > > > have a limited lifetime and that all xTR (and the supporting > > > services including the mapping system) should be prepared for a > > > change of their locator. Locator renumbering should be part of > > > the standardised solution from day one. Otherwise, we'll be > > > stuck in the same situation as with IPv6 today where renumbering > > > is still not solved and network operators are changing the > > > policies of the RIRs to ensure that they will not need to > > > renumber. > >=20 > > When you say locators, I hope you mean the core-facing RLOCs. =20 >=20 > That is how I read it, and there are various proposals around > for how to do this.=20 >=20 > Do folks want to have an independent work item (i.e., draft) > for this, or do you envision that xTR renumbering be folded > into the base spec? It's not an extension. Let's leave it in the base spec unless/until the base spec gets too big. --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkl0skMACgkQF0TR2hENFAR4bwCePUoJJur0SokDnUlZUMBovX/U I4AAoLAjE3KtMZv8W3UIr0s2vTyHQYW/ =5RKU -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- --===============0106877646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0106877646==-- From lisp-bounces@ietf.org Mon Jan 19 09:05:03 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504BA3A6918; Mon, 19 Jan 2009 09:05:03 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B59E3A6904 for ; Mon, 19 Jan 2009 09:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 NhEREXhSe+wG for ; Mon, 19 Jan 2009 09:05:01 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A738D3A6918 for ; Mon, 19 Jan 2009 09:05:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="34220059" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Jan 2009 17:04:45 +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 n0JH4jAp014843 for ; Mon, 19 Jan 2009 12:04:45 -0500 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 n0JH4jtx000825 for ; Mon, 19 Jan 2009 17:04:45 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); Mon, 19 Jan 2009 12:04:45 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 12:04:44 -0500 Date: Mon, 19 Jan 2009 12:04:41 -0500 From: Scott Brim To: Dino Farinacci Message-ID: <20090119170441.GI85912@cisco.com> References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> <497433D8.30600@uclouvain.be> <20090119165454.GG85912@cisco.com> <5C6B1851-EA75-4265-AD93-4E101DC849DE@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5C6B1851-EA75-4265-AD93-4E101DC849DE@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 19 Jan 2009 17:04:44.0887 (UTC) FILETIME=[06EFF670:01C97A58] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: lisp@ietf.org Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Excerpts from Dino Farinacci on Mon, Jan 19, 2009 09:01:54AM -0800: >> allocation scheme for the experiment to go forward, but that is not >> the same as deciding how things will be allocated in production. > > Scott, let's at least get going with some model that is reasonable. Yup - see "existence proof". >> There is a lot of politics there. I would say that all we need is an >> existence proof that there is a way to allocate EIDs and RLOCs, but we >> don't need to come up with a recommendation on what the Internet / >> RIRs should do. I hope. > > We need the entropy factor in this as well. So we need to deploy > something so people understand how existing deployment models will > change, if they change at all and if new deployment models and business > opportunities develop. Yes _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 19 09:12:54 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8E23A67F6; Mon, 19 Jan 2009 09:12:54 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E793A67F6 for ; Mon, 19 Jan 2009 09:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 EcqnDbYNrjIv for ; Mon, 19 Jan 2009 09:12:48 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 6322B3A6774 for ; Mon, 19 Jan 2009 09:12:47 -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 n0JHCUQg014748; Mon, 19 Jan 2009 09:12:30 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0JHCUUW014747; Mon, 19 Jan 2009 09:12:30 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 19 Jan 2009 09:12:30 -0800 From: David Meyer To: Scott Brim Message-ID: <20090119171230.GC14305@1-4-5.net> References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> <497433D8.30600@uclouvain.be> <20090119165454.GG85912@cisco.com> MIME-Version: 1.0 In-Reply-To: <20090119165454.GG85912@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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============1705513096==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1705513096== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t0UkRYy7tHLRMCai" Content-Disposition: inline --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Scott, > Excerpts from Olivier Bonaventure on Mon, Jan 19, 2009 09:03:36AM +0100: > > >> Another point that should be discussed in a LISP WG is how locators = and > > >> EIDs should be allocated. This is more a policy than a protocol issu= e, > > >> but I think that it will have an impact on the long-term scalablity = of a > > >> solution such as LISP. > > >=20 > > > So, do you think the working group should have in it's charter to work > > > on both protocols and operational practices? > >=20 > > Usually, protocols and operational practices are decoupled as we need > > some time to learn from the actual deployment to document operationnal > > practices. However, in the case of LISP, if the objective is a set of > > Experimental RFCs, then having experimental operationnal practices that > > are documented would be useful. This might be done by asking IANA for a > > small reserved block of addresses to be used as EIDs for a limited time > > and the establishment of an experimental registry (e.g. within an > > existing RIR willing to experiment) to also evaluate this part of the > > solution. >=20 > I am hesitant to mix this all together. Of course we need an > allocation scheme for the experiment to go forward, but that is not > the same as deciding how things will be allocated in production. > There is a lot of politics there. I would say that all we need is an > existence proof that there is a way to allocate EIDs and RLOCs, but we > don't need to come up with a recommendation on what the Internet / > RIRs should do. I hope. I would guess that a draft that provided guidance to the RIRs around EID allocation would be a generally good thing. The question (which I think you're raising) is whether such a draft should be part of the LISP WG that we're discussing.=20 Now, an argument could be made that what we're discussing here is a protocol WG, and that the RIR EID allocation guidance draft is more of an operational (and as you point out, political) document. In addition, as you know RIR policy is for the most part formulated by the RIR constituents, not the IETF. That said, a document outlining what we have in mind with respect to EID-allocation and aggregation would seem to be useful, if for no other reason that the ideas would be documented. So let me ask again: Do folks think a document describing EID allocation strategy, targeted at the RIRs, would be a useful (and appropriate) document for a LISP WG to produce, noting that there may be other venues for such a document, e.g., GROW. Please chime in. FYI - I've included a schematic of the EID addressing plan that we're using today below. Thnx, Dave --- # # Consolidated LISP Addressing Plan # # For IPv6 # # OrgName: Cisco Systems, Inc. # OrgID: CISCOS-2 # Address: 170 West Tasman Drive # City: San Jose # StateProv: CA # PostalCode: 95134 # Country: US # =20 # NetRange: 2610:00D0:0000:0000:0000:0000:0000:0000 -=20 # 2610:00D0:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF # CIDR: 2610:00D0:0000:0000:0000:0000:0000:0000/32 # NetName: LISPV6 # NetHandle: NET6-2610-D0-1 # Parent: NET6-2610-1 # NetType: Direct Assignment # Comment: # RegDate: 2008-05-09 # Updated: 2008-05-09 # =20 # RTechHandle: DMM65-ARIN # RTechName: Meyer, David # RTechPhone: +1-541-346-1747 # RTechEmail: dmm@antc.uoregon.edu # =20 # OrgTechHandle: DN5-ORG-ARIN # OrgTechName: Cisco Systems, Inc. # OrgTechPhone: +1-408-527-9223 # OrgTechEmail: dns-info@cisco.com # # # # 2610:D0:/32 -- The universe # # 2610:D0:1000:/36 # ^ # | # continent # # 2610:D0:1100:/40 # ^ # | # Region # # 2610:D0:1100:/48 # -- # sites # # # # David Meyer # dmm@1-4-5.net # Tue May 6 07:58:53 2008 # # $Header: /home/dmm/lisp/configs/RCS/addressing.plan,v 1.76 2009/01/= 16 16:13:31 dmm Exp $ # IPv4 EID Space -------------- NA: 153.16.0.0/20 EU: 153.16.32.0/20 Asia: 153.16.64.0/20 Africa: 153.16.96.0/20 Latin America: 153.16.128.0/20 Reserved: 153.16.160.0/20 153.16.192.0/20 153.16.224.0/20 IPv6 EID Space -------------- NA: 2610:D0:1000::/36 EU: 2610:D0:2000::/36 =20 Asia: 2610:D0:3000::/36 =20 Africa: 2610:D0:4000::/36 Latin America: 2610:D0:5000::/36 Reserved: 2610:D0:6000::/36 - 2610:D0:F000::/36 =09 --t0UkRYy7tHLRMCai 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) iEYEARECAAYFAkl0tH4ACgkQORgD1qCZ2KddwwCfXcCYS69QAdO3eH2fytS9V/85 ovEAn1oKCz3sYl8zcvcUYHsnst7uPdlE =x3zA -----END PGP SIGNATURE----- --t0UkRYy7tHLRMCai-- --===============1705513096== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1705513096==-- From lisp-bounces@ietf.org Mon Jan 19 09:16:26 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B7A3A67F6; Mon, 19 Jan 2009 09:16:26 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9783A67F6 for ; Mon, 19 Jan 2009 09:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.919 X-Spam-Level: X-Spam-Status: No, score=-8.919 tagged_above=-999 required=5 tests=[AWL=1.680, BAYES_00=-2.599, 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 ePzxqwPKWovB for ; Mon, 19 Jan 2009 09:16:23 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 705143A6774 for ; Mon, 19 Jan 2009 09:16:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="31310150" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2009 17:16:04 +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 n0JHG4eO022505; Mon, 19 Jan 2009 18:16:04 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0JHG42I020284; Mon, 19 Jan 2009 17:16:04 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 18:16:04 +0100 Received: from adsl-247-4-fixip.tiscali.ch ([10.61.87.93]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 18:16:03 +0100 Message-ID: <4974B553.5060203@cisco.com> Date: Mon, 19 Jan 2009 18:16:03 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090116 Shredder/3.0b2pre MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> In-Reply-To: <4973AD19.6020706@uclouvain.be> X-OriginalArrivalTime: 19 Jan 2009 17:16:03.0818 (UTC) FILETIME=[9B9C9CA0:01C97A59] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1343; t=1232385364; x=1233249364; 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]=20draft=20charter=20for=20a=20LI SP=20BOF/WG=20--=20please=20comment |Sender:=20; bh=qzhzaf2QW/+d97wfqNfK7ZzU3hFENii4oIMknaY0F0w=; b=bxM2dpsrS/caSlU6YF7WBvEWUzT1WjuLzPz8S7HDeZ6EKVKVltYZur2gdf wuWVJ55pwENIeiVoAV1NaLfFUUSI/rVfKSYCimBM1YQkH03cFHdOLUY0ik1l 8/eCIbQBgw; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org On 1/18/09 11:28 PM, Olivier Bonaventure wrote: > Concerning the locators, an important requirement for the scalability of > the underlying routing system is that it should be possible to allocate > locators in a way that follows the network topology. In practice, this > implies that locators will have a limited lifetime and that all xTR (and > the supporting services including the mapping system) should be prepared > for a change of their locator. Locator renumbering should be part of > the standardised solution from day one. Otherwise, we'll be stuck in the > same situation as with IPv6 today where renumbering is still not solved > and network operators are changing the policies of the RIRs to ensure > that they will not need to renumber. > > Ok, but what does this mean? The difficulty of renumbering is by-and-large the orders of magnitude of changes that need to occur on the host level. A 60,000 device network today has to renumber, well, 60,000 devices in a renumbering event. Of course in LISP those would be EIDs, and so you wouldn't imagine renumbering them. On the locator front, we're talking what? 1/2 dozen systems? Maybe 32 max? But perhaps you mean it should be possible to support mobility? In which case you could have 60,000 mappings, all changing constantly. Eliot _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 19 09:34:53 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DC43A68B0; Mon, 19 Jan 2009 09:34:53 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCBDD3A68B0 for ; Mon, 19 Jan 2009 09:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 y34Qs2RT4vLz for ; Mon, 19 Jan 2009 09:34:52 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BFE603A67FF for ; Mon, 19 Jan 2009 09:34:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="34184972" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2009 17:34:35 +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 n0JHYZp1010535; Mon, 19 Jan 2009 12:34:35 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0JHYZZT007257; Mon, 19 Jan 2009 17:34:35 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); Mon, 19 Jan 2009 12:34:35 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 12:34:34 -0500 Date: Mon, 19 Jan 2009 12:34:31 -0500 From: Scott Brim To: David Meyer Message-ID: <20090119173431.GJ85912@cisco.com> References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> <497433D8.30600@uclouvain.be> <20090119165454.GG85912@cisco.com> <20090119171230.GC14305@1-4-5.net> MIME-Version: 1.0 In-Reply-To: <20090119171230.GC14305@1-4-5.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 19 Jan 2009 17:34:34.0941 (UTC) FILETIME=[31E486D0:01C97A5C] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: lisp@ietf.org Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============1268556763==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1268556763== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Excerpts from David Meyer on Mon, Jan 19, 2009 09:12:30AM -0800: > I would guess that a draft that provided guidance to the > RIRs around EID allocation would be a generally good > thing. The question (which I think you're raising) is > whether such a draft should be part of the LISP WG that > we're discussing.=20 >=20 > Now, an argument could be made that what we're discussing > here is a protocol WG, and that the RIR EID allocation > guidance draft is more of an operational (and as you > point out, political) document. In addition, as you know > RIR policy is for the most part formulated by the RIR > constituents, not the IETF. That said, a document > outlining what we have in mind with respect to > EID-allocation and aggregation would seem to be useful, > if for no other reason that the ideas would be > documented. >=20 > So let me ask again: Do folks think a document describing > EID allocation strategy, targeted at the RIRs, would be a > useful (and appropriate) document for a LISP WG to > produce, noting that there may be other venues for such a > document, e.g., GROW. Please chime in. OK, here's a suggestion: as the protocols are being finalized, - be sure that ops people agree that possible allocation approaches are reasonable (so the protocol isn't decoupled from reality). =20 - add yet another draft which will be "implications" of the design. With respect to this particular issue, it would include implications for how EIDs and Locators are allocated. ?? Scott --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkl0uacACgkQF0TR2hENFARS8ACeMscSqT0d3hwNvxWDnwgd8S/o ItsAoJsG5Q6XJfLdY5jGuHHyd7Wiz5rd =XMJT -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk-- --===============1268556763== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1268556763==-- From lisp-bounces@ietf.org Mon Jan 19 11:00:52 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90913A69CE; Mon, 19 Jan 2009 11:00:52 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40EB28C157 for ; Mon, 19 Jan 2009 11:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 HYE-tXkCAr8s for ; Mon, 19 Jan 2009 11:00:50 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 141903A6966 for ; Mon, 19 Jan 2009 11:00:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="232657064" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Jan 2009 19:00:34 +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 n0JJ0Y52021413; Mon, 19 Jan 2009 11:00:34 -0800 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 n0JJ0YtD020778; Mon, 19 Jan 2009 19:00:34 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, 19 Jan 2009 11:00:34 -0800 Received: from [192.168.5.219] ([10.21.121.246]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 11:00:33 -0800 Message-Id: From: Dino Farinacci To: Eliot Lear In-Reply-To: <4974B553.5060203@cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 19 Jan 2009 11:00:33 -0800 References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <4974B553.5060203@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 19 Jan 2009 19:00:33.0761 (UTC) FILETIME=[34C9FD10:01C97A68] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1596; t=1232391634; x=1233255634; 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]=20draft=20charter=20for=20a=20LI SP=20BOF/WG=20--=20please=20comment |Sender:=20; bh=WNe8Jhp9QLD0s2yg9IQzzdpY/cJpdzrio1rHhKCWIwc=; b=lZDnvXfaEvGBCmvrCQyagB9Ozn4TAVKBOFGxqMLe9rfWXzMCsnrh2U7hLD tz0TD3i2+AnAHaemHc30/sN1Bn2C4lVdGqUnhNNT2o2yfgkE5TKNLLtWDohv yB8u6wGmZN; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > On 1/18/09 11:28 PM, Olivier Bonaventure wrote: >> Concerning the locators, an important requirement for the >> scalability of >> the underlying routing system is that it should be possible to >> allocate >> locators in a way that follows the network topology. In practice, >> this >> implies that locators will have a limited lifetime and that all xTR >> (and >> the supporting services including the mapping system) should be >> prepared >> for a change of their locator. Locator renumbering should be part of >> the standardised solution from day one. Otherwise, we'll be stuck >> in the >> same situation as with IPv6 today where renumbering is still not >> solved >> and network operators are changing the policies of the RIRs to ensure >> that they will not need to renumber. >> >> > > Ok, but what does this mean? The difficulty of renumbering is by- > and-large the orders of magnitude of changes that need to occur on > the host level. A 60,000 device network today has to renumber, > well, 60,000 devices in a renumbering event. Of course in LISP > those would be EIDs, and so you wouldn't imagine renumbering them. > On the locator front, we're talking what? 1/2 dozen systems? Maybe > 32 max? But perhaps you mean it should be possible to support > mobility? In which case you could have 60,000 mappings, all > changing constantly. In most cases 2-4. Dino > > > Eliot > _______________________________________________ > 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 lisp-bounces@ietf.org Mon Jan 19 14:13:36 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB83B3A6934; Mon, 19 Jan 2009 14:13:36 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B5E3A6934 for ; Mon, 19 Jan 2009 14:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 17DepHX1+iQO for ; Mon, 19 Jan 2009 14:13:26 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id C40BB3A6912 for ; Mon, 19 Jan 2009 14:13:25 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so2519478ywj.49 for ; Mon, 19 Jan 2009 14:13:07 -0800 (PST) Received: by 10.100.126.19 with SMTP id y19mr4312653anc.2.1232401545763; Mon, 19 Jan 2009 13:45:45 -0800 (PST) Received: by 10.100.140.7 with HTTP; Mon, 19 Jan 2009 13:45:45 -0800 (PST) Message-ID: <9b942cbb0901191345k2259bb72if8d9198f09905bfd@mail.gmail.com> Date: Mon, 19 Jan 2009 15:45:45 -0600 From: "Benson Schliesser" To: "David Meyer" In-Reply-To: <20090119171230.GC14305@1-4-5.net> MIME-Version: 1.0 References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> <497433D8.30600@uclouvain.be> <20090119165454.GG85912@cisco.com> <20090119171230.GC14305@1-4-5.net> Cc: lisp@ietf.org Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============1335851907==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1335851907== Content-Type: multipart/alternative; boundary="----=_Part_15605_20391441.1232401545756" ------=_Part_15605_20391441.1232401545756 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dave- In response to your question: Yes, I think that the WG should document recommendations for allocation and routing of both EIDs and RLOCs. LISP may have other uses, but routing and addressing scale is the primary motivation for its development. The WG should capture all salient points on how LISP is thought to address these issues, while acknowledging that external groups will ultimately decide how it's deployed. The WG should probably stop short of capturing operational topics such as best practices, which might belong in a future LISP-Ops WG. IMHO, -Benson On Jan 19, 2009 11:12 AM, "David Meyer" wrote: Scott, > Excerpts from Olivier Bonaventure on Mon, Jan 19, 2009 09:03:36AM +0100: > > >> Another point tha... I would guess that a draft that provided guidance to the RIRs around EID allocation would be a generally good thing. The question (which I think you're raising) is whether such a draft should be part of the LISP WG that we're discussing. Now, an argument could be made that what we're discussing here is a protocol WG, and that the RIR EID allocation guidance draft is more of an operational (and as you point out, political) document. In addition, as you know RIR policy is for the most part formulated by the RIR constituents, not the IETF. That said, a document outlining what we have in mind with respect to EID-allocation and aggregation would seem to be useful, if for no other reason that the ideas would be documented. So let me ask again: Do folks think a document describing EID allocation strategy, targeted at the RIRs, would be a useful (and appropriate) document for a LISP WG to produce, noting that there may be other venues for such a document, e.g., GROW. Please chime in. FYI - I've included a schematic of the EID addressing plan that we're using today below. Thnx, Dave --- # # Consolidated LISP Addressing Plan # # For IPv6 # # OrgName: Cisco Systems, Inc. # OrgID: CISCOS-2 # Address: 170 West Tasman Drive # City: San Jose # StateProv: CA # PostalCode: 95134 # Country: US # # NetRange: 2610:00D0:0000:0000:0000:0000:0000:0000 - # 2610:00D0:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF # CIDR: 2610:00D0:0000:0000:0000:0000:0000:0000/32 # NetName: LISPV6 # NetHandle: NET6-2610-D0-1 # Parent: NET6-2610-1 # NetType: Direct Assignment # Comment: # RegDate: 2008-05-09 # Updated: 2008-05-09 # # RTechHandle: DMM65-ARIN # RTechName: Meyer, David # RTechPhone: +1-541-346-1747 # RTechEmail: dmm@antc.uoregon.edu # # OrgTechHandle: DN5-ORG-ARIN # OrgTechName: Cisco Systems, Inc. # OrgTechPhone: +1-408-527-9223 # OrgTechEmail: dns-info@cisco.com # # # # 2610:D0:/32 -- The universe # # 2610:D0:1000:/36 # ^ # | # continent # # 2610:D0:1100:/40 # ^ # | # Region # # 2610:D0:1100:/48 # -- # sites # # # # David Meyer # dmm@1-4-5.net # Tue May 6 07:58:53 2008 # # $Header: /home/dmm/lisp/configs/RCS/addressing.plan,v 1.76 2009/01/16 16:13:31 dmm Exp $ # IPv4 EID Space -------------- NA: 153.16.0.0/20 EU: 153.16.32.0/20 Asia: 153.16.64.0/20 Africa: 153.16.96.0/20 Latin America: 153.16.128.0/20 Reserved: 153.16.160.0/20 153.16.192.0/20 153.16.224.0/20 IPv6 EID Space -------------- NA: 2610:D0:1000::/36 EU: 2610:D0:2000::/36 Asia: 2610:D0:3000::/36 Africa: 2610:D0:4000::/36 Latin America: 2610:D0:5000::/36 Reserved: 2610:D0:6000::/36 - 2610:D0:F000::/36 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl0tH4ACgkQORgD1qCZ2KddwwCfXcCYS69QAdO3eH2fytS9V/85 ovEAn1oKCz3sYl8zcvcUYHsnst7uPdlE =x3zA -----END PGP SIGNATURE----- _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ------=_Part_15605_20391441.1232401545756 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Dave-

In response to your question: Yes, I think that the WG should document recommendations for allocation and routing of both EIDs and RLOCs.

LISP may have other uses, but routing and addressing scale is the primary motivation for its development. The WG should capture all salient points on how LISP is thought to address these issues, while acknowledging that external groups will ultimately decide how it's deployed. The WG should probably stop short of capturing operational topics such as best practices, which might belong in a future LISP-Ops WG.

IMHO,
-Benson

On Jan 19, 2009 11:12 AM, "David Meyer" <dmm@1-4-5.net> wrote:

       Scott,

> Excerpts from Olivier Bonaventure on Mon, Jan 19, 2009 09:03:36AM +0100: > > >> Another point tha...

       I would guess that a draft that provided guidance to the
       RIRs around EID allocation would be a generally good
       thing. The question (which I think you're raising) is
       whether such a draft should be part of the LISP WG that
       we're discussing.

       Now, an argument could be made that what we're discussing
       here is a protocol WG, and that the RIR EID allocation
       guidance draft is more of an operational (and as you
       point out, political) document. In addition, as you know
       RIR policy is for the most part formulated by the RIR
       constituents, not the IETF. That said, a document
       outlining what we have in mind with respect to
       EID-allocation and aggregation would seem to be useful,
       if for no other reason that the ideas would be
       documented.

       So let me ask again: Do folks think a document describing
       EID allocation strategy, targeted at the RIRs, would be a
       useful (and appropriate) document for a LISP WG to
       produce, noting that there may be other venues for such a
       document, e.g., GROW. Please chime in.

       FYI - I've included a schematic of the EID addressing plan
       that we're using today below.

       Thnx,

       Dave

---

#
#        Consolidated LISP Addressing Plan
#
#       For IPv6
#
#       OrgName:    Cisco Systems, Inc.
#       OrgID:      CISCOS-2
#       Address:    170 West Tasman Drive
#       City:       San Jose
#       StateProv:  CA
#       PostalCode: 95134
#       Country:    US
#
#       NetRange:   2610:00D0:0000:0000:0000:0000:0000:0000 -
#       2610:00D0:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
#       CIDR:       2610:00D0:0000:0000:0000:0000:0000:0000/32
#       NetName:    LISPV6
#       NetHandle:  NET6-2610-D0-1
#       Parent:     NET6-2610-1
#       NetType:    Direct Assignment
#       Comment:
#       RegDate:    2008-05-09
#       Updated:    2008-05-09
#
#       RTechHandle: DMM65-ARIN
#       RTechName:   Meyer, David
#       RTechPhone:  +1-541-346-1747
#       RTechEmail:  dmm@antc.uoregon.edu
#
#       OrgTechHandle: DN5-ORG-ARIN
#       OrgTechName:   Cisco Systems, Inc.
#       OrgTechPhone:  +1-408-527-9223
#       OrgTechEmail:  dns-info@cisco.com
#
#
#
#               2610:D0:/32 -- The universe
#
#                2610:D0:1000:/36
#                          ^
#                          |
#                        continent
#
#                2610:D0:1100:/40
#                           ^
#                           |
#                          Region
#
#                2610:D0:1100:/48
#                             --
#                           sites
#
#
#
#       David Meyer
#       dmm@1-4-5.net
#       Tue May  6 07:58:53 2008
#
#       $Header: /home/dmm/lisp/configs/RCS/addressing.plan,v 1.76 2009/01/16 16:13:31 dmm Exp $
#

IPv4 EID Space
--------------
NA:              153.16.0.0/20
EU:              153.16.32.0/20
Asia:            153.16.64.0/20
Africa:          153.16.96.0/20
Latin America:   153.16.128.0/20
Reserved:        153.16.160.0/20
                153.16.192.0/20
                153.16.224.0/20

IPv6 EID Space
--------------
NA:              2610:D0:1000::/36
EU:              2610:D0:2000::/36
Asia:            2610:D0:3000::/36
Africa:          2610:D0:4000::/36
Latin America:   2610:D0:5000::/36
Reserved:        2610:D0:6000::/36 - 2610:D0:F000::/36




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkl0tH4ACgkQORgD1qCZ2KddwwCfXcCYS69QAdO3eH2fytS9V/85
ovEAn1oKCz3sYl8zcvcUYHsnst7uPdlE
=x3zA
-----END PGP SIGNATURE-----

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

------=_Part_15605_20391441.1232401545756-- --===============1335851907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1335851907==-- From lisp-bounces@ietf.org Mon Jan 19 16:32:43 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9753A6A98; Mon, 19 Jan 2009 16:32:43 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0FC3A6A98 for ; Mon, 19 Jan 2009 16:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 HrQWfEvSpHeg for ; Mon, 19 Jan 2009 16:32:41 -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 EF0BF3A67B1 for ; Mon, 19 Jan 2009 16:32:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,292,1231113600"; d="scan'208";a="130877739" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 20 Jan 2009 00:32:25 +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 n0K0WPwL010515; Mon, 19 Jan 2009 16:32:25 -0800 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 n0K0WPI7011484; Tue, 20 Jan 2009 00:32:25 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); Mon, 19 Jan 2009 16:32:24 -0800 Received: from [192.168.5.52] ([10.21.149.231]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 16:32:24 -0800 Message-Id: From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <49730E98.1030101@uclouvain.be> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 19 Jan 2009 16:32:24 -0800 References: <49730E98.1030101@uclouvain.be> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 20 Jan 2009 00:32:24.0419 (UTC) FILETIME=[90774B30:01C97A96] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6916; t=1232411545; x=1233275545; 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]=20Locator=20liveness=20problem |Sender:=20; bh=rGpLlecU1PMAtaRbedKuE+9UQG2zjwnO8OWhdKZEGzM=; b=avs14iq6Fq/A2YH0OCQnNlNJZMMHI6Yo37p82cmwDhW9OXpZiNRaAGNj00 w2nFLwOCSmkrCKFrCA61Rx6FiPaGvnq28n3V/5EqWVMZYNZyOhejt7Tv0Ud5 Qe2ncNcmYj; 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] Locator liveness problem 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > Hello, > > draft-meyer-loc-id-implications-00 discusses the locator liveness > problem and several possible solutions. I think that there are several > related issues that need to be discussed : Olivier, see my comments inline. > 1- What are the types of failures that we consider and want to be able > to detect : > > a. Failure of an ETR > > b. Failure of (one of the link) directly attached to an ETR to its > provider These are covered by the loc-reach-bits and have been in the LISP spec for quite a long time. I think dating back to the -02 draft. > c. Failure or misconfiguration of some intermediate links that causes > some ETR to become unreachable from some ITRs although the ETR and its > links are up. We need to distinguish between the term "reachable" and "alive". And the mechanisms for "reachability" or "liveness" need to be clearly decoupled and analyzed independently. Today a BGP router believes a destination is alive because it is reachable. Being "reachable" here means there is a route (in the DFZ is it a more specific route and not a default route) in the local RIB. "Liveness" is usally what a ping echo-reply would tell you. And we all know there is nothing protocol-wise in the core that tests for liveness. The reason I say this is because, with good approximation and probability, a reachable prefix is one that usually is alive. If we didn't believe that, the Internet wouldn't be reliable today. So the question I keep challenging people with is, with LISP loc-reach- bits and BGP route existence (i.e. "reachability"), is this good enough. Is this enough tools for an ITR to know when to switch RLOCs. If the ITR is running BGP, I think we are in a good position to day yes. When the ITR is not running BGP, and there are many cases for it not to run BGP to lower the opex cost of running the ITR on a CPE router, is there an inadequate reachability capability. That is the question. I do have some ideas to solve this low-opex ITR case. And they are light-weight. > Failures of type C are the more general, but also the most complex to > handle. There has been some work on detecting such > failures/misconfigurations ( see e.g. > A. Dhamdhere, R. Teixeira, C. Dovrolis, and C. Diot - > "NetDiagnoser:Troubleshooting network unreachabilities using end-to- > end > probes and routing data", in Proc. of CoNEXT, December 2007 ) > , but I don't think that we could reliably detect them in a LISP > world. > I would suggest to focus the discussion on failures of type A and > type B. Those are handled. The case is where a peering connection goes down and an alternate path is not available because the transit policy for an RLOC is quite different than for an EID. That is, a transit ISP cannot tell it's customer is behind an RLOC supported by another ISP. And the EID is not known to the core (for good reasons) so we could sever connectivity which previously was not before we introduced the level of indirection. Having said that, c is the issue at hand here and not a and b. > 2- The focus of LISP should be to forward packets despite of > failures of > an ETR or failures of a link that is attached to an ETR and not to > detect failures. But having an alternate path locally and not using could be question of "a good feature we cannot scale". > I think that we should also consider network design best practices and > fast reroute techniques that could allow the EIDs served by the ETR to > remain reachable although an ETR or a link failed. Fast reroute mechanisms in the xTRs? Or, alternately in core, they are already there. There is also the case how fast the IGP can switch to another exit ITR. > First, if a set of EID prefixes is served only by a single-homed ETR, > then the failure of the ETR or of the link that attaches the ETR to > its If the site is single homed and the ETR goes down, there is no reason to fix this, because you cannot. Just like routers can't switch packets without the power on. ;-) Oh, and others have asked me to make packets go faster than the speed of light too. ;-) > provider will cause a failure of the EID. Such a failure will be > eventually detected by ICMP destination unreachable messages. This is Another comment I have. Can all of us please stop talking about ICMP Unreachables. We can't rely on them. They are not dependable. They are off by default in core IOS routers. They are filtered by NATs and other firewalls. All designs should spec that if an Unreachble is received, you can use it but you can't base a design on using ICMP unreachables. Even if they were turned on, there are too many security implications. Also, ICMP unreachables don't contain mask-lengths, so this contributes to it's unscalablility. > the same case as today when a router attached to a single subnet which > is part of a larger aggregate fails. In this case, BGP does not inform > the entire Internet about the failure as the aggregate remains > reachable. Yes, another problem with Unreachables. > Second, we should consider dual-homed ETRs. There are two subcases : > a- Two ETRs attached to the same provider > b- Two ETRs attached to different providers > > In subcase a, the two ETRs could be configured in anycast so that the > provider redirects the packets to the other ETR in case of failure of That all depends on where in the region of that ISP they connect. An ISP is not going to want to carry host routes across their core. > one ETR or one of its links. > > In subcase b, a cooperation among the two providers could ensure that > the two RLOCs remain reachable even if one of the links or one of the There is never cooperation like this between two SPs. My definition of inter-SP cooperation is agreeing to BGP peer with each other and the manual exchange of peering addresses. This is why the LISP authors think the sweet-spot for a LISP xTR is at the CPE router. > ETR fails. A possible solution to this problem could be based on the > BGP > fast reroute technique described in > http://inl.info.ucl.ac.be/publications/achieving-sub-50-milliseconds-recove-0 > but other solutions are possible as well > > I think that we should explore the utilisation of such network design > and fast reroute techniques to ensure that LISP encapsulated packets > are > delivered even in case of failures instead of discussing the detection > of the failures themselves. If we cannot find enough network design > and > fast reroute techniques, then we'll have to define ways to detect > failures. We should definitely discuss. But I hope we can make hard decisions as well. > Best regards, Thanks for the thought provoking email Olivier. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 03:09:41 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEEAE3A6BBF; Tue, 20 Jan 2009 03:09:41 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F9F28C127 for ; Tue, 20 Jan 2009 03:09:40 -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 6cbHxmsGKFZ7 for ; Tue, 20 Jan 2009 03:09:39 -0800 (PST) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 941A83A6A42 for ; Tue, 20 Jan 2009 03:09:39 -0800 (PST) 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=4sfvDFzBZAZNS5kuO2nKxmVozwA=; b=gCGSNNAuBN gi6eIshXw/zBcPWGRw5Lo/z8EzlLF3UAPPd2+eKwqk7DEkuhnnRoAopgQUVbXRjy 6kL/dvKjsa4B1X9Xm2ihOWIMizjqUgH5RqNO6gG1F42CEhxbykz1bBzHZBktzBq0 H4ZvI6HWtNes06YosUrXC583WmSJyhOsg= 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=0Jhw3 MvV4Fd+cYk2z4JW3ex0cK2EfzxjVnAEKyLR61SLy2F+q+i7TMXMFwp2TWQBGfiN1 mpQWFVMq3v0iypKKniIsv5Zwk8e3zWw9UwJhMw5XsxaZm/cIN5FEGbruvCbGmlfz rzzLy2P3xSGfG2TlXWHtg2LHF54plck49mN75k= Received: from mbpobo.dhcp.info.ucl.ac.be (unknown [130.104.228.96]) (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; Tue, 20 Jan 2009 12:09:17 +0100 (CET) Message-ID: <4975B0D9.3080001@uclouvain.be> Date: Tue, 20 Jan 2009 12:09:13 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: David Meyer References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> <497433D8.30600@uclouvain.be> <20090119165426.GA14305@1-4-5.net> In-Reply-To: <20090119165426.GA14305@1-4-5.net> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 46B32EBAC3.E495A 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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dave, > > As you may (or may not) know, we do have both IPv4 and > IPv6 EID prefixes in use now (153.16/16 and > 2610:D0:/32). It would be great if an RIR would pick up > allocation of their part of the address space. The > current model has RIPE, ARIN, LACNIC (actually UY) at the > top of the aggregation hierarchy, and each has a /20 > (from 153.16/16) and a /36 (2610:D0:/32). We're also > working with folks at APNIC, and hope to have them going > soon. So there is a kind of "square" at the top of the > ALT hierarchy consisting of RIPE, ARIN, APNIC, and > LACNIC. ... > > That said, perhaps the charter should include a work item > that looks something like "guidelines for allocating IPv4 > and IPv6 EID prefixes" or something similar. What do > folks think? I think that we should look at the type of information that needs to be maintained and provided by an EID allocation authority. If we would to be able to secure the mapping systems (and I'm convinced that we'll have to), we'll likely need to have cryptographical certificates that are provided by the allocation authority to the owner of the EID block. These certificates could be similar to those that are being discussed within the SIDR WG. They will allow EID block owners to prove the ownership of their EID blocks. A successful LISP experiment should also consider this problem. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 03:11:47 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15CB03A6A42; Tue, 20 Jan 2009 03:11:47 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A453A6A42 for ; Tue, 20 Jan 2009 03:11:45 -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 HXvRosqlWJfJ for ; Tue, 20 Jan 2009 03:11:45 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id D068D3A6889 for ; Tue, 20 Jan 2009 03:11:44 -0800 (PST) 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=luvrf380HoDunAeg+pDkJ67j2m4=; b=CzzHISYd1K yFH4bF+EYn8gQNl4Hq21tL1tMjX8uuOFMIih6693ZHi31ENuV6Y8uxK6tEmoUKwt tAYfam/KPylZEeup1SCG9uN/ALY7wnShdoI71rdg0rszBfuykm9j4rtRX9A5Is0N nCSP6lg6jNF+NhMJAGytjRwFwlBxbDdic= 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=oVmE+ UTG+qSzVLr1xWaMlGdRIbyumSr82FMhtcmtgP1TSfyw840D0AB6eHfHVudzUEakR Jj7xHpzejpIieL/deOnKn4SI2ntoAp3gI1/dI9eT83DHhgaFO9eodkOkZcexKVFC f/Rh1T33mJw5VuffQmeXOSTSKnbjgzwIoRXLC0= Received: from mbpobo.dhcp.info.ucl.ac.be (unknown [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, 20 Jan 2009 12:11:23 +0100 (CET) Message-ID: <4975B152.2040000@uclouvain.be> Date: Tue, 20 Jan 2009 12:11:14 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: David Meyer References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <20090119165247.GF85912@cisco.com> <20090119165842.GB14305@1-4-5.net> In-Reply-To: <20090119165842.GB14305@1-4-5.net> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 1C094F1C74.B53A0 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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dave, >>> Concerning the locators, an important requirement for the >>> scalability of the underlying routing system is that it should be >>> possible to allocate locators in a way that follows the network >>> topology. In practice, this implies that locators will have a >>> limited lifetime and that all xTR (and the supporting services >>> including the mapping system) should be prepared for a change of >>> their locator. Locator renumbering should be part of the >>> standardised solution from day one. Otherwise, we'll be stuck in the >>> same situation as with IPv6 today where renumbering is still not >>> solved and network operators are changing the policies of the RIRs >>> to ensure that they will not need to renumber. >> When you say locators, I hope you mean the core-facing RLOCs. Yes > That is how I read it, and there are various proposals > around for how to do this. > > Do folks want to have an independent work item (i.e., > draft) for this, or do you envision that xTR renumbering > be folded into the base spec? If RLOC renumbering is part of the base spec, then it will be implemented by everyone and everybody will know that they need to plan for a renumbering of their RLOCs. I would vote for discussing it in the base spec unless it becomes too large. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 04:10:42 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948A528C124; Tue, 20 Jan 2009 04:10:42 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F4728C111 for ; Tue, 20 Jan 2009 04:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.572 X-Spam-Level: X-Spam-Status: No, score=-8.572 tagged_above=-999 required=5 tests=[AWL=1.027, BAYES_00=-2.599, J_BACKHAIR_34=1, 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 rnYa-7yPt7+S for ; Tue, 20 Jan 2009 04:10:40 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8F1673A6BD6 for ; Tue, 20 Jan 2009 04:10:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,295,1231113600"; d="scan'208";a="31383896" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jan 2009 12:10: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 n0KCAM0O013862; Tue, 20 Jan 2009 13:10:22 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0KCAKNU002795; Tue, 20 Jan 2009 12:10:22 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 13:10:20 +0100 Received: from adsl-247-4-fixip.tiscali.ch ([10.61.93.171]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 13:10:19 +0100 Message-ID: <4975BF2B.6030107@cisco.com> Date: Tue, 20 Jan 2009 13:10:19 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090119 Shredder/3.0b2pre MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <20090119165247.GF85912@cisco.com> <20090119165842.GB14305@1-4-5.net> <4975B152.2040000@uclouvain.be> In-Reply-To: <4975B152.2040000@uclouvain.be> X-OriginalArrivalTime: 20 Jan 2009 12:10:19.0745 (UTC) FILETIME=[101AF510:01C97AF8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1316; t=1232453422; x=1233317422; 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]=20draft=20charter=20for=20a=20LI SP=20BOF/WG=20--=20please=20comment |Sender:=20; bh=yx1Wk3EksWFU+jEzYeIICfvT7jZtdZncqRfTrPLjZFQ=; b=fhiep+2yHjQFI1Gx0WYl6PO8aAy4+jeqaxZRc6EXVIrXoRTyn9sE78EuVt HhpOD49JoNM0/zlgLz1DLxBENvu1z5RVGhkkMQ9Mh0y3FuEUe9N6zpyoMFDS OYQkMoDD9B; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Olivier, > If RLOC renumbering is part of the base spec, then it will be > implemented by everyone and everybody will know that they need to plan > for a renumbering of their RLOCs. I would vote for discussing it in the > base spec unless it becomes too large. > Let me restate my earlier screed: what is the frequency of the event? Let's consider three options: Frequency of change Sort of Solution required Pluses / Minuses Whenever you change provider (rare) Manual, management Very easy to implement; less infrastructure needed to maintain; but constrains the solution space. Whenever you dial up your ppp connection automated management Provides more generality, plug and play for the house; but requires automated validation check for EID<->RLOC binding, but can be done through provisioning function As you move from one location to another automated signaling/control plane Most general (DEBE - does everything but eat) solution, but high signaling overhead, introduces immediate potential for additional points of failure, RPA (royal pain in the ...) I'd argue for sufficient architectural separation that you can do any or all three, but I would probably aim for (2) as a good initial target that is not too high not too low. Regards, Eliot _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 04:48:59 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE47C3A68B8; Tue, 20 Jan 2009 04:48:59 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42703A68B8 for ; Tue, 20 Jan 2009 04:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.428 X-Spam-Level: X-Spam-Status: No, score=-8.428 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 YHzejHxwFE19 for ; Tue, 20 Jan 2009 04:48:57 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 727133A67EC for ; Tue, 20 Jan 2009 04:48:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,295,1231113600"; d="scan'208,217";a="31389657" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jan 2009 12:48:40 +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 n0KCme7A027809; Tue, 20 Jan 2009 13:48:40 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0KCmeDi017977; Tue, 20 Jan 2009 12:48:40 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 13:48:40 +0100 Received: from adsl-247-4-fixip.tiscali.ch ([10.61.93.171]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 13:48:39 +0100 Message-ID: <4975C827.1050503@cisco.com> Date: Tue, 20 Jan 2009 13:48:39 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090119 Shredder/3.0b2pre MIME-Version: 1.0 To: Eliot Lear References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <20090119165247.GF85912@cisco.com> <20090119165842.GB14305@1-4-5.net> <4975B152.2040000@uclouvain.be> <4975BF2B.6030107@cisco.com> In-Reply-To: <4975BF2B.6030107@cisco.com> X-OriginalArrivalTime: 20 Jan 2009 12:48:39.0900 (UTC) FILETIME=[6B1AC1C0:01C97AFD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1619; t=1232455720; x=1233319720; 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]=20draft=20charter=20for=20a=20LI SP=20BOF/WG=20--=20please=20comment |Sender:=20; bh=Pe672hjOgv0v6Uo7EmnD2C0LX1pWG8EoUfsffX66rqk=; b=QcdGBvYcz04X3QlUr4wsqql3n/UlvBjMSRr/hrmBgkq6mMH8AYmk3bGwzr iAs16ozMskQLMU0vFmUnxxJ1Jez6QbFgo2CakCpYx3OeEmqG3dKDfss5hZQx t5MrmQZJYN; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============1474958949==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1474958949== Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Let's try that one again with some formatting:

Frequency of Change
 Sort of Solution Required
 Pluses / Minuses
Whenever you change provider (rare)
 Manual management
 Very easy to implement; less infrastructure needed to maintain; but constrains the solution space.
Whenever you dial up your ppp connection Automated management Provides more generality, plug and play for the house; but requires automated validation check for EID<->RLOC binding, but can be done through provisioning function.
As you move from one location to another (mobility)
 Automated signaling/control plane Most general (DEBE - does everything but eat) solution, but high signaling overhead, introduces immediate potential for additional points of failure, RPA (royal pain in the ...)

--===============1474958949== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1474958949==-- From lisp-bounces@ietf.org Tue Jan 20 08:00:58 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EBB28C17C; Tue, 20 Jan 2009 08:00:58 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E143A6B23 for ; Tue, 20 Jan 2009 08:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 OqAGIHC+zj5a for ; Tue, 20 Jan 2009 08:00:56 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 1BA4C28C124 for ; Tue, 20 Jan 2009 08:00:55 -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 n0KG0duG002900; Tue, 20 Jan 2009 08:00:39 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0KG0coB002899; Tue, 20 Jan 2009 08:00:38 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 08:00:38 -0800 From: David Meyer To: Olivier Bonaventure Message-ID: <20090120160038.GA2840@1-4-5.net> References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <73A75DC6-62ED-4E6A-AF6D-1EE854FB5C59@cisco.com> <497433D8.30600@uclouvain.be> <20090119165426.GA14305@1-4-5.net> <4975B0D9.3080001@uclouvain.be> MIME-Version: 1.0 In-Reply-To: <4975B0D9.3080001@uclouvain.be> 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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: multipart/mixed; boundary="===============0703837251==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0703837251== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 20, 2009 at 12:09:13PM +0100, Olivier Bonaventure wrote: > Dave, > >=20 > > As you may (or may not) know, we do have both IPv4 and > > IPv6 EID prefixes in use now (153.16/16 and > > 2610:D0:/32). It would be great if an RIR would pick up > > allocation of their part of the address space. The > > current model has RIPE, ARIN, LACNIC (actually UY) at the > > top of the aggregation hierarchy, and each has a /20 > > (from 153.16/16) and a /36 (2610:D0:/32). We're also > > working with folks at APNIC, and hope to have them going > > soon. So there is a kind of "square" at the top of the > > ALT hierarchy consisting of RIPE, ARIN, APNIC, and > > LACNIC.=20 > ... > >=20 > > That said, perhaps the charter should include a work item > > that looks something like "guidelines for allocating IPv4 > > and IPv6 EID prefixes" or something similar. What do > > folks think? >=20 >=20 > I think that we should look at the type of information that needs to be > maintained and provided by an EID allocation authority. >=20 > If we would to be able to secure the mapping systems (and I'm convinced > that we'll have to), we'll likely need to have cryptographical > certificates that are provided by the allocation authority to the owner > of the EID block. These certificates could be similar to those that are > being discussed within the SIDR WG. They will allow EID block owners to > prove the ownership of their EID blocks. A successful LISP experiment > should also consider this problem. Right. The idea was to use whatever the SIDR WG came up with (I had mentioned this to Sandy in Dublin, and she didn't see any issue with that). In any event, no reason to reinvent the wheel.=20 Dave --h31gzZEtNLTqOjlF 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) iEYEARECAAYFAkl19SYACgkQORgD1qCZ2Ke1CwCeKGatuANVpVjiXVbGMcISTZeA DlEAn2jC63ATo0jsPXD07crYF7HQ0ROR =x0Vq -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- --===============0703837251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0703837251==-- From lisp-bounces@ietf.org Tue Jan 20 08:21:57 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6500F3A6B0E; Tue, 20 Jan 2009 08:21:57 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5AB3A6982 for ; Tue, 20 Jan 2009 08:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=-0.218, 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 wlqqS4z9553p for ; Tue, 20 Jan 2009 08:21:55 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 52DD03A6B0E for ; Tue, 20 Jan 2009 08:21:55 -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 n0KGLXNi003297; Tue, 20 Jan 2009 08:21:33 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0KGLXnU003296; Tue, 20 Jan 2009 08:21:33 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 08:21:33 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090120162133.GA2929@1-4-5.net> MIME-Version: 1.0 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] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , Content-Type: multipart/mixed; boundary="===============0456065698==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0456065698== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, I'm being asked (by the IESG) whether people believe that we can go directly to our first WG meeting at the next IETF or if another WG forming BOF is necessary. Here are the current facts on the ground:=20 o We have fairly mature set of core drafts o There are a number of other (non-core) LISP drafts o Significant global deployment is underway o We have 2 or more implementations=20 o We have been discussing a draft charter (see update below) The question is that I would like folks to respond to is =09 "Should a WG be formed following the draft agenda (below), or should we have another BOF?" Please give your opinion as soon as possible so we can close on these administrative issues. Thanks, Dave -- LISP (Locator/ID Separation Protocol) Last Modified: 2009-01-20 Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Secretary(ies): TBD =20 Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: LISP and companion documents (see below) are proposals that respond to the problems discussed at the IAB's October, 2006 Routing and Addressing Workshop [0]. The purpose of the BOF is to form a working group whose charter (see below) is to work on the design on the LISP base protocol [1], the LISP+ALT mapping system [2], LISP Interworking [4] and LISP multicast [6]. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group may also create EID-prefix assignment guidelines for RIRs, as well as security profiles for the ALT (presumably using technology developed in the SIDR working group). 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. Mar 2010 Re-charter or close. Internet-Drafts: draft-farinacci-lisp-11.txt draft-farinacci-lisp-multicast-01.txt draft-fuller-lisp-alt-03.txt draft-lewis-lisp-interworking-02.txt Request For Comments: None References ---------- [0] Meyer, D. et. al., "Report from the IAB Workshop on Routing and Addressing", RFC 4984. [1] Farinacci, D. et. al., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-11.txt. [2] Fuller, V., et. al., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-03.txt [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-00.txt. [4] Lewis, D., et. al., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-02.txt. [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt. [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt. =20 --liOOAslEiF7prFVr 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) iEYEARECAAYFAkl1+g0ACgkQORgD1qCZ2KfN0wCcCSRx0knb1ZTbxGCelH+fF1nK QYkAn2UqiRmehM4StNgHwa1m+LMPeTyb =Qgr+ -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- --===============0456065698== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0456065698==-- From lisp-bounces@ietf.org Tue Jan 20 08:26:21 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F863A69F9; Tue, 20 Jan 2009 08:26:21 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D37EE3A69F9 for ; Tue, 20 Jan 2009 08:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.212, 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 PKJ7xGTgO5k1 for ; Tue, 20 Jan 2009 08:26:20 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 03E8F3A69CD for ; Tue, 20 Jan 2009 08:26:19 -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 n0KGQ3fs003398 for ; Tue, 20 Jan 2009 08:26:04 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0KGQ3l3003397 for lisp@ietf.org; Tue, 20 Jan 2009 08:26:03 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 08:26:03 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090120162603.GA3374@1-4-5.net> MIME-Version: 1.0 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 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: , Content-Type: multipart/mixed; boundary="===============0024419932==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0024419932== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry about that, for some reason the updated version didn't make it into my last email. Here's the update. Dave -- LISP (Locator/ID Separation Protocol) Last Modified: 2009-01-20 Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Secretary(ies): TBD =20 Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: LISP and companion documents (see below) are proposals that respond to the problems discussed at the IAB's October, 2006 Routing and Addressing Workshop [0]. The purpose of the BOF is to form a working group whose charter (see below) is to work on the design on the LISP base protocol [1], the LISP+ALT mapping system [2], LISP Interworking [4] and LISP multicast [6]. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group may also create EID-prefix assignment guidelines for RIRs, as well as security profiles for the ALT (presumably using technology developed in the SIDR working group). 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 Recommendations for Allocation and Routing of both EIDs and RLOCs to the IESG for Experimental. June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG for Experimental. July 2010 Submit LISP for Multicast Environments to the IESG for Experimental.=20 Aug 2010 Re-charter or close. Internet-Drafts: draft-farinacci-lisp-11.txt draft-farinacci-lisp-multicast-01.txt draft-fuller-lisp-alt-03.txt draft-lewis-lisp-interworking-02.txt Request For Comments: None References ---------- [0] Meyer, D. et. al., "Report from the IAB Workshop on Routing and Addressing", RFC 4984. [1] Farinacci, D. et. al., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-09.txt. [2] Fuller, V., et. al., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-03.txt [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-00.txt. [4] Lewis, D., et. al., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-01.txt. [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt. [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt. =20 --lrZ03NoBR/3+SXJZ 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) iEYEARECAAYFAkl1+xsACgkQORgD1qCZ2KfaagCfYaawmJPApfxcvQDXvWZDRENG DhoAnRUDRmQyDpnigCKiwxsgBR2DKRcP =jCOd -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- --===============0024419932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0024419932==-- From lisp-bounces@ietf.org Tue Jan 20 08:41:48 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF2D3A6B0E; Tue, 20 Jan 2009 08:41:48 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817113A6B0E for ; Tue, 20 Jan 2009 08:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=-0.202, 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 IjZYU19yT6bb for ; Tue, 20 Jan 2009 08:41:45 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 819E93A69CD for ; Tue, 20 Jan 2009 08:41:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C4A51430332; Tue, 20 Jan 2009 08:41:29 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-64.clppva.btas.verizon.net [71.161.51.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id E559E430319; Tue, 20 Jan 2009 08:41:28 -0800 (PST) Message-ID: <4975FEB1.7070600@joelhalpern.com> Date: Tue, 20 Jan 2009 11:41:21 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Meyer References: <20090120162133.GA2929@1-4-5.net> In-Reply-To: <20090120162133.GA2929@1-4-5.net> Cc: lisp@ietf.org Subject: Re: [lisp] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Given the target (a WG to produce experimental specificaitons) I can see no benefit in an additional BoF. Joel David Meyer wrote: > Folks, > > I'm being asked (by the IESG) whether people believe > that we can go directly to our first WG meeting at the > next IETF or if another WG forming BOF is necessary. > > Here are the current facts on the ground: > > o We have fairly mature set of core drafts > o There are a number of other (non-core) LISP drafts > o Significant global deployment is underway > o We have 2 or more implementations > o We have been discussing a draft charter (see update below) > > The question is that I would like folks to respond to is > > "Should a WG be formed following the draft agenda > (below), or should we have another BOF?" > > Please give your opinion as soon as possible so we can > close on these administrative issues. > > Thanks, > > Dave > -- > > LISP (Locator/ID Separation Protocol) > > Last Modified: 2009-01-20 > > Chair(s): > TBD > > Internet Area Director(s): > TBD > > Routing Area Advisor: > TBD > > Secretary(ies): > TBD > > Mailing Lists: > General Discussion: lisp@ietf.org > > Description of Working Group: > > LISP and companion documents (see below) are proposals that > respond to the problems discussed at the IAB's October, 2006 > Routing and Addressing Workshop [0]. The purpose of the BOF is to > form a working group whose charter (see below) is to work on the > design on the LISP base protocol [1], the LISP+ALT mapping system > [2], LISP Interworking [4] and LISP multicast [6]. The working > group will encourage and support interoperable LISP > implementations as well as defining requirements for alternate > mapping systems. The Working Group may also create EID-prefix > assignment guidelines for RIRs, as well as security profiles for > the ALT (presumably using technology developed in the SIDR > working group). > > 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. > > Mar 2010 Re-charter or close. > > Internet-Drafts: > draft-farinacci-lisp-11.txt > draft-farinacci-lisp-multicast-01.txt > draft-fuller-lisp-alt-03.txt > draft-lewis-lisp-interworking-02.txt > > Request For Comments: > None > > > References > ---------- > [0] Meyer, D. et. al., "Report from the IAB Workshop on > Routing and Addressing", RFC 4984. > > [1] Farinacci, D. et. al., "Locator/ID Separation Protocol > (LISP)", draft-farinacci-lisp-11.txt. > > [2] Fuller, V., et. al., "LISP Alternative Topology > (LISP-ALT)", draft-fuller-lisp-alt-03.txt > > [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation > Report", draft-iannone-openlisp-implementation-00.txt. > > [4] Lewis, D., et. al., "Interworking LISP with IPv4 and > IPv6", draft-lewis-lisp-interworking-02.txt. > > [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map > identifiers onto locators", draft-mathy-lisp-dht-00.txt. > > [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, > "LISP for Multicast Environments", > draft-farinacci-lisp-multicast-01.txt. > > > ------------------------------------------------------------------------ > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 08:58:46 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2AF3A6A00; Tue, 20 Jan 2009 08:58:46 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2AC3A6A00 for ; Tue, 20 Jan 2009 08:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 KFTy4WhK4s45 for ; Tue, 20 Jan 2009 08:58:44 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 9934F3A69F9 for ; Tue, 20 Jan 2009 08:58:44 -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 n0KGwSro005004; Tue, 20 Jan 2009 08:58:28 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0KGwSST005003; Tue, 20 Jan 2009 08:58:28 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 08:58:28 -0800 From: David Meyer To: "Joel M. Halpern" Message-ID: <20090120165828.GA4977@1-4-5.net> References: <20090120162133.GA2929@1-4-5.net> <4975FEB1.7070600@joelhalpern.com> MIME-Version: 1.0 In-Reply-To: <4975FEB1.7070600@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] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , Content-Type: multipart/mixed; boundary="===============1919476414==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1919476414== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 20, 2009 at 11:41:21AM -0500, Joel M. Halpern wrote: > Given the target (a WG to produce experimental specificaitons) I can see = =20 > no benefit in an additional BoF. Thanks for the input Joel. Dave --3V7upXqbjpZ4EhLz 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) iEYEARECAAYFAkl2ArQACgkQORgD1qCZ2Kd9XACbBGznyR4U5AY+SJcbaXZk2eEv lp8An2Pm0E1LdPG+BSE0bas5oSjgnH/k =9V93 -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- --===============1919476414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1919476414==-- From lisp-bounces@ietf.org Tue Jan 20 09:09:49 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B743A6BE9; Tue, 20 Jan 2009 09:09:49 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230503A6BE9 for ; Tue, 20 Jan 2009 09:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 11M1cGxRNq4D for ; Tue, 20 Jan 2009 09:09:47 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 55D6F3A6B3C for ; Tue, 20 Jan 2009 09:09:47 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 625BA6BE5EF; Tue, 20 Jan 2009 12:09:28 -0500 (EST) To: lisp@ietf.org Message-Id: <20090120170928.625BA6BE5EF@mercury.lcs.mit.edu> Date: Tue, 20 Jan 2009 12:09:28 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > From: David Meyer > I'm being asked (by the IESG) whether people believe > that we can go directly to our first WG meeting at the > next IETF or if another WG forming BOF is necessary. > > ... > > o We have fairly mature set of core drafts > o There are a number of other (non-core) LISP drafts > o Significant global deployment is underway > o We have 2 or more implementations Given that this is more than most WGs have, even some time after they start, I can't see how a second BoF would be any use. (In fact, were I still an AD, I wouldn't even both with one BoF, with this much evidence of interest. The only reason to deny a WG in such circumstances would be if one felt it was a bad direction, techncally, and any number of BoFs wouldn't help you with that question.) Noel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 09:31:42 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A173A6B38; Tue, 20 Jan 2009 09:31:42 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E7528C1F8 for ; Tue, 20 Jan 2009 09:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 VCR5RINzPMpP for ; Tue, 20 Jan 2009 09:31:39 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 92B2328C208 for ; Tue, 20 Jan 2009 09:31:18 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14323724; Tue, 20 Jan 2009 12:30:34 -0500 Message-Id: From: Marshall Eubanks To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-Reply-To: <20090120170928.625BA6BE5EF@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 20 Jan 2009 12:31:02 -0500 References: <20090120170928.625BA6BE5EF@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.930.3) Cc: lisp@ietf.org Subject: Re: [lisp] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org On Jan 20, 2009, at 12:09 PM, Noel Chiappa wrote: >> From: David Meyer > >> I'm being asked (by the IESG) whether people believe >> that we can go directly to our first WG meeting at the >> next IETF or if another WG forming BOF is necessary. >> >> ... >> >> o We have fairly mature set of core drafts >> o There are a number of other (non-core) LISP drafts >> o Significant global deployment is underway >> o We have 2 or more implementations > > Given that this is more than most WGs have, even some time after > they start, > I can't see how a second BoF would be any use. (In fact, were I > still an AD, > I wouldn't even both with one BoF, with this much evidence of > interest. The > only reason to deny a WG in such circumstances would be if one felt > it was a > bad direction, techncally, and any number of BoFs wouldn't help you > with that > question.) I agree with this analysis, and don't think that a second BOF is necessary. Regards Marshall > > > Noel > _______________________________________________ > 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 lisp-bounces@ietf.org Tue Jan 20 10:23:03 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2420A3A6895; Tue, 20 Jan 2009 10:23:03 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E823A6878 for ; Tue, 20 Jan 2009 10:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 IAGL6YFosmj8 for ; Tue, 20 Jan 2009 10:23:00 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 640563A690D for ; Tue, 20 Jan 2009 10:23:00 -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 n0KIMMGR007131; Tue, 20 Jan 2009 10:22:22 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0KIMMpi007130; Tue, 20 Jan 2009 10:22:22 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 10:22:22 -0800 From: David Meyer To: rgaglian@lacnic.net Message-ID: <20090120182222.GA7106@1-4-5.net> References: <20090120162133.GA2929@1-4-5.net> <4975FEB1.7070600@joelhalpern.com> <52393.200.7.85.17.1232470668.squirrel@www.lacnic.net.uy> MIME-Version: 1.0 In-Reply-To: <52393.200.7.85.17.1232470668.squirrel@www.lacnic.net.uy> 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] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , Content-Type: multipart/mixed; boundary="===============1063207887==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1063207887== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 20, 2009 at 02:57:48PM -0200, rgaglian@lacnic.net wrote: > +1 > Roque Thnx Roque. Dave --2oS5YaxWCcQjTEyO 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) iEYEARECAAYFAkl2Fl4ACgkQORgD1qCZ2KcFRwCePDbqIoqRXuEOZ4VavPK0GaCE zE0AnRFCYwY8cMeXl4FDYxs/yNwqAYuW =fOmF -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- --===============1063207887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1063207887==-- From lisp-bounces@ietf.org Tue Jan 20 10:23:15 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E403A690D; Tue, 20 Jan 2009 10:23:15 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3534C3A6878 for ; Tue, 20 Jan 2009 10:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 2asVWcHiZJJp for ; Tue, 20 Jan 2009 10:23:09 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 6961D3A69EA for ; Tue, 20 Jan 2009 10:23:09 -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 n0KIMlpS007159; Tue, 20 Jan 2009 10:22:47 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0KIMkdr007158; Tue, 20 Jan 2009 10:22:46 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 10:22:46 -0800 From: David Meyer To: Noel Chiappa Message-ID: <20090120182246.GB7106@1-4-5.net> References: <20090120170928.625BA6BE5EF@mercury.lcs.mit.edu> MIME-Version: 1.0 In-Reply-To: <20090120170928.625BA6BE5EF@mercury.lcs.mit.edu> 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] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , Content-Type: multipart/mixed; boundary="===============1952633656==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1952633656== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LpQ9ahxlCli8rRTG" Content-Disposition: inline --LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Given that this is more than most WGs have, even some time after they start, > I can't see how a second BoF would be any use. (In fact, were I still an AD, > I wouldn't even both with one BoF, with this much evidence of interest. The > only reason to deny a WG in such circumstances would be if one felt it was a > bad direction, techncally, and any number of BoFs wouldn't help you with that > question.) Thanks Noel. Dave --LpQ9ahxlCli8rRTG 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) iEYEARECAAYFAkl2FnYACgkQORgD1qCZ2KclpQCeJ1KwIVnt9qtbOH4IiNZf99A0 1xUAni3eTg/dxNJNoZC/WodjLTf1Wgue =tho/ -----END PGP SIGNATURE----- --LpQ9ahxlCli8rRTG-- --===============1952633656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1952633656==-- From lisp-bounces@ietf.org Tue Jan 20 10:24:07 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4925B3A6895; Tue, 20 Jan 2009 10:24:07 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6B93A6895 for ; Tue, 20 Jan 2009 10:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 uwfcRZ7HkZHD for ; Tue, 20 Jan 2009 10:24:05 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id EAC593A6878 for ; Tue, 20 Jan 2009 10:24:04 -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 n0KINmF6007216; Tue, 20 Jan 2009 10:23:48 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0KINmbY007215; Tue, 20 Jan 2009 10:23:48 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 10:23:48 -0800 From: David Meyer To: Marshall Eubanks Message-ID: <20090120182348.GD7106@1-4-5.net> References: <20090120170928.625BA6BE5EF@mercury.lcs.mit.edu> MIME-Version: 1.0 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] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , Content-Type: multipart/mixed; boundary="===============1510525645==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1510525645== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jL2BoiuKMElzg3CS" Content-Disposition: inline --jL2BoiuKMElzg3CS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > I agree with this analysis, and don't think that a second BOF is =20 > necessary. Thanks Marshall. Dave --jL2BoiuKMElzg3CS 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) iEYEARECAAYFAkl2FrQACgkQORgD1qCZ2KcSewCbByFOiObnZpVgGELNm1fWw7BU Yt0AnjvTd9ZYeij2fFQ+zXaYgOxN5Nb7 =Vaxo -----END PGP SIGNATURE----- --jL2BoiuKMElzg3CS-- --===============1510525645== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1510525645==-- From lisp-bounces@ietf.org Tue Jan 20 10:26:04 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004EF3A69F9; Tue, 20 Jan 2009 10:26:04 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CA53A69F9 for ; Tue, 20 Jan 2009 10:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 X598IygHQ1pz for ; Tue, 20 Jan 2009 10:26:02 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A633B3A6878 for ; Tue, 20 Jan 2009 10:26:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,295,1231113600"; d="scan'208";a="34335399" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Jan 2009 18:25:41 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0KIPfFd023135; Tue, 20 Jan 2009 13:25:41 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0KIPfdn001755; Tue, 20 Jan 2009 18:25:41 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 13:25:41 -0500 Received: from sbrim-mbp.local ([64.102.8.172]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 13:25:40 -0500 Message-ID: <49761724.8020209@employees.org> Date: Tue, 20 Jan 2009 13:25:40 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: David Meyer References: <20090120162133.GA2929@1-4-5.net> In-Reply-To: <20090120162133.GA2929@1-4-5.net> X-OriginalArrivalTime: 20 Jan 2009 18:25:40.0850 (UTC) FILETIME=[7FBADD20:01C97B2C] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: lisp@ietf.org Subject: Re: [lisp] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org +1. Of course that means we need to get the charter really clear. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 11:08:03 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8A028C105; Tue, 20 Jan 2009 11:08:03 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8678A28C0D6; Tue, 20 Jan 2009 11:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 fA4qXqRudRhN; Tue, 20 Jan 2009 11:08:00 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 987693A6BC6; Tue, 20 Jan 2009 11:08:00 -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 n0KJ7ivw009632; Tue, 20 Jan 2009 11:07:44 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0KJ7iVj009631; Tue, 20 Jan 2009 11:07:44 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 11:07:44 -0800 From: David Meyer To: routing-discussion@ietf.org, int-area@ietf.org Message-ID: <20090120190744.GA9467@1-4-5.net> MIME-Version: 1.0 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] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: multipart/mixed; boundary="===============1056446314==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1056446314== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, The IESG would like to know whether people believe that we can go directly to our first LISP WG meeting at the next IETF, or if another WG forming BOF is necessary. Here are the current facts on the ground: o We have fairly mature set of core drafts o There are a number of other (non-core) LISP drafts o Significant global deployment is underway o We have 2 (or more) implementations o We have been discussing a draft charter (see update below) The question is that I would like folks to respond to is "Should a WG be formed based on the draft agenda (see below), or should we have another BOF?" Please give your opinion as soon as possible so we can close on these administrative issues.=20 Thanks, Dave -- LISP (Locator/ID Separation Protocol) Last Modified: 2009-01-20 Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Secretary(ies): TBD =20 Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: LISP and companion documents (see below) are proposals that respond to the problems discussed at the IAB's October, 2006 Routing and Addressing Workshop [0]. The purpose of the BOF is to form a working group whose charter (see below) is to work on the design on the LISP base protocol [1], the LISP+ALT mapping system [2], LISP Interworking [4] and LISP multicast [6]. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group may also create EID-prefix assignment guidelines for RIRs, as well as security profiles for the ALT (presumably using technology developed in the SIDR working group). 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 Recommendations for Allocation and Routing of both EIDs and RLOCs to the IESG for Experimental. June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG for Experimental. July 2010 Submit LISP for Multicast Environments to the IESG for Experimental.=20 Aug 2010 Re-charter or close. Internet-Drafts: draft-farinacci-lisp-11.txt draft-farinacci-lisp-multicast-01.txt draft-fuller-lisp-alt-03.txt draft-lewis-lisp-interworking-02.txt Request For Comments: None References ---------- [0] Meyer, D. et. al., "Report from the IAB Workshop on Routing and Addressing", RFC 4984. [1] Farinacci, D. et. al., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-11.txt. [2] Fuller, V., et. al., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-03.txt [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-00.txt. [4] Lewis, D., et. al., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-02.txt. [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt. [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt. =20 --DocE+STaALJfprDB 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) iEYEARECAAYFAkl2IQAACgkQORgD1qCZ2Kdx9ACcCA1Bo9YSprY0BmBHElnXUSiM e8YAn3jb6is+hliLQd8OsbXTVU7s5nB1 =3mGu -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- --===============1056446314== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1056446314==-- From lisp-bounces@ietf.org Tue Jan 20 13:12:43 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631543A6804; Tue, 20 Jan 2009 13:12:43 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BAC3A6804 for ; Tue, 20 Jan 2009 13:12:42 -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 5MjNAIaRDSbW for ; Tue, 20 Jan 2009 13:12:41 -0800 (PST) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 544113A67C1 for ; Tue, 20 Jan 2009 13:12:41 -0800 (PST) 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=c6273z+IP47uqzNw98OMMe3VhBw=; b=WghZt68rO7 ewglkZ4nR5ztbjThkGmmdIdEKNbh3GbOPuWRbugKp33LtdUFr4ryOMTudurv9qVJ BvNr4D32pR0TEj7OAxGgiIcm0lPuLZYFU+xp9EOuIXRN3fqEGJQHD0u2HruGr82W 1e9A/BhjRxtO4w8Bvb/h2yAJabUeQtpZ8= 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=GX10N ETdfd6jvhOjZv1Mii9+erFh6CdbERnIEmF0PWm5bYBQtJUMvTeYzcMaN0rTKRhx1 g1lrhzGCeO0X35c1wFW7XEo65jFcsC2scoeLqXipIaUTA1zsf0EZJNIk1ldT2qGd blM+fxkcayzcFjcRqHjJbCl92hRzRD5VdmBFXE= Received: from mbpobo.local (bonaventure.info.ucl.ac.be [130.104.240.230]) (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; Tue, 20 Jan 2009 22:12:08 +0100 (CET) Message-ID: <49763E22.4060400@uclouvain.be> Date: Tue, 20 Jan 2009 22:12:02 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Scott Brim References: <20090120162133.GA2929@1-4-5.net> <49761724.8020209@employees.org> In-Reply-To: <49761724.8020209@employees.org> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 04970CF312.AD282 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] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Scott Brim wrote: > +1. Of course that means we need to get the charter really clear. I agree with the two sentences. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 13:42:50 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E393A697A; Tue, 20 Jan 2009 13:42:49 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22933A6968 for ; Tue, 20 Jan 2009 13:42:48 -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=[AWL=0.000, 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 xnQkb3cR1Y6h for ; Tue, 20 Jan 2009 13:42:47 -0800 (PST) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 2B5213A67C1 for ; Tue, 20 Jan 2009 13:42:47 -0800 (PST) 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=Ho2hwjuNqKHTSvQxzIqRr1L2Rg8=; b=fuj2wfbMdm qsyAa13BhRpsHN8mKxfVXNJGo3Yr6bURGzBkRX/TebaHLt8dDsNCoC+gptMqUC3V j3VjSrscpgZ1rKcf/o+zhoMC+2AGsousNDJDn5PQ4lOm3HKCpR5uT5BN7MpRByoL IbNG7+YwsjkgQGZSSHu7IMjWwZTzy+3iQ= 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=fbfam F22Q1uNtwHgzeZxAKctBbq2Xg3bGQYKuXxHEoosH+Vpr/1xEfBUsASjR1eKCxjpH NzdN9d3qLd7bD7hZzVF9r9o4SkGnqrK7phxPwh761wrBVGUKUNLtdms+eqxDugZW tMseX7hrciMwSy/SjPtUh2naD8MXxJuXNIZ/1w= Received: from mbpobo.local (bonaventure.info.ucl.ac.be [130.104.240.230]) (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; Tue, 20 Jan 2009 22:42:26 +0100 (CET) Message-ID: <4976453C.4020306@uclouvain.be> Date: Tue, 20 Jan 2009 22:42:20 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dino Farinacci References: <49730E98.1030101@uclouvain.be> In-Reply-To: X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 9FC251C8AFF.86BAC 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] Locator liveness problem 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dino, > >> 1- What are the types of failures that we consider and want to be able >> to detect : >> >> a. Failure of an ETR >> >> b. Failure of (one of the link) directly attached to an ETR to its >> provider > > These are covered by the loc-reach-bits and have been in the LISP spec > for quite a long time. I think dating back to the -02 draft. There are some issues with loc-reach-bits that are part of the LISP spec : - The support for more than 31 locators is cumbersome (maybe 31 locoators is sufficient for most deployments, including experimental ones, but I don't think that it's future proof) - They assume that there is an ordering among the ETRs such that each ETR knows the position of all other ETRs in the loc-reach bits. This ordering should be preserved everytime an ETR is added or removed to serve a given EID prefix and the ordering must remain consistent among all ETRs that serve each EID prefix. This issue has not been discussed in details until now. >> c. Failure or misconfiguration of some intermediate links that causes >> some ETR to become unreachable from some ITRs although the ETR and its >> links are up. > > We need to distinguish between the term "reachable" and "alive". And the > mechanisms for "reachability" or "liveness" need to be clearly decoupled > and analyzed independently. Today a BGP router believes a destination is > alive because it is reachable. Being "reachable" here means there is a > route (in the DFZ is it a more specific route and not a default route) > in the local RIB. > > "Liveness" is usally what a ping echo-reply would tell you. And we all > know there is nothing protocol-wise in the core that tests for liveness. > > The reason I say this is because, with good approximation and > probability, a reachable prefix is one that usually is alive. If we > didn't believe that, the Internet wouldn't be reliable today. I agree > So the question I keep challenging people with is, with LISP > loc-reach-bits and BGP route existence (i.e. "reachability"), is this > good enough. Is this enough tools for an ITR to know when to switch > RLOCs. If the ITR is running BGP, I think we are in a good position to > day yes. LISP ETRs will be mainly deployed by stub networks. Consider that AS1 and AS2 are two large T1 ISPs with thousands of stub customers. For scalability reasons, the RLOCs attached to the ETRs of their customers are all inside a large prefix announced by BGP (say 1.0.0.0/16 for AS1 and 2.0.0.0/16 for AS2). In this case, a BGP withdraw will only be sent if the entire RLOC prefix fails, which is unlikely. I'm not sure that BGP gives you mugh more information, unless we expect to see short RLOC prefixes advertised with BGP, which does not scale. > When the ITR is not running BGP, and there are many cases for it not to > run BGP to lower the opex cost of running the ITR on a CPE router, is > there an inadequate reachability capability. That is the question. The target should be xTR without the full BGP routing tables. > I do have some ideas to solve this low-opex ITR case. And they are > light-weight. > >> Failures of type C are the more general, but also the most complex to >> handle. There has been some work on detecting such >> failures/misconfigurations ( see e.g. >> A. Dhamdhere, R. Teixeira, C. Dovrolis, and C. Diot - >> "NetDiagnoser:Troubleshooting network unreachabilities using end-to-end >> probes and routing data", in Proc. of CoNEXT, December 2007 ) >> , but I don't think that we could reliably detect them in a LISP world. >> I would suggest to focus the discussion on failures of type A and type B. > > Those are handled. The paper considers much more general failure cases than the loss of a peering. > The case is where a peering connection goes down and > an alternate path is not available because the transit policy for an > RLOC is quite different than for an EID. That is, a transit ISP cannot > tell it's customer is behind an RLOC supported by another ISP. And the > EID is not known to the core (for good reasons) so we could sever > connectivity which previously was not before we introduced the level of > indirection. > > Having said that, c is the issue at hand here and not a and b. > >> 2- The focus of LISP should be to forward packets despite of failures of >> an ETR or failures of a link that is attached to an ETR and not to >> detect failures. > > But having an alternate path locally and not using could be question of > "a good feature we cannot scale". Sorry, but I don't see why a local alternate cannot scale >> I think that we should also consider network design best practices and >> fast reroute techniques that could allow the EIDs served by the ETR to >> remain reachable although an ETR or a link failed. > > Fast reroute mechanisms in the xTRs? Or, alternately in core, they are > already there. There is also the case how fast the IGP can switch to > another exit ITR. I agree, when the two ETRs that serve an EID prefix are attached to the same provider, then failures can be handled by the provider's IGP. >> First, if a set of EID prefixes is served only by a single-homed ETR, >> then the failure of the ETR or of the link that attaches the ETR to its > > If the site is single homed and the ETR goes down, there is no reason to > fix this, because you cannot. What I mean is that if an EID prefix is served by a single-homed xTR, then there is no need to spend time/packets/cpu to detect the reachability of this xTR. > Just like routers can't switch packets > without the power on. ;-) > > Oh, and others have asked me to make packets go faster than the speed of > light too. ;-) > >> provider will cause a failure of the EID. Such a failure will be >> eventually detected by ICMP destination unreachable messages. This is > > Another comment I have. Can all of us please stop talking about ICMP > Unreachables. We can't rely on them. They are not dependable. They are > off by default in core IOS routers. They are filtered by NATs and other > firewalls. > > All designs should spec that if an Unreachble is received, you can use > it but you can't base a design on using ICMP unreachables. Even if they > were turned on, there are too many security implications. Also, ICMP > unreachables don't contain mask-lengths, so this contributes to it's > unscalablility. I agree that we cannot rely only on ICMP, but we cannot ignore them neither. We should not assume that core routers will send ICMP unreachable, but a PE attached to a CPE could easily send ICMP unreach when the attached CPE fails. ICMP could be off on core routers, but be on or rate limited on edge routers. I agree with the security concern and upon reception of an ICMP unreachable, an ETR should send a probe message to check the unreachability of the ITR's RLOC before considering the RLOC to be unreachable. >> the same case as today when a router attached to a single subnet which >> is part of a larger aggregate fails. In this case, BGP does not inform >> the entire Internet about the failure as the aggregate remains reachable. > > Yes, another problem with Unreachables. > >> Second, we should consider dual-homed ETRs. There are two subcases : >> a- Two ETRs attached to the same provider >> b- Two ETRs attached to different providers >> >> In subcase a, the two ETRs could be configured in anycast so that the >> provider redirects the packets to the other ETR in case of failure of > > That all depends on where in the region of that ISP they connect. An ISP > is not going to want to carry host routes across their core. Other solutions than anycast are possible. >> one ETR or one of its links. >> >> In subcase b, a cooperation among the two providers could ensure that >> the two RLOCs remain reachable even if one of the links or one of the > > There is never cooperation like this between two SPs. My definition of > inter-SP cooperation is agreeing to BGP peer with each other and the > manual exchange of peering addresses. Paying customers can "encourage" network providers to cooperate to provide better/combined services. > This is why the LISP authors think the sweet-spot for a LISP xTR is at > the CPE router. I agree Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 13:55:44 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B81E3A697A; Tue, 20 Jan 2009 13:55:44 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B0F3A697A for ; Tue, 20 Jan 2009 13:55:43 -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=[AWL=0.000, 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 GVj5XQj44a1j for ; Tue, 20 Jan 2009 13:55:42 -0800 (PST) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id F09F73A67C1 for ; Tue, 20 Jan 2009 13:55:41 -0800 (PST) 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=HMR+N9B32Xm9JwwMRLGU35rlngw=; b=RY1jfFXHxH cDLU6jQmfzd7XzBexKA5xIjXdZR7af/X8i10q303Necf19/EDeHBSyaJQ6gRjEsd YhWl3POZnFQloZ+6LLz82WJhp2HK14ITLSrhA3DBZW/TusnrRiUEcg938cREXKjj trFgCFqj8FaZWJcE36R+8Rs8zATpLpI9U= 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=UqTUA rdrv1oIK1v79cg1lg9nZZPNnZdGyvqgkw8twP/DukNI8rKI8YwX6pqefpF1eYRjb lgQkre528bw6BvnEAcUq/SYGNI7z+u+522nkrJlQmFacw/vUCXmaJlJNSbab5qkm 8sRGWEFwkI4A8vFOVRsEzlg6+qEpykoX7gAN7A= Received: from mbpobo.local (ip-83-134-208-192.dsl.scarlet.be [83.134.208.192]) (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; Tue, 20 Jan 2009 22:55:21 +0100 (CET) Message-ID: <49764843.7070109@uclouvain.be> Date: Tue, 20 Jan 2009 22:55:15 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Eliot Lear References: <20090116174412.GA20971@1-4-5.net> <4973AD19.6020706@uclouvain.be> <4974B553.5060203@cisco.com> In-Reply-To: <4974B553.5060203@cisco.com> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: F22EFEDC0C.437C1 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] draft charter for a LISP BOF/WG -- please comment 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Eliot, > On 1/18/09 11:28 PM, Olivier Bonaventure wrote: >> Concerning the locators, an important requirement for the scalability of >> the underlying routing system is that it should be possible to allocate >> locators in a way that follows the network topology. In practice, this >> implies that locators will have a limited lifetime and that all xTR (and >> the supporting services including the mapping system) should be prepared >> for a change of their locator. Locator renumbering should be part of >> the standardised solution from day one. Otherwise, we'll be stuck in the >> same situation as with IPv6 today where renumbering is still not solved >> and network operators are changing the policies of the RIRs to ensure >> that they will not need to renumber. >> >> > > Ok, but what does this mean? The situation that I have in mind is an xTR that serves one EID prefix. This xTR is attached to one router of an ISP. The xTR receives its IP address (V4 and/or v6) by using a protocol similar to DHCP that provides an RLOC and a lifetime. Using such a protocol gives flexibility to the ISP and allows it to renumber its network when needed for scalability reasons. When the xTR's RLOC needs to change, it should be able to use both the oldRLOC and the newRLOC for some time, as with IPv6 today. Ideally, the xTR should be able to update the mapping system autonomously, by sending something similar to the dynamic updates used by DNS. > The difficulty of renumbering is > by-and-large the orders of magnitude of changes that need to occur on > the host level. A 60,000 device network today has to renumber, well, > 60,000 devices in a renumbering event. Of course in LISP those would be > EIDs, and so you wouldn't imagine renumbering them. Renumbering EIDs is outside the scope of LISP Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 14:10:16 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3E93A69FE; Tue, 20 Jan 2009 14:10:16 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464D63A6980; Tue, 20 Jan 2009 14:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.132, 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 H2O8XMFY946t; Tue, 20 Jan 2009 14:10:12 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 905633A688B; Tue, 20 Jan 2009 14:10:12 -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 n0KM9tNf012673; Tue, 20 Jan 2009 14:09:55 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0KM9t6o012672; Tue, 20 Jan 2009 14:09:55 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 14:09:55 -0800 From: David Meyer To: Brian E Carpenter Message-ID: <20090120220955.GB12120@1-4-5.net> References: <20090120190744.GA9467@1-4-5.net> <49763313.904@gmail.com> MIME-Version: 1.0 In-Reply-To: <49763313.904@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: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: multipart/mixed; boundary="===============0003781149==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0003781149== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Brian, > Can you give a little more background on these two points, > for those who aren't following things that closely: >=20 > > o Significant global deployment is underway Check http://www.lisp4.net (IPv4) or http://www.lisp6.net (IPv6). There's a schematic of the global network there. Basically we're trying to get the RIRs to be at the topic level; you'll note that we have RIPE, ARIN, a LACNIC "proxy" (UY), and are working with the APNIC folks. Below that, we're trying to do a kind of regional (contential) aggregation, etc. There are roughly 30 routers deployed, and 5 or 6 are in the pipeline.=20 In addition, there are a growing number of hosts behind the xTRs (i.e., in EID space, either 153.16/16 or 2610:D0:/32), scattered around the planet. For example, the NTT US folks have put up http://lisp4.ameri.ca (v4 only), http://lisp6.ameri.ca (v6 only) or http://lisp.ameri.ca (dual stack).=20 BTW, if you reach www.lisp{4,6}.net (or the mirrors on lispX.ameri.ca) from outside the LISP world, then you are using the Proxy Tunnel Router (PTR) technology described in draft-lewis-lisp-interworking-01.txt (note that the draft has timed out; we'll have an update today or tomorrow, and let me know if you need a copy of -01.txt). If you look at http:/www.translate.lisp4.net, you're using the other interworking technique, LISP translation (i.e., LISP NAT). > > o We have 2 (or more) implementations >=20 > What's the nature of the deployment,=20 Answered above, I think. Let me know if you have other questions.=20 > and am I correct in thinking that only one of the > implementations is from a core router vendor? Sort or. We of course have Dino's implementation. There is also other ongoing LISP work in IOS (still evolving). I don't know about other vendors. You can also find OpenLISP (an open source freebsd LISP implementation) at http://gforge.info.ucl.ac.be/projects/openlisp. We are also actively looking at a Linux OpenLISP port. > Those questions being asked and answered, I don't personally > see that another BOF is called for. The IESG just has to make its > normal assessment of whether the support is broad enough. Thanks for your comments Brian. Very helpful. Dave --4bRzO86E/ozDv8r1 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) iEYEARECAAYFAkl2S7MACgkQORgD1qCZ2KcIpACfagN+ipp+bfukB4oTHZaQadWE h10AoIahSJCTL7K1+rW66LDS/DfJkMS8 =RtRt -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- --===============0003781149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0003781149==-- From lisp-bounces@ietf.org Tue Jan 20 15:37:49 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D582A3A6819; Tue, 20 Jan 2009 15:37:49 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5013A3A6819; Tue, 20 Jan 2009 15:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 HwJXZ4fgc1lJ; Tue, 20 Jan 2009 15:37:47 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D5F3C3A66B4; Tue, 20 Jan 2009 15:37:46 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id E68031986FA; Wed, 21 Jan 2009 01:37:29 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 854951986E2; Wed, 21 Jan 2009 01:37:29 +0200 (EET) Message-ID: <49765FFB.1010709@piuha.net> Date: Wed, 21 Jan 2009 01:36:27 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: int-area@ietf.org References: <20090120190744.GA9467@1-4-5.net> In-Reply-To: <20090120190744.GA9467@1-4-5.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: lisp@ietf.org, routing-discussion@ietf.org, rrg Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org I wanted to provide some background on this question. As you recall, a BOF was held on EXPLISP in Dublin. In Minneapolis we had a number of WGs and the RRG talk about LISP. Implementation and small scale deployment is going on. The RRG is still continuing its work, and they are looking at a number of different solutions, including map-and-encap, translation, host changes, and combinations thereof. I do not want to preempt the RRG's efforts and at this time we are NOT considering any IETF standards in this area. We are, however, potentially interested in working groups targeting experimental specifications so that we can get more experience about the various technical solutions, different people can build systems that work together, etc. Some of you may be familiar with the HIP effort; they also had a working group that produced experimental RFCs to complement the more research oriented work in the IRTF HIP group. My interpretation of the outcome of the first BOF was that the topic was very interesting for the people in the room but that at the time they felt it was more in research than IETF scope. There were also technical debates. That being said, we did not spend enough time on the WG formation question. So I did not view the results as final. Nevertheless, several attempts were made in the autumn to create some form of a subgroup in RRG to do this work. However, the proponents were only interested in a working group. So what is happening now is what we did with many other BOF efforts as well. We got feedback in the BOF, there's been further discussion, and work on various fronts has progressed. Its time to complete the discussion about the fate of this effort. We need to see if additional information or further changes can result in a WG proposal that is acceptable to the community or not. If we can reach a decision on the list, fine, if not I will reserve a second BOF slot for the discussion. I am mindful of the fact that the list discussion may not reach quite the same crowd as a f2f meeting, so unless we get a fairly strong signal in the list we probably need to meet as well. But back to the proposal. In particular, I would like to know how people feel about this work being ready for an (Experimental) IETF WG, what the scope should be, whether the charter is reasonable. And if not, what would make it so. Dave, can you post a summary of changes in the proposed charter since the first BOF? I see that you have already posted some information on what is going on in the implementation front -- that was very useful, thanks. Has there been other significant events since last summer? Jari P.S. Maybe we should reply on just one list from now on. Please use, say, int-area because I do not think everyone's on the lisp list. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 15:40:44 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506913A6A94; Tue, 20 Jan 2009 15:40:44 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4AD3A6A94; Tue, 20 Jan 2009 15:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 oSOkpVQ9kSjG; Tue, 20 Jan 2009 15:40:42 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id D91093A6A8A; Tue, 20 Jan 2009 15:40:41 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14327228; Tue, 20 Jan 2009 18:39:56 -0500 Message-Id: <0C7CE15B-385F-4B67-9238-57790AA68C42@multicasttech.com> From: Marshall Eubanks To: Jari Arkko In-Reply-To: <49765FFB.1010709@piuha.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 20 Jan 2009 18:40:23 -0500 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> X-Mailer: Apple Mail (2.930.3) Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, rrg Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org On Jan 20, 2009, at 6:36 PM, Jari Arkko wrote: > I wanted to provide some background on this question. > > As you recall, a BOF was held on EXPLISP in Dublin. In Minneapolis > we had a number of WGs and the RRG talk about LISP. Implementation > and small scale deployment is going on. The RRG is still continuing > its work, and they are looking at a number of different solutions, > including map-and-encap, translation, host changes, and combinations > thereof. I do not want to preempt the RRG's efforts and at this time > we are NOT considering any IETF standards in this area. We are, > however, potentially interested in working groups targeting > experimental specifications so that we can get more experience about > the various technical solutions, different people can build systems > that work together, etc. Some of you may be familiar with the HIP > effort; they also had a working group that produced experimental > RFCs to complement the more research oriented work in the IRTF HIP > group. > > My interpretation of the outcome of the first BOF was that the topic > was very interesting for the people in the room but that at the time > they felt it was more in research than IETF scope. There were also > technical debates. That being said, we did not spend enough time on > the WG formation question. So I did not view the results as final. > Nevertheless, several attempts were made in the autumn to create > some form of a subgroup in RRG to do this work. However, the > proponents were only interested in a working group. > > So what is happening now is what we did with many other BOF efforts > as well. We got feedback in the BOF, there's been further > discussion, and work on various fronts has progressed. Its time to > complete the discussion about the fate of this effort. We need to > see if additional information or further changes can result in a WG > proposal that is acceptable to the community or not. If we can reach > a decision on the list, Might I ask (given the multiple cross-threading going on in this discussion) whether you specifically mean the lisp@ietf.org list ? If so, can we cut down on the cross-posting ? Regards Marshall > fine, if not I will reserve a second BOF slot for the discussion. I > am mindful of the fact that the list discussion may not reach quite > the same crowd as a f2f meeting, so unless we get a fairly strong > signal in the list we probably need to meet as well. > > But back to the proposal. In particular, I would like to know how > people feel about this work being ready for an (Experimental) IETF > WG, what the scope should be, whether the charter is reasonable. And > if not, what would make it so. > > Dave, can you post a summary of changes in the proposed charter > since the first BOF? I see that you have already posted some > information on what is going on in the implementation front -- that > was very useful, thanks. Has there been other significant events > since last summer? > > Jari > > P.S. Maybe we should reply on just one list from now on. Please use, > say, int-area because I do not think everyone's on the lisp list. > > _______________________________________________ > 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 lisp-bounces@ietf.org Tue Jan 20 17:00:32 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E61928C0F4; Tue, 20 Jan 2009 17:00:32 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732F028C0F4; Tue, 20 Jan 2009 17:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 3ny+111IbG1H; Tue, 20 Jan 2009 17:00:30 -0800 (PST) Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by core3.amsl.com (Postfix) with ESMTP id ACCCE28C0F3; Tue, 20 Jan 2009 17:00:30 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: bensons@savvis.net X-Msg-Ref: server-8.tower-137.messagelabs.com!1232499612!49778227!1 X-StarScan-Version: 6.0.0; banners=savvis.net,-,- X-Originating-IP: [216.91.182.151] Received: (qmail 1696 invoked from network); 21 Jan 2009 01:00:12 -0000 Received: from sl6edge1.savvis.net (HELO SL6EDGE1.savvis.net) (216.91.182.151) by server-8.tower-137.messagelabs.com with RC4-SHA encrypted SMTP; 21 Jan 2009 01:00:12 -0000 Received: from sl6smtp2.savvis.ad.savvis.net (10.12.134.211) by SL6EDGE1.savvis.net (216.91.182.151) with Microsoft SMTP Server id 8.1.291.1; Tue, 20 Jan 2009 19:00:14 -0600 Received: from sl6exchbe1.savvis.ad.savvis.net ([10.12.134.212]) by sl6smtp2.savvis.ad.savvis.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 18:59:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jan 2009 18:59:51 -0600 Message-ID: <4B5ACF3E973474489456A00BD0F707AF0255BCAB@sl6exchbe1.savvis.ad.savvis.net> In-Reply-To: <49765FFB.1010709@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP thread-index: Acl7WCueAHUNAAb5QhyV3CKcjWselQABfvDA References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> From: "Schliesser, Benson" To: Jari Arkko , X-OriginalArrivalTime: 21 Jan 2009 00:59:52.0725 (UTC) FILETIME=[91589450:01C97B63] Cc: lisp@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > Jari Arkko: > > In particular, I would like to know how people > feel about this work being ready for an (Experimental) IETF > WG, what the scope should be, whether the charter is > reasonable. And if not, what would make it so. +1 for an Experimental IETF WG scoped to develop an RFC series on LISP protocol, routing, and addressing. The most recent charter proposed by Dave Meyer looks good to me. Cheers, -Benson This message contains information which may be confidential and/or privileged. Unless you are the intended recipient (or authorized to receive for the intended recipient), you may not read, use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message and any attachment(s) thereto without retaining any copies. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 20 17:14:36 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18DB83A6822; Tue, 20 Jan 2009 17:14:36 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C7F3A6822; Tue, 20 Jan 2009 17:14:35 -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 r+BBmfQJ5CZI; Tue, 20 Jan 2009 17:14:34 -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 8510F3A6885; Tue, 20 Jan 2009 17:14:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,297,1231113600"; d="scan'208";a="129944742" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2009 01:14:18 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n0L1EID1012196; Tue, 20 Jan 2009 17:14:18 -0800 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 n0L1EITg013058; Wed, 21 Jan 2009 01:14:18 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 17:14:18 -0800 Received: from 10.116.77.99 ([10.116.77.99]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Jan 2009 01:14:17 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 20 Jan 2009 20:14:00 -0500 From: byzek To: "Schliesser, Benson" , Jari Arkko , Message-ID: Thread-Topic: [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Thread-Index: Acl7WCueAHUNAAb5QhyV3CKcjWselQABfvDAAAHYv6M= In-Reply-To: <4B5ACF3E973474489456A00BD0F707AF0255BCAB@sl6exchbe1.savvis.ad.savvis.net> Mime-version: 1.0 X-OriginalArrivalTime: 21 Jan 2009 01:14:18.0163 (UTC) FILETIME=[952FF030:01C97B65] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1151; t=1232500458; x=1233364458; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=byzek@cisco.com; z=From:=20byzek=20 |Subject:=20Re=3A=20[lisp]=20[Int-area]=20Please=20respond= 3A=20Questions=20from=20the=20IESG=20as=20to=0A=20whether=20 a=20WG=20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=+BrKSnAQbZSyLoWbGfU2GeFIwluWSSRQg+RYR71CON4=; b=Y5csX/MYJvP9RAodPwmLEsplPiSbXGOsbBJNyMPFTpsXbAN66ZpiEHLP63 hBfAXkT7cEpJfd7ltXBGti9fPgq9Iqqkb0hu5p3l1IrUaPqrE+0Wt/ijhp7t tRYqwbhzyy; Authentication-Results: sj-dkim-4; header.From=byzek@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org On 1/20/09 7:59 PM, "Schliesser, Benson" wrote: > >> Jari Arkko: >> >> In particular, I would like to know how people >> feel about this work being ready for an (Experimental) IETF >> WG, what the scope should be, whether the charter is >> reasonable. And if not, what would make it so. > > +1 for an Experimental IETF WG scoped to develop an RFC series on LISP > protocol, routing, and addressing. > > The most recent charter proposed by Dave Meyer looks good to me. +1 -J > > Cheers, > -Benson > > This message contains information which may be confidential and/or privileged. > Unless you are the intended recipient (or authorized to receive for the > intended recipient), you may not read, use, copy or disclose to anyone the > message or any information contained in the message. If you have received the > message in error, please advise the sender by reply e-mail and delete the > message and any attachment(s) thereto without retaining any copies. > _______________________________________________ > 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 lisp-bounces@ietf.org Tue Jan 20 17:28:10 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43693A6800; Tue, 20 Jan 2009 17:28:10 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D74D3A6800; Tue, 20 Jan 2009 17:28:09 -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=[AWL=-0.001, 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 JfEceUOMZuif; Tue, 20 Jan 2009 17:28:08 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B32EE3A67B6; Tue, 20 Jan 2009 17:28:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,297,1231113600"; d="scan'208,217";a="124266843" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 21 Jan 2009 01:27:52 +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 n0L1RqYY006695; Tue, 20 Jan 2009 17:27:52 -0800 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 n0L1Rq5X020261; Wed, 21 Jan 2009 01:27:52 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); Tue, 20 Jan 2009 17:27:52 -0800 Received: from [10.0.1.4] ([10.21.151.69]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 17:27:51 -0800 In-Reply-To: <4B5ACF3E973474489456A00BD0F707AF0255BCAB@sl6exchbe1.savvis.ad.savvis.net> References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <4B5ACF3E973474489456A00BD0F707AF0255BCAB@sl6exchbe1.savvis.ad.savvis.net> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <0886033D-14EE-4D93-BDB2-E375038D5748@cisco.com> From: John Zwiebel Date: Tue, 20 Jan 2009 15:27:53 -1000 To: "Schliesser, Benson" X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 21 Jan 2009 01:27:52.0053 (UTC) FILETIME=[7A4DB250:01C97B67] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1021; t=1232501272; x=1233365272; 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[Int-area]=20Please=20respond= 3A=20Questions=20from=20the=20IESG=20as=20to=20whether=20a=0 9WG=20forming=09BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=scbHWxqCZk0O+2ENi8W6DAIYCPElzrylOD0G4pJN00I=; b=vvFpZu0gaaOTY4g3VJExdCS83PMDEMhaiIjxAb0wBoSRQ5+oJ7icfkCzYI PW3CjC8c9+5RYN455lQpHDDAY3g4G0c/c34UG7OtWHSUg5AL0ukvUOhTun/n E6YV0A+TYb; Authentication-Results: sj-dkim-2; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: int-area@ietf.org, lisp@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: multipart/mixed; boundary="===============0239152264==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0239152264== Content-Type: multipart/alternative; boundary=Apple-Mail-24-791003285 --Apple-Mail-24-791003285 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Jan 20, 2009, at 2:59 PM, Schliesser, Benson wrote: > > The most recent charter proposed by Dave Meyer looks good to me. > aye --Apple-Mail-24-791003285 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Jan 20, 2009, at 2:59 PM, Schliesser, Benson wrote:


The most recent charter proposed by Dave Meyer looks good to me.



aye
--Apple-Mail-24-791003285-- --===============0239152264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0239152264==-- From lisp-bounces@ietf.org Tue Jan 20 21:19:06 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27EA33A6917; Tue, 20 Jan 2009 21:19:06 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05A23A68B5 for ; Tue, 20 Jan 2009 21:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 gfNMRBITq603 for ; Tue, 20 Jan 2009 21:19:04 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 4640E3A6824 for ; Tue, 20 Jan 2009 21:19:04 -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 n0L5IlBi024034 for ; Tue, 20 Jan 2009 21:18:47 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0L5Ilwj024033 for lisp@ietf.org; Tue, 20 Jan 2009 21:18:47 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 21:18:47 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090121051847.GA24001@1-4-5.net> MIME-Version: 1.0 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] the LISP WG formation discussion has been moved to int-area@ietf.org 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: , Content-Type: multipart/mixed; boundary="===============1209286946==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1209286946== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Jari's decision. Please subscribe over there if you'd like to participate. Dave --8t9RHnE3ZwKMSgU+ 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) iEYEARECAAYFAkl2sDcACgkQORgD1qCZ2Ke17wCeKukYTJEkd6+AqQ4804ZEjuBb /XwAmwZ5iWN7P8nHgCOkZJdD9kx3qcba =wAuy -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- --===============1209286946== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1209286946==-- From lisp-bounces@ietf.org Wed Jan 21 05:03:11 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BB8228C12E; Wed, 21 Jan 2009 05:03:11 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F77228C0E0; Wed, 21 Jan 2009 05:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.311 X-Spam-Level: X-Spam-Status: No, score=-9.311 tagged_above=-999 required=5 tests=[AWL=1.288, BAYES_00=-2.599, 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 KRlfZE+IMmth; Wed, 21 Jan 2009 05:03:03 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EEBDF28C102; Wed, 21 Jan 2009 05:03:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,300,1231113600"; d="scan'208";a="31516743" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Jan 2009 13:02:45 +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 n0LD2jdc028083; Wed, 21 Jan 2009 14:02:45 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0LD2jWH014841; Wed, 21 Jan 2009 13:02:45 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 14:02:45 +0100 Received: from adsl-247-5-fixip.tiscali.ch ([10.61.93.79]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 14:02:45 +0100 Message-ID: <49771CF4.6060609@cisco.com> Date: Wed, 21 Jan 2009 14:02:44 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090119 Shredder/3.0b2pre MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> X-OriginalArrivalTime: 21 Jan 2009 13:02:45.0171 (UTC) FILETIME=[8D56A030:01C97BC8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=458; t=1232542965; x=1233406965; 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[Int-area]=20Please=20respond=3A=20Ques tions=20from=20the=20IESG=20as=20to=20whether=0A=20aWG=20for ming=09BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=vMmuETFXMmHC1HmT2zcPx4M1pfWP2QVRf6S4h5Q+O7A=; b=Y2Joou3z7WQBKkK/jOXNX9IQup1HXt4/yGqGjxrhFjnp6KePUPgyipo0RA NJc1dsaqSFLQBxwfY8EDuD0kQb63+/cgUoy7L8SQ1nZosl6aCwiSp9W6p7uy 4LsBbBLmuR; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > So the question - that is not administrative - boils down imho to: can > we exclusively concentrate on the LISP protocol(s) specifics leaving the > issue of our confidence on the Loc/ID split and associated challenges > open. That question deserves imho a specific discussion that should > happen in the context of a BoF. > I missed the part where anyone said that we should *exclusively* concentrate on LISP. Where/when did that happen? _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 05:16:30 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F07BE3A6924; Wed, 21 Jan 2009 05:16:29 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A503A6924; Wed, 21 Jan 2009 05:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.959 X-Spam-Level: X-Spam-Status: No, score=-5.959 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 HH+GSdYrRayU; Wed, 21 Jan 2009 05:16:27 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 329353A677E; Wed, 21 Jan 2009 05:16:26 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0LDFNOg025334; Wed, 21 Jan 2009 14:15:38 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Jan 2009 14:15:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 14:12:54 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <49771CF4.6060609@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Thread-Index: Acl7yJAu5OemcxrQQFqWqA7aQAT+qwAACOmA References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <49771CF4.6060609@cisco.com> From: "PAPADIMITRIOU Dimitri" To: "Eliot Lear" X-OriginalArrivalTime: 21 Jan 2009 13:15:31.0428 (UTC) FILETIME=[56102A40:01C97BCA] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Eliot: > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Wednesday, January 21, 2009 2:03 PM > To: PAPADIMITRIOU Dimitri > Cc: David Meyer; routing-discussion@ietf.org; > int-area@ietf.org; lisp@ietf.org > Subject: Re: [Int-area] Please respond: Questions from the > IESG as to whether aWG forming BOF is necessary for LISP > > > > So the question - that is not administrative - boils down > > imho to: can we exclusively concentrate on the LISP protocol(s) > > specifics leaving the issue of our confidence on the Loc/ID > > split and associated challenges open. That question deserves > > imho a specific discussion that should happen in the context > > of a BoF. > > I missed the part where anyone said that we should *exclusively* > concentrate on LISP. Where/when did that happen? All items in the charter - see below - are exclusively oriented toward LISP protocols implementation specifics, and interworking: /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 Recommendations for Allocation and Routing / of both EIDs and RLOCs to the IESG for Experimental. / /June 2010 Submit Recommendations for Securing the LISP Mapping / System to the IESG for Experimental. / /July 2010 Submit LISP for Multicast Environments to the IESG for / Experimental. thanks, -dimitri. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 05:56:15 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF65A28C148; Wed, 21 Jan 2009 05:56:15 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E53128C0E5; Wed, 21 Jan 2009 05:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.397 X-Spam-Level: X-Spam-Status: No, score=-9.397 tagged_above=-999 required=5 tests=[AWL=1.202, BAYES_00=-2.599, 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 qG5zj65cSwrZ; Wed, 21 Jan 2009 05:56:13 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A6C983A694F; Wed, 21 Jan 2009 05:56:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,300,1231113600"; d="scan'208";a="31525448" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Jan 2009 13:55:55 +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 n0LDttND029182; Wed, 21 Jan 2009 14:55:55 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0LDttcx007741; Wed, 21 Jan 2009 13:55:55 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 14:55:55 +0100 Received: from adsl-247-5-fixip.tiscali.ch ([10.61.104.93]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 14:55:54 +0100 Message-ID: <4977296A.50502@cisco.com> Date: Wed, 21 Jan 2009 14:55:54 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090119 Shredder/3.0b2pre MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <49771CF4.6060609@cisco.com> <00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> X-OriginalArrivalTime: 21 Jan 2009 13:55:54.0845 (UTC) FILETIME=[FA8840D0:01C97BCF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=405; t=1232546155; x=1233410155; 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[Int-area]=20Please=20respond=3A=20Ques tions=20from=20the=20IESG=20as=20to=20whether=0A=20aWG=20for ming=09BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=ssRe9O5xBgSjvuXW3Uu8MheiyjsrD028+Y5gDLF5JJY=; b=ni/3rB9BfJ208vaj7kYoOFO7XKUiD5HxPOQoiZ5zGvfXDMOrwCA+uUdOn2 EXXlhraLCERzT9VyEzlD2C0JR6q584pRq8X87t6cxl3LUsaR0s1LiPrigtD/ 99XXZJl7Jl; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org On 1/21/09 2:12 PM, PAPADIMITRIOU Dimitri wrote: > All items in the charter - see below - are exclusively oriented toward > LISP protocols implementation specifics, and interworking: > Right. This is a LISP WG. There is nothing stopping anyone from creating another WG, assuming the work warrants it. And again, the output is experimental docs. No standardization choices are being made. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 07:16:37 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAEE03A6BD1; Wed, 21 Jan 2009 07:16:37 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9A63A6973; Wed, 21 Jan 2009 07:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 9mPaBPgVkeXi; Wed, 21 Jan 2009 07:16:35 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 35D8628C102; Wed, 21 Jan 2009 07:15:54 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0LFEw3T028574; Wed, 21 Jan 2009 16:15:03 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Jan 2009 16:14:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 16:11:29 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E25A@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <4977296A.50502@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Thread-Index: Acl7z/0NfBtZ1T/5TOi81M67Be3f8AABxB8A References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <49771CF4.6060609@cisco.com> <00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> <4977296A.50502@cisco.com> From: "PAPADIMITRIOU Dimitri" To: "Eliot Lear" X-OriginalArrivalTime: 21 Jan 2009 15:14:59.0696 (UTC) FILETIME=[06AF0F00:01C97BDB] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Eliot: Dave asked for opinions on usefulness to lead another BoF. Imho there is a pending question that deserves discussion and a BoF is one of the suitable mean to have such discussion and hopefully reach consensus. Your answer seems to state that the activities needed to address the known Loc/ID split challenges would be lead outside LISP WG anyway ... but this does not answer the initial question. Thanks, -d. > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Wednesday, January 21, 2009 2:56 PM > To: PAPADIMITRIOU Dimitri > Cc: David Meyer; routing-discussion@ietf.org; > int-area@ietf.org; lisp@ietf.org > Subject: Re: [Int-area] Please respond: Questions from the > IESG as to whether aWG forming BOF is necessary for LISP > > On 1/21/09 2:12 PM, PAPADIMITRIOU Dimitri wrote: > > All items in the charter - see below - are exclusively > oriented toward > > LISP protocols implementation specifics, and interworking: > > > Right. This is a LISP WG. There is nothing stopping anyone from > creating another WG, assuming the work warrants it. And again, the > output is experimental docs. No standardization choices are > being made. > > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 08:15:44 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C1D28C1EE; Wed, 21 Jan 2009 08:15:44 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8538028C1EC for ; Wed, 21 Jan 2009 08:15:43 -0800 (PST) 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.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 UzbAiqLh7eqj for ; Wed, 21 Jan 2009 08:15:42 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id 14AD528C1EE for ; Wed, 21 Jan 2009 08:15:41 -0800 (PST) Received: from [IPv6:2001:13c7:7001:5000:216:cbff:fe98:665f] (unknown [IPv6:2001:13c7:7001:5000:216:cbff:fe98:665f]) by mail.lacnic.net.uy (Postfix) with ESMTP id 0B6F03084A4; Wed, 21 Jan 2009 14:15:12 -0200 (UYST) Message-Id: From: Roque Gagliano To: David Meyer In-Reply-To: <20090120162603.GA3374@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 21 Jan 2009 14:15:10 -0200 References: <20090120162603.GA3374@1-4-5.net> 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 Cc: lisp@ietf.org Subject: Re: [lisp] updated 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: , Content-Type: multipart/mixed; boundary="===============1558339006==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1558339006== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-48-844240570" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-48-844240570 Content-Type: multipart/alternative; boundary=Apple-Mail-47-844240538 --Apple-Mail-47-844240538 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit David, I wonder if any document should be published on the Management plane for LISP, I am not familiar with experimental documents but we can explore at least some management requirements. roque On Jan 20, 2009, at 2:26 PM, David Meyer wrote: > > Sorry about that, for some reason the updated version > didn't make it into my last email. Here's the update. > > Dave > -- > > > LISP (Locator/ID Separation Protocol) > > Last Modified: 2009-01-20 > > Chair(s): > TBD > > Internet Area Director(s): > TBD > > Routing Area Advisor: > TBD > > Secretary(ies): > TBD > > Mailing Lists: > General Discussion: lisp@ietf.org > > Description of Working Group: > > LISP and companion documents (see below) are proposals that > respond to the problems discussed at the IAB's October, 2006 > Routing and Addressing Workshop [0]. The purpose of the BOF is to > form a working group whose charter (see below) is to work on the > design on the LISP base protocol [1], the LISP+ALT mapping system > [2], LISP Interworking [4] and LISP multicast [6]. The working > group will encourage and support interoperable LISP > implementations as well as defining requirements for alternate > mapping systems. The Working Group may also create EID-prefix > assignment guidelines for RIRs, as well as security profiles for > the ALT (presumably using technology developed in the SIDR > working group). > > 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 Recommendations for Allocation and Routing > of both EIDs and RLOCs to the IESG for Experimental. > > June 2010 Submit Recommendations for Securing the LISP Mapping > System to the IESG for Experimental. > > July 2010 Submit LISP for Multicast Environments to the IESG for > Experimental. > > Aug 2010 Re-charter or close. > > Internet-Drafts: > draft-farinacci-lisp-11.txt > draft-farinacci-lisp-multicast-01.txt > draft-fuller-lisp-alt-03.txt > draft-lewis-lisp-interworking-02.txt > > Request For Comments: > None > > > References > ---------- > [0] Meyer, D. et. al., "Report from the IAB Workshop on > Routing and Addressing", RFC 4984. > > [1] Farinacci, D. et. al., "Locator/ID Separation Protocol > (LISP)", draft-farinacci-lisp-09.txt. > > [2] Fuller, V., et. al., "LISP Alternative Topology > (LISP-ALT)", draft-fuller-lisp-alt-03.txt > > [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation > Report", draft-iannone-openlisp-implementation-00.txt. > > [4] Lewis, D., et. al., "Interworking LISP with IPv4 and > IPv6", draft-lewis-lisp-interworking-01.txt. > > [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map > identifiers onto locators", draft-mathy-lisp-dht-00.txt. > > [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, > "LISP for Multicast Environments", > draft-farinacci-lisp-multicast-01.txt. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-47-844240538 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable David,

I = wonder if any document should be published on the Management plane for = LISP, I am not familiar with experimental documents but we can explore = at least some management = requirements.

roque


=
On Jan 20, 2009, at 2:26 PM, David Meyer wrote:


Sorry about that, for some reason = the updated version
didn't make it into my last = email. Here's the update.

Dave
--


LISP = (Locator/ID Separation Protocol)

Last Modified: = 2009-01-20

Chair(s):
TBD

Internet Area = Director(s):
TBD

Routing Area Advisor:
= TBD

Secretary(ies):
TBD

Mailing Lists:
General = Discussion: lisp@ietf.org

Description of = Working Group:

LISP and companion documents (see below) are = proposals that
respond to the problems discussed at the IAB's = October, 2006
Routing and Addressing Workshop [0]. The purpose of the = BOF is to
form a working group whose charter (see below) is to work = on the
design on the LISP base protocol [1], the LISP+ALT mapping = system
[2], LISP Interworking [4] and LISP multicast [6]. The = working
group will encourage and support interoperable = LISP
implementations as well as defining requirements for = alternate
mapping systems. The Working Group may also create = EID-prefix
assignment guidelines for RIRs, as well as security = profiles for
the ALT (presumably using technology developed in the = SIDR
working group).

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 Recommendations = for Allocation and Routing
 of both EIDs and RLOCs to = the IESG for Experimental.

June 2010 Submit Recommendations for = Securing the LISP Mapping
 System to the IESG for = Experimental.

July 2010 Submit LISP for Multicast Environments to = the IESG for
=  Experimental.

Aug  2010  Re-charter or = close.

Internet-Drafts:
= draft-farinacci-lisp-11.txt
= draft-farinacci-lisp-multicast-01.txt
= draft-fuller-lisp-alt-03.txt
= draft-lewis-lisp-interworking-02.txt

Request For = Comments:
=  None


References
----------
[0] =     Meyer, D. et. al., "Report from the IAB Workshop = on
       Routing and = Addressing", RFC 4984.

[1]     Farinacci, D. = et. al., "Locator/ID Separation Protocol
=        (LISP)", = draft-farinacci-lisp-09.txt.

[2] Fuller, V., et. al., "LISP = Alternative Topology
(LISP-ALT)", = draft-fuller-lisp-alt-03.txt

[3] Iannone, L., and O. Bonaventure, = "OpenLISP Implementation
Report", = draft-iannone-openlisp-implementation-00.txt.

[4] Lewis, = D., et. al., "Interworking LISP with IPv4 and
IPv6", = draft-lewis-lisp-interworking-01.txt.

[5] Mathy, = L., et. al., "LISP-DHT: Towards a DHT to map
= identifiers onto locators", = draft-mathy-lisp-dht-00.txt.

[6] =     Farinacci, D., Meyer, D., Zwiebel, J., and S. = Venaas,
= "LISP for Multicast Environments",
= draft-farinacci-lisp-multicast-01.txt. =  
_______________________________________________
lisp = mailing list
lisp@ietf.org
https://www.ietf.org/m= ailman/listinfo/lisp

= --Apple-Mail-47-844240538-- --Apple-Mail-48-844240570 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) iEYEARECAAYFAkl3Sg8ACgkQnk+WSgHpbO4UxgCguSc/ko0hzR1EcG98IR//leyQ smMAoJMCy3kUI7gwIGwi+vfgebDEBpFG =r/mf -----END PGP SIGNATURE----- --Apple-Mail-48-844240570-- --===============1558339006== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1558339006==-- From lisp-bounces@ietf.org Wed Jan 21 08:18:16 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2650128C1EE; Wed, 21 Jan 2009 08:18:16 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1779128C15F; Wed, 21 Jan 2009 08:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 3FOZtXH0gd9s; Wed, 21 Jan 2009 08:18:14 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 180053A68F3; Wed, 21 Jan 2009 08:18: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 n0LGHjrV001237; Wed, 21 Jan 2009 08:17:45 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0LGHjCT001236; Wed, 21 Jan 2009 08:17:45 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 21 Jan 2009 08:17:45 -0800 From: David Meyer To: PAPADIMITRIOU Dimitri Message-ID: <20090121161745.GA907@1-4-5.net> References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> MIME-Version: 1.0 In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.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: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for 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: , Content-Type: multipart/mixed; boundary="===============1595319625==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1595319625== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dimitri, > The task consisting in discovering by experimentation architectural fit > (wrt initial objectives) and complement understanding wrt known > challenges (mapping, caching, loc.reachability, impact on traffic > spatio-temporal properties) is very different in nature than ensuring > interoperability among protocols, minimize operational impact, and > facilitate integration/deployability -> so requiring different type of > efforts with different timelines. As a matter of fact, both types of > activities are still required imho.=20 >=20 > So the question - that is not administrative - boils down imho to: can > we exclusively concentrate on the LISP protocol(s) specifics leaving the > issue of our confidence on the Loc/ID split and associated challenges > open. That question deserves imho a specific discussion that should > happen in the context of a BoF.=20 The purpose of this WG would be to take the *LISP* documents to EXPERIMENTAL. That is what I had in mind when I wrote the charter, and I believe that it is pretty clear on this point. That is not to say it the charter can't be further tightened (I'm sure it can). A you know, WGs need to be tightly focused, especially in the case of protocol groups. I'll grant you that my experience with WGs in the OPs area are somewhat more open-ended (at least mine have been), but it seems unlikely that an IETF WG could successfully produce both tight protocol specs and broad architectural surveys and analyzes. In fact, I can't think of a case in which this has been done in the IETF (perhaps there is one, but it doesn't readily come to mind). Add to that that LISP is clearly in an engineering and deployment phase, coupled with the fact that producing engineering specs what the IETF is good at (well, that is the IETF does), and one sees that finishing up the LISP specs in the IETF seems only natural. That said, it is a fine thing for the RRG to continue to do what its doing, and further, the document you've been describing on the RRG list should continue to progress (IMO of course). In fact, these activities are completely complementary. So keep up the good work. Just one point on your argument: > So the question - that is not administrative - boils down imho to: can > we exclusively concentrate on the LISP protocol(s) specifics leaving the > issue of our confidence on the Loc/ID split and associated challenges > open. That question deserves imho a specific discussion that should > happen in the context of a BoF.=20 It would seem that one could apply the same argument to SHIM6, HIP, SCTP, and several other protocols that have been or are being standardized. So my question to you is: (i). Given your argument above, do you believe that say, the SHIM6 WG should not have been chartered (or perhaps that the SIGTRAN WG, which produced RFCs 4960 and 3286) should not have been chartered? Clearly they did not have such an analysis, or we wouldn't be talking about doing it now (and again, that is not to say there isn't a ton of literature on loc/id split). (ii). If on the other hand you believe that, say SHIM6 should have been chartered, the question is why (again, given your argument above)?=20 Note that I'm not taking a stand on this either way. Rather, I'm just following the logic of your argument.=20 Dave --Kj7319i9nmIyA2yE 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) iEYEARECAAYFAkl3SqkACgkQORgD1qCZ2KesNACdEB55Ad2uqsOFniD2RhKdyYdP fU8AoIb7mPNis9z5nq3wyo6WOOuiq46q =jJNd -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- --===============1595319625== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1595319625==-- From lisp-bounces@ietf.org Wed Jan 21 08:19:08 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF40A28C1E4; Wed, 21 Jan 2009 08:19:08 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BAED28C1ED for ; Wed, 21 Jan 2009 08:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 hOSX-4Jfp-pr for ; Wed, 21 Jan 2009 08:19:07 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id EF5713A6A7C for ; Wed, 21 Jan 2009 08:19:06 -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 n0LGIouY001280; Wed, 21 Jan 2009 08:18:50 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0LGIoCt001279; Wed, 21 Jan 2009 08:18:50 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 21 Jan 2009 08:18:50 -0800 From: David Meyer To: Roque Gagliano Message-ID: <20090121161850.GB907@1-4-5.net> References: <20090120162603.GA3374@1-4-5.net> MIME-Version: 1.0 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] updated 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: , Content-Type: multipart/mixed; boundary="===============1117702567==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1117702567== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable HEy Roque, > I wonder if any document should be published on the Management plane for= =20 > LISP, I am not familiar with experimental documents but we can explore at= =20 > least some management requirements. Sure. Are you interested in authoring/co-authoring such a document? That would be great if so. Dave --ADZbWkCsHQ7r3kzd 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) iEYEARECAAYFAkl3SuoACgkQORgD1qCZ2KdmogCgkaUuPWldlcWNSiqCAIWnhlge jwkAnR1t9uIkYjArMj0P1rxGzAOnt39L =MqkZ -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd-- --===============1117702567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1117702567==-- From lisp-bounces@ietf.org Wed Jan 21 08:21:30 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D85B28C1F6; Wed, 21 Jan 2009 08:21:30 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9865C3A6A00 for ; Tue, 20 Jan 2009 08:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=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 H+nL6dCUGZ8V for ; Tue, 20 Jan 2009 08:58:13 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id 267413A69F9 for ; Tue, 20 Jan 2009 08:58:12 -0800 (PST) Received: from www.lacnic.net.uy (localhost [IPv6:::1]) by mail.lacnic.net.uy (Postfix) with ESMTP id 6CA3630846D; Tue, 20 Jan 2009 14:57:48 -0200 (UYST) Received: from 200.7.85.17 (SquirrelMail authenticated user rgaglian) by www.lacnic.net.uy with HTTP; Tue, 20 Jan 2009 14:57:48 -0200 (UYST) Message-ID: <52393.200.7.85.17.1232470668.squirrel@www.lacnic.net.uy> In-Reply-To: <4975FEB1.7070600@joelhalpern.com> References: <20090120162133.GA2929@1-4-5.net> <4975FEB1.7070600@joelhalpern.com> Date: Tue, 20 Jan 2009 14:57:48 -0200 (UYST) From: rgaglian@lacnic.net To: "Joel M. Halpern" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal 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: rgaglian@lacnic.net X-Mailman-Approved-At: Wed, 21 Jan 2009 08:21:28 -0800 Cc: lisp@ietf.org Subject: Re: [lisp] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org +1 Roque > Given the target (a WG to produce experimental specificaitons) I can see > no benefit in an additional BoF. > > Joel > > David Meyer wrote: >> Folks, >> >> I'm being asked (by the IESG) whether people believe >> that we can go directly to our first WG meeting at the >> next IETF or if another WG forming BOF is necessary. >> >> Here are the current facts on the ground: >> >> o We have fairly mature set of core drafts >> o There are a number of other (non-core) LISP drafts >> o Significant global deployment is underway >> o We have 2 or more implementations >> o We have been discussing a draft charter (see update below) >> >> The question is that I would like folks to respond to is >> >> "Should a WG be formed following the draft agenda >> (below), or should we have another BOF?" >> >> Please give your opinion as soon as possible so we can >> close on these administrative issues. >> >> Thanks, >> >> Dave >> -- >> >> LISP (Locator/ID Separation Protocol) >> >> Last Modified: 2009-01-20 >> >> Chair(s): >> TBD >> >> Internet Area Director(s): >> TBD >> >> Routing Area Advisor: >> TBD >> >> Secretary(ies): >> TBD >> >> Mailing Lists: >> General Discussion: lisp@ietf.org >> >> Description of Working Group: >> >> LISP and companion documents (see below) are proposals that >> respond to the problems discussed at the IAB's October, 2006 >> Routing and Addressing Workshop [0]. The purpose of the BOF is to >> form a working group whose charter (see below) is to work on the >> design on the LISP base protocol [1], the LISP+ALT mapping system >> [2], LISP Interworking [4] and LISP multicast [6]. The working >> group will encourage and support interoperable LISP >> implementations as well as defining requirements for alternate >> mapping systems. The Working Group may also create EID-prefix >> assignment guidelines for RIRs, as well as security profiles for >> the ALT (presumably using technology developed in the SIDR >> working group). >> >> 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. >> >> Mar 2010 Re-charter or close. >> >> Internet-Drafts: >> draft-farinacci-lisp-11.txt >> draft-farinacci-lisp-multicast-01.txt >> draft-fuller-lisp-alt-03.txt >> draft-lewis-lisp-interworking-02.txt >> >> Request For Comments: >> None >> >> >> References >> ---------- >> [0] Meyer, D. et. al., "Report from the IAB Workshop on >> Routing and Addressing", RFC 4984. >> >> [1] Farinacci, D. et. al., "Locator/ID Separation Protocol >> (LISP)", draft-farinacci-lisp-11.txt. >> >> [2] Fuller, V., et. al., "LISP Alternative Topology >> (LISP-ALT)", draft-fuller-lisp-alt-03.txt >> >> [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation >> Report", draft-iannone-openlisp-implementation-00.txt. >> >> [4] Lewis, D., et. al., "Interworking LISP with IPv4 and >> IPv6", draft-lewis-lisp-interworking-02.txt. >> >> [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map >> identifiers onto locators", draft-mathy-lisp-dht-00.txt. >> >> [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, >> "LISP for Multicast Environments", >> draft-farinacci-lisp-multicast-01.txt. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 08:21:30 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B616728C204; Wed, 21 Jan 2009 08:21:30 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EE13A697A; Tue, 20 Jan 2009 12:25:26 -0800 (PST) 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 WoN5eyTI58mC; Tue, 20 Jan 2009 12:25:22 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 958583A684B; Tue, 20 Jan 2009 12:25:16 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3870646wfd.31 for ; Tue, 20 Jan 2009 12:25:00 -0800 (PST) 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=T+2XjFCm55wQxOKnmKbw/zlqX8jt3M/R37Qgqjm/Vuo=; b=kdDUm9rRiqcPmZlE/Xet0V0hULg20pxN9eQxvDJ8428tFiTXwEJY8f8QjVh4PAH5m+ ggtlILs0998ahFbw5Wq4ypt6TNykc7zeuDRLOgCzAuEtD8EIcqKTKHO+4QfxBBfb5DqL wgpc/ULGX/USTPA8jWIAGjjPmtjrm5viqOqwU= 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=h4DB+syqGUB5HiYTr/T56niiySzNRv9CUJfURnnG3u2D4f00g+4STiOcbT2pMLVcfI CGp9uLua9PdleSAKeT9sitCtVMGVJalKev9NnEyQckz5g/Sf3uJxLtAgjK7z9PWmEGKg HR99oC3/IHyQ4vGhfNLrgsap7m+BF4wxwcdSE= Received: by 10.142.154.14 with SMTP id b14mr3004939wfe.69.1232483100236; Tue, 20 Jan 2009 12:25:00 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 30sm14495222wfc.55.2009.01.20.12.24.58 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jan 2009 12:24:59 -0800 (PST) Message-ID: <49763313.904@gmail.com> Date: Wed, 21 Jan 2009 09:24:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Meyer References: <20090120190744.GA9467@1-4-5.net> In-Reply-To: <20090120190744.GA9467@1-4-5.net> X-Mailman-Approved-At: Wed, 21 Jan 2009 08:21:28 -0800 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dave, Can you give a little more background on these two points, for those who aren't following things that closely: > o Significant global deployment is underway > o We have 2 (or more) implementations What's the nature of the deployment, and am I correct in thinking that only one of the implementations is from a core router vendor? Those questions being asked and answered, I don't personally see that another BOF is called for. The IESG just has to make its normal assessment of whether the support is broad enough. Thanks Brian _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 08:21:30 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D250628C20A; Wed, 21 Jan 2009 08:21:30 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B373A6A50; Tue, 20 Jan 2009 14:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[AWL=-1.048, 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 lqGDW9MGzYT7; Tue, 20 Jan 2009 14:17:02 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0B9C73A6A7C; Tue, 20 Jan 2009 14:16:01 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0KMFLH0027161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jan 2009 23:15:21 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0KMFLeX018122; Tue, 20 Jan 2009 23:15:21 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 23:15:20 +0100 Received: from 10.162.95.252 ([10.162.95.252]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Jan 2009 22:15:19 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 21 Jan 2009 00:15:16 +0200 From: "Soininen, Jonne (NSN - FI/Espoo)" To: ext David Meyer , , Message-ID: Thread-Topic: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Thread-Index: Acl7TJJbxsRTuUSxZ0S5yflqK+J+Qw== In-Reply-To: <20090120190744.GA9467@1-4-5.net> Mime-version: 1.0 X-OriginalArrivalTime: 20 Jan 2009 22:15:20.0611 (UTC) FILETIME=[951B8730:01C97B4C] X-Mailman-Approved-At: Wed, 21 Jan 2009 08:21:28 -0800 Cc: lisp@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Hi, I am sorry if I'm a bit lost here. Perhaps I just haven't paid enough attention. Did the RRG conclude and decide to take LISP or is this a parallel activity? If this is a parallel activity what is the intended connection to the RRG work? Sorry for the perhaps simple questions and thanks for the answers in advance! Cheers, Jonne. On 1/20/09 9:07 PM, "ext David Meyer" wrote: > > Folks, > > The IESG would like to know whether people believe that > we can go directly to our first LISP WG meeting at the > next IETF, or if another WG forming BOF is necessary. > > Here are the current facts on the ground: > > o We have fairly mature set of core drafts > o There are a number of other (non-core) LISP drafts > o Significant global deployment is underway > o We have 2 (or more) implementations > o We have been discussing a draft charter (see update below) > > The question is that I would like folks to respond to is > "Should a WG be formed based on the draft agenda > (see below), or should we have another BOF?" > > Please give your opinion as soon as possible so we can > close on these administrative issues. > > Thanks, > > Dave > -- > > LISP (Locator/ID Separation Protocol) > > Last Modified: 2009-01-20 > > Chair(s): > TBD > > Internet Area Director(s): > TBD > > Routing Area Advisor: > TBD > > Secretary(ies): > TBD > > Mailing Lists: > General Discussion: lisp@ietf.org > > Description of Working Group: > > LISP and companion documents (see below) are proposals that > respond to the problems discussed at the IAB's October, 2006 > Routing and Addressing Workshop [0]. The purpose of the BOF is to > form a working group whose charter (see below) is to work on the > design on the LISP base protocol [1], the LISP+ALT mapping system > [2], LISP Interworking [4] and LISP multicast [6]. The working > group will encourage and support interoperable LISP > implementations as well as defining requirements for alternate > mapping systems. The Working Group may also create EID-prefix > assignment guidelines for RIRs, as well as security profiles for > the ALT (presumably using technology developed in the SIDR > working group). > > 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 Recommendations for Allocation and Routing > of both EIDs and RLOCs to the IESG for Experimental. > > June 2010 Submit Recommendations for Securing the LISP Mapping > System to the IESG for Experimental. > > July 2010 Submit LISP for Multicast Environments to the IESG for > Experimental. > > Aug 2010 Re-charter or close. > > Internet-Drafts: > draft-farinacci-lisp-11.txt > draft-farinacci-lisp-multicast-01.txt > draft-fuller-lisp-alt-03.txt > draft-lewis-lisp-interworking-02.txt > > Request For Comments: > None > > > References > ---------- > [0] Meyer, D. et. al., "Report from the IAB Workshop on > Routing and Addressing", RFC 4984. > > [1] Farinacci, D. et. al., "Locator/ID Separation Protocol > (LISP)", draft-farinacci-lisp-11.txt. > > [2] Fuller, V., et. al., "LISP Alternative Topology > (LISP-ALT)", draft-fuller-lisp-alt-03.txt > > [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation > Report", draft-iannone-openlisp-implementation-00.txt. > > [4] Lewis, D., et. al., "Interworking LISP with IPv4 and > IPv6", draft-lewis-lisp-interworking-02.txt. > > [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map > identifiers onto locators", draft-mathy-lisp-dht-00.txt. > > [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, > "LISP for Multicast Environments", > draft-farinacci-lisp-multicast-01.txt. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: jonne.soininen@nsn.com _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 08:21:30 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E864E28C20E; Wed, 21 Jan 2009 08:21:30 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4E63A6AD3; Wed, 21 Jan 2009 02:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.744 X-Spam-Level: X-Spam-Status: No, score=-5.744 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 Ij+x5C994IdH; Wed, 21 Jan 2009 02:56:04 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 1ED323A6AC3; Wed, 21 Jan 2009 02:56:03 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0LAsxLU015790; Wed, 21 Jan 2009 11:55:11 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Jan 2009 11:55:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 11:55:06 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20090120190744.GA9467@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Thread-Index: Acl7MmYdwA1jN8PMRB6Va33wRPeOxgAes9QA References: <20090120190744.GA9467@1-4-5.net> From: "PAPADIMITRIOU Dimitri" To: "David Meyer" , , X-OriginalArrivalTime: 21 Jan 2009 10:55:05.0592 (UTC) FILETIME=[B7DF9F80:01C97BB6] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Mailman-Approved-At: Wed, 21 Jan 2009 08:21:28 -0800 Cc: lisp@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dave, The task consisting in discovering by experimentation architectural fit (wrt initial objectives) and complement understanding wrt known challenges (mapping, caching, loc.reachability, impact on traffic spatio-temporal properties) is very different in nature than ensuring interoperability among protocols, minimize operational impact, and facilitate integration/deployability -> so requiring different type of efforts with different timelines. As a matter of fact, both types of activities are still required imho. So the question - that is not administrative - boils down imho to: can we exclusively concentrate on the LISP protocol(s) specifics leaving the issue of our confidence on the Loc/ID split and associated challenges open. That question deserves imho a specific discussion that should happen in the context of a BoF. Thanks, -dimitri. > -----Original Message----- > From: int-area-bounces@ietf.org > [mailto:int-area-bounces@ietf.org] On Behalf Of David Meyer > Sent: Tuesday, January 20, 2009 8:08 PM > To: routing-discussion@ietf.org; int-area@ietf.org > Cc: lisp@ietf.org > Subject: [Int-area] Please respond: Questions from the IESG > as to whether aWG forming BOF is necessary for LISP > > > Folks, > > The IESG would like to know whether people believe that > we can go directly to our first LISP WG meeting at the > next IETF, or if another WG forming BOF is necessary. > > Here are the current facts on the ground: > > o We have fairly mature set of core drafts > o There are a number of other (non-core) LISP drafts > o Significant global deployment is underway > o We have 2 (or more) implementations > o We have been discussing a draft charter (see update below) > > The question is that I would like folks to respond to is > "Should a WG be formed based on the draft agenda > (see below), or should we have another BOF?" > > Please give your opinion as soon as possible so we can > close on these administrative issues. > > Thanks, > > Dave > -- > > LISP (Locator/ID Separation Protocol) > > Last Modified: 2009-01-20 > > Chair(s): > TBD > > Internet Area Director(s): > TBD > > Routing Area Advisor: > TBD > > Secretary(ies): > TBD > > Mailing Lists: > General Discussion: lisp@ietf.org > > Description of Working Group: > > LISP and companion documents (see below) are proposals that > respond to the problems discussed at the IAB's October, 2006 > Routing and Addressing Workshop [0]. The purpose of the BOF is to > form a working group whose charter (see below) is to work on the > design on the LISP base protocol [1], the LISP+ALT mapping system > [2], LISP Interworking [4] and LISP multicast [6]. The working > group will encourage and support interoperable LISP > implementations as well as defining requirements for alternate > mapping systems. The Working Group may also create EID-prefix > assignment guidelines for RIRs, as well as security profiles for > the ALT (presumably using technology developed in the SIDR > working group). > > 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 Recommendations for Allocation and Routing > of both EIDs and RLOCs to the IESG for Experimental. > > June 2010 Submit Recommendations for Securing the LISP Mapping > System to the IESG for Experimental. > > July 2010 Submit LISP for Multicast Environments to the IESG for > Experimental. > > Aug 2010 Re-charter or close. > > Internet-Drafts: > draft-farinacci-lisp-11.txt > draft-farinacci-lisp-multicast-01.txt > draft-fuller-lisp-alt-03.txt > draft-lewis-lisp-interworking-02.txt > > Request For Comments: > None > > > References > ---------- > [0] Meyer, D. et. al., "Report from the IAB Workshop on > Routing and Addressing", RFC 4984. > > [1] Farinacci, D. et. al., "Locator/ID Separation Protocol > (LISP)", draft-farinacci-lisp-11.txt. > > [2] Fuller, V., et. al., "LISP Alternative Topology > (LISP-ALT)", draft-fuller-lisp-alt-03.txt > > [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation > Report", draft-iannone-openlisp-implementation-00.txt. > > [4] Lewis, D., et. al., "Interworking LISP with IPv4 and > IPv6", draft-lewis-lisp-interworking-02.txt. > > [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map > identifiers onto locators", draft-mathy-lisp-dht-00.txt. > > [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, > "LISP for Multicast Environments", > draft-farinacci-lisp-multicast-01.txt. > > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 08:21:31 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D32728C212; Wed, 21 Jan 2009 08:21:31 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7B628C102; Wed, 21 Jan 2009 04:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.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_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 9oiClpe7KwST; Wed, 21 Jan 2009 04:56:42 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id C1DF728C0E0; Wed, 21 Jan 2009 04:56:41 -0800 (PST) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 13:56:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 13:56:21 +0100 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE0813AFB1@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG as to whetheraWG forming BOF is necessary for LISP thread-index: Acl7MmYdwA1jN8PMRB6Va33wRPeOxgAes9QAAAZ0aRA= References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> From: To: , , , X-OriginalArrivalTime: 21 Jan 2009 12:56:22.0187 (UTC) FILETIME=[A90FE7B0:01C97BC7] X-Mailman-Approved-At: Wed, 21 Jan 2009 08:21:28 -0800 Cc: lisp@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whetheraWG forming BOF is necessary for 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Hi floks, I support Dimitri's position. Furthermore, sorry in case I missed it but I would really like to have an a= nswer on Jonne's point regarding RRG conclusions and decisions regarding LI= SP. I would guess that the answer will have links to the points raised by D= imitri and which, IINM, were the controversial part of the last explisp BOF. -- Greg > -----Message d'origine----- > De : routing-discussion-bounces@ietf.org = > [mailto:routing-discussion-bounces@ietf.org] De la part de = > PAPADIMITRIOU Dimitri > Envoy=E9 : mercredi 21 janvier 2009 11:55 > =C0 : David Meyer; routing-discussion@ietf.org; int-area@ietf.org > Cc : lisp@ietf.org > Objet : RE: [Int-area] Please respond: Questions from the = > IESG as to whetheraWG forming BOF is necessary for LISP > = > Dave, > = > The task consisting in discovering by experimentation = > architectural fit (wrt initial objectives) and complement = > understanding wrt known challenges (mapping, caching, = > loc.reachability, impact on traffic spatio-temporal = > properties) is very different in nature than ensuring = > interoperability among protocols, minimize operational = > impact, and facilitate integration/deployability -> so = > requiring different type of efforts with different timelines. = > As a matter of fact, both types of activities are still = > required imho. = > = > So the question - that is not administrative - boils down = > imho to: can we exclusively concentrate on the LISP = > protocol(s) specifics leaving the issue of our confidence on = > the Loc/ID split and associated challenges open. That = > question deserves imho a specific discussion that should = > happen in the context of a BoF. = > = > Thanks, > -dimitri. > = > = > = > > -----Original Message----- > > From: int-area-bounces@ietf.org > > [mailto:int-area-bounces@ietf.org] On Behalf Of David Meyer > > Sent: Tuesday, January 20, 2009 8:08 PM > > To: routing-discussion@ietf.org; int-area@ietf.org > > Cc: lisp@ietf.org > > Subject: [Int-area] Please respond: Questions from the IESG as to = > > whether aWG forming BOF is necessary for LISP > > = > > = > > Folks, > > = > > The IESG would like to know whether people believe that > > we can go directly to our first LISP WG meeting at the > > next IETF, or if another WG forming BOF is necessary. > > = > > Here are the current facts on the ground: > > = > > o We have fairly mature set of core drafts > > o There are a number of other (non-core) LISP drafts > > o Significant global deployment is underway > > o We have 2 (or more) implementations > > o We have been discussing a draft charter (see update below) > > = > > The question is that I would like folks to respond to is > > "Should a WG be formed based on the draft agenda > > (see below), or should we have another BOF?" > > = > > Please give your opinion as soon as possible so we can > > close on these administrative issues. = > > = > > Thanks, > > = > > Dave > > -- > > = > > LISP (Locator/ID Separation Protocol) > > = > > Last Modified: 2009-01-20 > > = > > Chair(s): > > TBD > > = > > Internet Area Director(s): > > TBD > > = > > Routing Area Advisor: > > TBD > > = > > Secretary(ies): > > TBD > > = > > Mailing Lists: > > General Discussion: lisp@ietf.org > > = > > Description of Working Group: > > = > > LISP and companion documents (see below) are proposals that = > respond to = > > the problems discussed at the IAB's October, 2006 Routing and = > > Addressing Workshop [0]. The purpose of the BOF is to form = > a working = > > group whose charter (see below) is to work on the design on = > the LISP = > > base protocol [1], the LISP+ALT mapping system [2], LISP = > Interworking = > > [4] and LISP multicast [6]. The working group will encourage and = > > support interoperable LISP implementations as well as defining = > > requirements for alternate mapping systems. The Working = > Group may also = > > create EID-prefix assignment guidelines for RIRs, as well = > as security = > > profiles for the ALT (presumably using technology developed in the = > > SIDR working group). > > = > > 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 Recommendations for Allocation and Routing > > of both EIDs and RLOCs to the IESG for Experimental. > > = > > June 2010 Submit Recommendations for Securing the LISP Mapping > > System to the IESG for Experimental. > > = > > July 2010 Submit LISP for Multicast Environments to the IESG for > > Experimental. = > > = > > Aug 2010 Re-charter or close. > > = > > Internet-Drafts: > > draft-farinacci-lisp-11.txt > > draft-farinacci-lisp-multicast-01.txt > > draft-fuller-lisp-alt-03.txt > > draft-lewis-lisp-interworking-02.txt > > = > > Request For Comments: > > None > > = > > = > > References > > ---------- > > [0] Meyer, D. et. al., "Report from the IAB Workshop on > > Routing and Addressing", RFC 4984. > > = > > [1] Farinacci, D. et. al., "Locator/ID Separation Protocol > > (LISP)", draft-farinacci-lisp-11.txt. > > = > > [2] Fuller, V., et. al., "LISP Alternative Topology > > (LISP-ALT)", draft-fuller-lisp-alt-03.txt > > = > > [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation > > Report", draft-iannone-openlisp-implementation-00.txt. > > = > > [4] Lewis, D., et. al., "Interworking LISP with IPv4 and > > IPv6", draft-lewis-lisp-interworking-02.txt. > > = > > [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map > > identifiers onto locators", draft-mathy-lisp-dht-00.txt. > > = > > [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, > > "LISP for Multicast Environments", > > draft-farinacci-lisp-multicast-01.txt. = > > = > > = > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > = _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 08:29:45 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4823A6A7C; Wed, 21 Jan 2009 08:29:45 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DE03A6A7C; Wed, 21 Jan 2009 08:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.114 X-Spam-Level: X-Spam-Status: No, score=-6.114 tagged_above=-999 required=5 tests=[AWL=-0.115, 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 oYSnpHtVY+M8; Wed, 21 Jan 2009 08:29:43 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 3C3AB3A699F; Wed, 21 Jan 2009 08:28:57 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSXdNNSZKlUITEIBeBErQ9D7Uhhmltqbt@postini.com; Wed, 21 Jan 2009 08:29:27 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Wed, 21 Jan 2009 08:27:01 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 08:27:00 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 08:27:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 11:26:58 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C05858248@emailwf1.jnpr.net> In-Reply-To: <4977296A.50502@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Thread-Index: Acl70AUsSpxB621FTRaYt7B8xx4dcQADxpgQ References: <20090120190744.GA9467@1-4-5.net><00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com><49771CF4.6060609@cisco.com><00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> <4977296A.50502@cisco.com> From: Ross Callon To: "Eliot Lear" , "PAPADIMITRIOU Dimitri" , "David Meyer" X-OriginalArrivalTime: 21 Jan 2009 16:27:00.0119 (UTC) FILETIME=[15DB4A70:01C97BE5] Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org In order to make an ID/Loc split work on an Internet-wide ubiquitous scale, we need very good solutions and/or greater understanding to some hard questions such as what will be the granularity of the mapping function (how large will the mapping table be and what granularity of prefix will be in it), how to do the mapping, how to do liveness detection, what the scaling properties of the mapping and liveness detection functions is likely to be, and what the manageability, security, and robustness implications are. I guess that while we are at it we need to figure out if there are other issues, such as MTU, that need consideration. If you want to do experimentation on a moderate scale, then answers to these questions are not strictly needed. I didn't see any of these "hard issues" explicitly mentioned in the proposed charter (although there is mention of "the LISP+ALT mapping system"). Is this because the effort is intended to be focused on the shorter term experimentation efforts (including experimental protocol specs that allow the immediate experiments to occur), for which these hard issues do not need to be answered? Thanks, Ross -----Original Message----- From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of Eliot Lear Sent: 21 January 2009 08:56 To: PAPADIMITRIOU Dimitri Cc: int-area@ietf.org; lisp@ietf.org; routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP On 1/21/09 2:12 PM, PAPADIMITRIOU Dimitri wrote: > All items in the charter - see below - are exclusively oriented toward > LISP protocols implementation specifics, and interworking: > Right. This is a LISP WG. There is nothing stopping anyone from creating another WG, assuming the work warrants it. And again, the output is experimental docs. No standardization choices are being made. _______________________________________________ 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 lisp-bounces@ietf.org Wed Jan 21 08:46:16 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0A33A6BC6; Wed, 21 Jan 2009 08:46:16 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248D83A6BBC for ; Wed, 21 Jan 2009 08:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 keKLVvwdOCvY for ; Wed, 21 Jan 2009 08:46:14 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id 34FE93A6A90 for ; Wed, 21 Jan 2009 08:46:14 -0800 (PST) Received: from [IPv6:2001:13c7:7001:5000:216:cbff:fe98:665f] (unknown [IPv6:2001:13c7:7001:5000:216:cbff:fe98:665f]) by mail.lacnic.net.uy (Postfix) with ESMTP id 80BD330841C; Wed, 21 Jan 2009 14:45:47 -0200 (UYST) Message-Id: From: Roque Gagliano To: David Meyer In-Reply-To: <20090121161850.GB907@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 21 Jan 2009 14:45:46 -0200 References: <20090120162603.GA3374@1-4-5.net> <20090121161850.GB907@1-4-5.net> 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 Cc: Eduardo Grampin , lisp@ietf.org Subject: Re: [lisp] updated 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 21, 2009, at 2:18 PM, David Meyer wrote: > HEy Roque, > >> I wonder if any document should be published on the Management >> plane for >> LISP, I am not familiar with experimental documents but we can >> explore at >> least some management requirements. > > Sure. Are you interested in authoring/co-authoring such a > document? That would be great if so. > Yes, I believe Eduardo and I can work on this document. Roque > Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkl3UToACgkQnk+WSgHpbO7uHACeII3PFDfLqMItJPWCy3dlfd3j YLUAoMXuSIxObRbYWAEjNR2BCKkAGGki =StMh -----END PGP SIGNATURE----- _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 09:32:20 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE82228C216; Wed, 21 Jan 2009 09:32:20 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16FDB28C216 for ; Wed, 21 Jan 2009 09:32:20 -0800 (PST) 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 FqxEA3nXYpqa for ; Wed, 21 Jan 2009 09:32:19 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 5A85C28C1F6 for ; Wed, 21 Jan 2009 09:32:19 -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 n0LHVwdA011135; Wed, 21 Jan 2009 09:31:58 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0LHVwR1011134; Wed, 21 Jan 2009 09:31:58 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 21 Jan 2009 09:31:58 -0800 From: David Meyer To: Roque Gagliano Message-ID: <20090121173158.GA11111@1-4-5.net> References: <20090120162603.GA3374@1-4-5.net> <20090121161850.GB907@1-4-5.net> MIME-Version: 1.0 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: Eduardo Grampin , lisp@ietf.org Subject: Re: [lisp] updated 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: , Content-Type: multipart/mixed; boundary="===============1765756509==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1765756509== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >>> I wonder if any document should be published on the Management plane=20 >>> for >>> LISP, I am not familiar with experimental documents but we can =20 >>> explore at >>> least some management requirements. >> >> Sure. Are you interested in authoring/co-authoring such a >> document? That would be great if so. >> > > Yes, I believe Eduardo and I can work on this document. Awesome guys. Let's talk next week at NANOG, ok? Dave --oyUTqETQ0mS9luUI 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) iEYEARECAAYFAkl3XA4ACgkQORgD1qCZ2Ke34wCePeblNSbVolofjXVzrJIO6ffZ DdgAn00+Qmt/mKlRJ0BqnMT7+TMsQeAN =oN17 -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- --===============1765756509== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1765756509==-- From lisp-bounces@ietf.org Wed Jan 21 10:17:22 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7FC28C1F2; Wed, 21 Jan 2009 10:17:22 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DDD3A6962; Wed, 21 Jan 2009 10:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 B87bIoTq9d+S; Wed, 21 Jan 2009 10:17:20 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 6DBD03A696A; Wed, 21 Jan 2009 10:17:20 -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 n0LIGqSR013537; Wed, 21 Jan 2009 10:16:53 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0LIGqgU013536; Wed, 21 Jan 2009 10:16:52 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 21 Jan 2009 10:16:52 -0800 From: David Meyer To: Joe Touch Message-ID: <20090121181652.GA13516@1-4-5.net> References: <4977296A.50502@cisco.com> <3525C9833C09ED418C6FD6CD9514668C05858248@emailwf1.jnpr.net> <49775054.9090702@isi.edu> MIME-Version: 1.0 In-Reply-To: <49775054.9090702@isi.edu> 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: PAPADIMITRIOU Dimitri , lisp@ietf.org, routing-discussion@ietf.org, int-area@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for 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: , Content-Type: multipart/mixed; boundary="===============1937343620==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1937343620== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Joe, > A note on these issues might be useful to include in the LISP documents > under 'deployment considerations' or 'open issues'. Completely reasonable. Dave --IJpNTDwzlM2Ie8A6 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) iEYEARECAAYFAkl3ZpQACgkQORgD1qCZ2KeFcgCgj27ywY4MwhwUgYQnok+tQE80 gxkAniv6Wagtnd5CV5qP0KZHznaKv2v7 =IPHy -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- --===============1937343620== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1937343620==-- From lisp-bounces@ietf.org Wed Jan 21 10:22:42 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7928328C16F; Wed, 21 Jan 2009 10:22:42 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CE63A69CB; Wed, 21 Jan 2009 10:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.983 X-Spam-Level: X-Spam-Status: No, score=-5.983 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 6r8RRb8HWckN; Wed, 21 Jan 2009 10:22:39 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 84F323A69BB; Wed, 21 Jan 2009 10:22:38 -0800 (PST) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0LILrpH006930; Wed, 21 Jan 2009 19:21:53 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Jan 2009 19:21:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 19:20:12 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20090121161745.GA907@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG as towhether aWG forming BOF is necessary for LISP Thread-Index: Acl749QA/QcF23n4RzKHKlK14jqPGAABJMww References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> From: "PAPADIMITRIOU Dimitri" To: "David Meyer" X-OriginalArrivalTime: 21 Jan 2009 18:21:53.0060 (UTC) FILETIME=[225E9E40:01C97BF5] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as towhether aWG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dave: > > So the question - that is not administrative - boils down > > imho to: can we exclusively concentrate on the LISP protocol(s) > > specifics leaving the issue of our confidence on the Loc/ID > > split and associated challenges open. That question deserves > > imho a specific discussion that should happen in the context > > of a BoF. > > It would seem that one could apply the same argument to > SHIM6, HIP, SCTP, and several other protocols that have > been or are being standardized. > > So my question to you is: > > (i). Given your argument above, do you believe that > say, the SHIM6 WG should not have been chartered > (or perhaps that the SIGTRAN WG, which produced > RFCs 4960 and 3286) should not have been > chartered? Clearly they did not have such an > analysis, or we wouldn't be talking about doing > it now (and again, that is not to say there isn't > a ton of literature on loc/id split). > > (ii). If on the other hand you believe that, say SHIM6 > should have been chartered, the question is why > (again, given your argument above)? Applying that approach (SCTP had foundations coming from outside IETF) may work with relatively simpler problems/protocols. The level of complexity of the task to reach a certain objective drives the approach. In the present case, some of the main challenges are known beforehand and they are certainly not limited yet to protocol implementation specific aspects. One may certainly initiate a cycle of experiments using experimental protocol specs together with a specific set of eval.objective and criteria. This said, the approach in spiral (LISPv1->experiment->analysis->LISPv2-> ...) works iff proto-development takes these elements into account (otherwise any experimentation is hardly useful as it will not deliver the expected outcomes in order to make real progress) and outcomes/analysis are documented accordingly before moving to the next iteration. Here, the problem in understanding stems because: LISP WG focus on experimental specification to resolve only protocol engineering problems leaving actual challenges outside of its own protocol work but at the same time acknowledges that such experimentation are complementary to achieve real progress on its own protocols. However, at this point in time, I do not see how the protocol engineering problem can be decoupled from the purpose of the experimental effort in spiral. Hope this clarifies my concern, -dimitri. > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net] > Sent: Wednesday, January 21, 2009 5:18 PM > To: PAPADIMITRIOU Dimitri > Cc: routing-discussion@ietf.org; int-area@ietf.org; lisp@ietf.org > Subject: Re: [Int-area] Please respond: Questions from the > IESG as towhether aWG forming BOF is necessary for LISP > > Dimitri, > > > The task consisting in discovering by experimentation > architectural fit > > (wrt initial objectives) and complement understanding wrt known > > challenges (mapping, caching, loc.reachability, impact on traffic > > spatio-temporal properties) is very different in nature > than ensuring > > interoperability among protocols, minimize operational impact, and > > facilitate integration/deployability -> so requiring > different type of > > efforts with different timelines. As a matter of fact, both types of > > activities are still required imho. > > > > So the question - that is not administrative - boils down > imho to: can > > we exclusively concentrate on the LISP protocol(s) > specifics leaving the > > issue of our confidence on the Loc/ID split and associated > challenges > > open. That question deserves imho a specific discussion that should > > happen in the context of a BoF. > > The purpose of this WG would be to take the *LISP* > documents to EXPERIMENTAL. That is what I had in mind > when I wrote the charter, and I believe that it is pretty > clear on this point. That is not to say it the charter > can't be further tightened (I'm sure it can). > > A you know, WGs need to be tightly focused, especially in > the case of protocol groups. I'll grant you that my > experience with WGs in the OPs area are somewhat more > open-ended (at least mine have been), but it seems > unlikely that an IETF WG could successfully produce both > tight protocol specs and broad architectural surveys and > analyzes. In fact, I can't think of a case in which this > has been done in the IETF (perhaps there is one, but it > doesn't readily come to mind). Add to that that LISP is > clearly in an engineering and deployment phase, coupled > with the fact that producing engineering specs what the > IETF is good at (well, that is the IETF does), and one > sees that finishing up the LISP specs in the IETF seems > only natural. > > That said, it is a fine thing for the RRG to continue to > do what its doing, and further, the document you've been > describing on the RRG list should continue to progress > (IMO of course). In fact, these activities are completely > complementary. So keep up the good work. > > Just one point on your argument: > > > So the question - that is not administrative - boils down > imho to: can > > we exclusively concentrate on the LISP protocol(s) > specifics leaving the > > issue of our confidence on the Loc/ID split and associated > challenges > > open. That question deserves imho a specific discussion that should > > happen in the context of a BoF. > > It would seem that one could apply the same argument to > SHIM6, HIP, SCTP, and several other protocols that have > been or are being standardized. > > So my question to you is: > > (i). Given your argument above, do you believe that > say, the SHIM6 WG should not have been chartered > (or perhaps that the SIGTRAN WG, which produced > RFCs 4960 and 3286) should not have been > chartered? Clearly they did not have such an > analysis, or we wouldn't be talking about doing > it now (and again, that is not to say there isn't > a ton of literature on loc/id split). > > (ii). If on the other hand you believe that, say SHIM6 > should have been chartered, the question is why > (again, given your argument above)? > > > Note that I'm not taking a stand on this either > way. Rather, I'm just following the logic of your > argument. > > Dave > > > > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 10:55:06 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C40228C0FB; Wed, 21 Jan 2009 10:55:06 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244083A67F8; Wed, 21 Jan 2009 10:55:05 -0800 (PST) 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 FOzPRvyVHflJ; Wed, 21 Jan 2009 10:54:59 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 731A03A67AF; Wed, 21 Jan 2009 10:54:59 -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 n0LIsWL1015139; Wed, 21 Jan 2009 10:54:32 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0LIsV6U015138; Wed, 21 Jan 2009 10:54:31 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 21 Jan 2009 10:54:31 -0800 From: David Meyer To: PAPADIMITRIOU Dimitri Message-ID: <20090121185431.GA14875@1-4-5.net> References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> MIME-Version: 1.0 In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.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: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as towhether aWG forming BOF is necessary for 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: , Content-Type: multipart/mixed; boundary="===============0399366239==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0399366239== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dimitri, > > > So the question - that is not administrative - boils down=20 > > > imho to: can we exclusively concentrate on the LISP protocol(s)=20 > > > specifics leaving the issue of our confidence on the Loc/ID=20 > > > split and associated challenges open. That question deserves=20 > > > imho a specific discussion that should happen in the context=20 > > > of a BoF.=20 > >=20 > > It would seem that one could apply the same argument to > > SHIM6, HIP, SCTP, and several other protocols that have > > been or are being standardized. > >=20 > > So my question to you is: > >=20 > > (i). Given your argument above, do you believe that > > say, the SHIM6 WG should not have been chartered > > (or perhaps that the SIGTRAN WG, which produced > > RFCs 4960 and 3286) should not have been > > chartered? Clearly they did not have such an > > analysis, or we wouldn't be talking about doing > > it now (and again, that is not to say there isn't > > a ton of literature on loc/id split). > > > > (ii). If on the other hand you believe that, say SHIM6 > > should have been chartered, the question is why > > (again, given your argument above)?=20 >=20 > Applying that approach (SCTP had foundations coming from outside IETF) > may work with relatively simpler problems/protocols. The level of > complexity of the task to reach a certain objective drives the approach. Agreed that its complex, though you dismiss SCTP without explanation. In addition, I don't see the relevance of SCTP coming from outside the IETF. In any event, you might make the same claim for LISP (that its coming from outside the IETF). =09 > In the present case, some of the main challenges are known beforehand > and they are certainly not limited yet to protocol implementation > specific aspects. One may certainly initiate a cycle of experiments > using experimental protocol specs together with a specific set of > eval.objective and criteria. This said, the approach in spiral > (LISPv1->experiment->analysis->LISPv2-> ...) works iff > proto-development takes these elements into account (otherwise any > experimentation is hardly useful as it will not deliver the expected > outcomes in order to make real progress) and outcomes/analysis are > documented accordingly before moving to the next iteration.=20 > > Here, the problem in understanding stems because: LISP WG focus on > experimental specification to resolve only protocol engineering problems > leaving actual challenges outside of its own protocol work but at the > same time acknowledges that such experimentation are complementary to > achieve real progress on its own protocols. However, at this point in > time, I do not see how the protocol engineering problem can be decoupled > from the purpose of the experimental effort in spiral. >=20 > Hope this clarifies my concern, Not really. First, you didn't answer my question. Second, what you are arguing can be applied to say, OSPF (v1-n), EGP->BGP, ..... Essentially any protocol that has ever been rev'ed. Just to be clear: I understand the concern to further understand the properties of loc/id split. If fact, to the best of my knowledge no one in the current RRG cycle has written about this except for me and Darrel (draft-meyer-loc-id-implications-00.txt). That, however, shouldn't stop us from developing protocols. If it did, we'd never develop any protocol (since obviously the set of such questions is clearly *not* recursively enumerable).=20 Finally, what happens if the properties you want to study are in some sense "emergent" (e.g., the Internet's heavy-tailed robustness-complexity curve). The point here is that you won't see those properties until you have a system to study, so in our case (the Internet) the approach you are advocating would not have revealed the deepest and most fundamental (and hence most interesting) properties of "the architecture" (check out=20 http://www.cds.caltech.edu/~doyle/SFI_robustness/rigor_robust.htm or any of Doyle's work on this topic). Dave --0F1p//8PRICkK4MW 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) iEYEARECAAYFAkl3b2cACgkQORgD1qCZ2KfBfACfeaXJr5rA/A4netr6VA1w04Av kyIAn0mXzKelDA567qEKXE2mUeIay+kq =+IA3 -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- --===============0399366239== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0399366239==-- From lisp-bounces@ietf.org Wed Jan 21 12:55:44 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBEBF3A6AA6; Wed, 21 Jan 2009 12:55:44 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0383A6AC3 for ; Wed, 21 Jan 2009 12:55:43 -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 jOLOX3+zEWfJ for ; Wed, 21 Jan 2009 12:55:40 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 0FD123A6AA6 for ; Wed, 21 Jan 2009 12:55:39 -0800 (PST) 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=B1fHgmCOBSjC8pv2rya72aArRF8=; b=c95+P8tHBt XNZ72WiOoEAhCCxkmnfFjHZAIQ39Y9XJUXk6JXXlcHSUWXJUFROGKpV4XALYWm3d MDY5uMLS9syS4PCF4P/jAM/CuYlvq/cAA55BSEuq37/ODHeKP/cCJBpDfAs81cQa v9IGVVo7587gAanmZ5F8S66FXwFrUd0D4= 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=AR63d uAYB5zcqpavwtoq57b34Q752IVejSgZfYI6NhM4yG/x2qIggSJh2xHBCA3DfjTFn 1VHp3YAITe2wZ/2IdM1frVUEJKLZmgaRzHnnfBj3WezhNhH3E2niWPHE+PVPQJ0o 5eyCV0LiKR7bIYJlSOaWMR7TZk24huqBR+8LQQ= Received: from mbpobo.local (ip-83-134-203-193.dsl.scarlet.be [83.134.203.193]) (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; Wed, 21 Jan 2009 21:55:21 +0100 (CET) Message-ID: <49778BA7.2060200@uclouvain.be> Date: Wed, 21 Jan 2009 21:55:03 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: David Meyer References: <20090120162603.GA3374@1-4-5.net> In-Reply-To: <20090120162603.GA3374@1-4-5.net> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 1754BF1C16.C92A8 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] updated LISP WG charter 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dave, > > 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. I don't think that we should restrict the mapping discussion to ALT even if ALT is the only deployed solution today. > Mar 2010 Submit the LISP Interworking specification to the IESG > for Experimental. > > June 2010 Submit Recommendations for Allocation and Routing > of both EIDs and RLOCs to the IESG for Experimental. > > June 2010 Submit Recommendations for Securing the LISP Mapping > System to the IESG for Experimental. I think that the discussion on Securing the LISP Mapping System should be finished before the finalisation of any mapping proposal. This discussion is likely to define a set of requirements to be met by mapping systems. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 13:04:30 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8723A6B08; Wed, 21 Jan 2009 13:04:30 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC673A6AC5 for ; Wed, 21 Jan 2009 13:04:30 -0800 (PST) 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 NtW3NDQisB7e for ; Wed, 21 Jan 2009 13:04:29 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3B27C3A69ED for ; Wed, 21 Jan 2009 13:04:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,302,1231113600"; d="scan'208";a="34482577" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2009 21:04:10 +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 n0LL4A54019223 for ; Wed, 21 Jan 2009 16:04:10 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0LL4AsA023059 for ; Wed, 21 Jan 2009 21:04:10 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 16:04:10 -0500 Received: from cisco.com ([10.86.250.24]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 16:04:10 -0500 Date: Wed, 21 Jan 2009 16:04:00 -0500 From: Scott Brim To: lisp@ietf.org Message-ID: <20090121210400.GG71937@cisco.com> References: <20090120162603.GA3374@1-4-5.net> <49778BA7.2060200@uclouvain.be> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49778BA7.2060200@uclouvain.be> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 21 Jan 2009 21:04:10.0228 (UTC) FILETIME=[CE2C8B40:01C97C0B] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Subject: Re: [lisp] updated 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Excerpts from Olivier Bonaventure on Wed, Jan 21, 2009 09:55:03PM +0100: > Dave, > > > > > 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. > > I don't think that we should restrict the mapping discussion to ALT even > if ALT is the only deployed solution today. > > > Mar 2010 Submit the LISP Interworking specification to the IESG > > for Experimental. > > > > June 2010 Submit Recommendations for Allocation and Routing > > of both EIDs and RLOCs to the IESG for Experimental. > > > > June 2010 Submit Recommendations for Securing the LISP Mapping > > System to the IESG for Experimental. > > I think that the discussion on Securing the LISP Mapping System should > be finished before the finalisation of any mapping proposal. This > discussion is likely to define a set of requirements to be met by > mapping systems. The mapping system spec will have a security considerations section already. I guess this draft will be a more in-depth exploration of the mechanisms laid out in the mapping system spec? _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 13:09:23 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91EFC3A69B2; Wed, 21 Jan 2009 13:09:23 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BCF3A69B2 for ; Wed, 21 Jan 2009 13:09:23 -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=[AWL=0.000, 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 ZBDrdZKI5fhv for ; Wed, 21 Jan 2009 13:09:22 -0800 (PST) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id CF10C3A683A for ; Wed, 21 Jan 2009 13:09:21 -0800 (PST) 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= AOOsdQPDDgGSKTwSxKJWwaBmDK8=; b=avheE2/r8TdRlCjnzxsgnL+3gJ8rP1kG 64s9hP5rONHJbgL3afnpCVRMAZvXso/cXp5hKwZtmKFbkuewD0O9FEwBpYktqs9d m4pWOjUlOOg0RQgp/l28+fVXcRlWfE02klFi8EMw22t5GfGW5gKSgZ2b7UNpEykj BB5ZG8KQmtw= 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=CvOmRgpqgAb/VfybvF Rhc4DXsXf1XtZ9fb4aHNk8TQX0lE0bLfmDiXpOkX+VgAXMGv8AtzaDKV6i18B8/8 YUYcHAjyMDKR3u/py8lrnin+prRDyGiEzXFKAis2XRB8/xYliCXwYLBQJU+u5Yzk vqiaOcTTnR6qdvlO5wCsRlwEw= Received: from mbpobo.local (ip-83-134-203-193.dsl.scarlet.be [83.134.203.193]) (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 for ; Wed, 21 Jan 2009 22:08:55 +0100 (CET) Message-ID: <49778EE1.8050407@uclouvain.be> Date: Wed, 21 Jan 2009 22:08:49 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: lisp@ietf.org X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: CC31DEDD1F.44B1F X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: [lisp] The case for Map-Updates 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Hello, In the current LISP specification, two mapping messages are defined : - Map-Request that allows to request the set of RLOCs corresponding to a given EID - Map-Reply that provides the mapping between an EID block and a set of RLOCs These two messages basically assume that the mapping database is built by means that are outside of the LISP protocols (e.g. manual configuration). I think that we should add a third message to add or update entries in the mapping databases : - Map-Update : this message is used when an entity needs to add a new mapping in the database or update an existing entry in the mapping database. There should, of course, be a way to authenticate the sender of the mapping update These Map-Update messages would be useful in different scenarios : - an xTR needs to change its RLOC - an xTR is being shutdown or will be shutdown in some time and need to force a removal of the corresponding mapping entry - load-balanced xTR are overloaded and their weight needs to be updated - ... I think that there would be other usages of such Map-Update messages. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 13:14:17 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C662D3A6984; Wed, 21 Jan 2009 13:14:17 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49BD3A6984 for ; Wed, 21 Jan 2009 13:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 Hbm4zv1Hyqn5 for ; Wed, 21 Jan 2009 13:14:16 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 1F53C3A683A for ; Wed, 21 Jan 2009 13:14:16 -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 n0LLDx33017787; Wed, 21 Jan 2009 13:13:59 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0LLDxvn017786; Wed, 21 Jan 2009 13:13:59 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 21 Jan 2009 13:13:59 -0800 From: David Meyer To: Olivier Bonaventure Message-ID: <20090121211359.GA17680@1-4-5.net> References: <20090120162603.GA3374@1-4-5.net> <49778BA7.2060200@uclouvain.be> MIME-Version: 1.0 In-Reply-To: <49778BA7.2060200@uclouvain.be> 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] updated 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: , Content-Type: multipart/mixed; boundary="===============0968742107==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0968742107== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Olivier, > > Goals and Milestones: > >=20 > > Mar 2010 Submit base LISP specification to the IESG for > > Experimental. > >=20 > > Mar 2010 Submit base ALT specification to the IESG for > > Experimental. >=20 > I don't think that we should restrict the mapping discussion to ALT even > if ALT is the only deployed solution today. I understand your point (LISP is modular in the mapping system). However, I was writing milestones here, so this one needs to stay.=20 So do you want to add another milestone around mapping systems, and if so, send some text of what you have in mind and we can work on that. > > Mar 2010 Submit the LISP Interworking specification to the IESG > > for Experimental. > >=20 > > June 2010 Submit Recommendations for Allocation and Routing > > of both EIDs and RLOCs to the IESG for Experimental. > >=20 > > June 2010 Submit Recommendations for Securing the LISP Mapping > > System to the IESG for Experimental. >=20 > I think that the discussion on Securing the LISP Mapping System should > be finished before the finalisation of any mapping proposal. This > discussion is likely to define a set of requirements to be met by > mapping systems. In general, yes. In the particular case of ALT, we will do whatever SIDR does. However, we do not want to gate progress on ALT by whatever is being done SIDR. So maybe we can have the ALT draft be self-contained (all this stuff about SIDR could go in a Security Considerations section in the ALT document), and whoever writing the Recommendations Draft can also point at that. Does that make sense? Dave --G4iJoqBmSsgzjUCe 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) iEYEARECAAYFAkl3kBcACgkQORgD1qCZ2KecuACdHmjAtMNUxjJKs3RVMshHS2xu 5UEAnRGxAGk8M4SLMqp0oTZxUR+tKy6Y =c2PL -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- --===============0968742107== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0968742107==-- From lisp-bounces@ietf.org Wed Jan 21 15:49:36 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B793A68DC; Wed, 21 Jan 2009 15:49:36 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199803A6850; Wed, 21 Jan 2009 15:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 9sDWPzJ8yzwZ; Wed, 21 Jan 2009 15:49:33 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 66E333A67AE; Wed, 21 Jan 2009 15:49:32 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0LNmkVD014408; Thu, 22 Jan 2009 00:48:46 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 22 Jan 2009 00:48:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 00:48:46 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20090121185431.GA14875@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG astowhether aWG forming BOF is necessary for LISP Thread-Index: Acl7+blIDhCrD/9eT363+q1bfcUGdQAArRdg References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> <20090121185431.GA14875@1-4-5.net> From: "PAPADIMITRIOU Dimitri" To: "David Meyer" X-OriginalArrivalTime: 21 Jan 2009 23:48:45.0937 (UTC) FILETIME=[CC8E2610:01C97C22] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG astowhether aWG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org David: > > > > So the question - that is not administrative - boils down > > > > imho to: can we exclusively concentrate on the LISP protocol(s) > > > > specifics leaving the issue of our confidence on the Loc/ID > > > > split and associated challenges open. That question deserves > > > > imho a specific discussion that should happen in the context > > > > of a BoF. > > > > > > It would seem that one could apply the same argument to > > > SHIM6, HIP, SCTP, and several other protocols that have > > > been or are being standardized. > > > > > > So my question to you is: > > > > > > (i). Given your argument above, do you believe that > > > say, the SHIM6 WG should not have been chartered > > > (or perhaps that the SIGTRAN WG, which produced > > > RFCs 4960 and 3286) should not have been > > > chartered? Clearly they did not have such an > > > analysis, or we wouldn't be talking about doing > > > it now (and again, that is not to say there isn't > > > a ton of literature on loc/id split). > > > > > > (ii). If on the other hand you believe that, say SHIM6 > > > should have been chartered, the question is why > > > (again, given your argument above)? > > > > Applying that approach (SCTP had foundations coming from > outside IETF) > > may work with relatively simpler problems/protocols. The level of > > complexity of the task to reach a certain objective drives > the approach. > > Agreed that its complex, though you dismiss SCTP without > explanation. I mean for SCTP the base work was already done when protocol was translated in the IP world. SCTP follows the path described by D.Thaler in the IAB doc. "What Makes For a Successful Protocol?" > In addition, I don't see the relevance of > SCTP coming from outside the IETF. In any event, you > might make the same claim for LISP (that its coming from > outside the IETF). > > > In the present case, some of the main challenges are known > beforehand > > and they are certainly not limited yet to protocol implementation > > specific aspects. One may certainly initiate a cycle of experiments > > using experimental protocol specs together with a specific set of > > eval.objective and criteria. This said, the approach in spiral > > (LISPv1->experiment->analysis->LISPv2-> ...) works iff > > proto-development takes these elements into account (otherwise any > > experimentation is hardly useful as it will not deliver the expected > > outcomes in order to make real progress) and outcomes/analysis are > > documented accordingly before moving to the next iteration. > > > > Here, the problem in understanding stems because: LISP WG focus on > > experimental specification to resolve only protocol > engineering problems > > leaving actual challenges outside of its own protocol work > but at the > > same time acknowledges that such experimentation are > complementary to > > achieve real progress on its own protocols. However, at > this point in > > time, I do not see how the protocol engineering problem can > be decoupled > > from the purpose of the experimental effort in spiral. > > > > Hope this clarifies my concern, > > Not really. First, you didn't answer my question. Your question is: does one size (of approach) fits all and the answer is no. Indeed, these situations can not be compared (SHIM6 is a WG whereas HIP is a WG and a RG) but none did intend to address the Internet routing system scalability. If my answer yes they should have been chartered it does not provide any element for answering the present question. > Second, > what you are arguing can be applied to say, OSPF (v1-n), > EGP->BGP, ..... Essentially any protocol that has ever > been rev'ed. Indeed. This is what i had in mind as example but there is a main difference: BGPv1 has been released in 1989 and progressed together with the growth of the Internet until reaching BGPv4. The conditions/environment is thus different but one thing remains multiple iterations will be needed. > Just to be clear: I understand the concern to further > understand the properties of loc/id split. If fact, to > the best of my knowledge no one in the current RRG cycle > has written about this except for me and Darrel > (draft-meyer-loc-id-implications-00.txt). That, however, > shouldn't stop us from developing protocols. If it did, > we'd never develop any protocol (since obviously the set > of such questions is clearly *not* recursively > enumerable). Work on cache-based mapping is ongoing, and there is still open work for mapping system itself (any reason for instance why you consider ALT as the only mapping distribution technique ?) to a name a few whereas there is no outcome yet for what it concerns impact on spatio-temporal traffic properties. All these "uncertainties" are left outside the design space - at least as the charter translates it - > Finally, what happens if the properties you want to study > are in some sense "emergent" (e.g., the Internet's > heavy-tailed robustness-complexity curve). The point here > is that you won't see those properties until you have a > system to study, so in our case (the Internet) the > approach you are advocating would not have revealed the > deepest and most fundamental (and hence most interesting) > properties of "the architecture" (check out > > http://www.cds.caltech.edu/~doyle/SFI_robustness/rigor_robust.htm > or any of Doyle's work on this topic). Uncertainties are intrinsically part of the experimental work: this reference states "robust to known and designed-for uncertainties". Paraphrasing that statement it seems the LISP charter does not leave room for addressing uncertainties (e.g. mapping system consider only ALT so only ALT could be experimented) - a BoF session should clarify why this is the case - Thanks, -dimitri. > Dave > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 16:02:48 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA55028C173; Wed, 21 Jan 2009 16:02:48 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 827563A68DC; Wed, 21 Jan 2009 16:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 J83oNYdl9ZzQ; Wed, 21 Jan 2009 16:02:46 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id B78343A67AE; Wed, 21 Jan 2009 16:02:46 -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 n0M02Ksl025950; Wed, 21 Jan 2009 16:02:20 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0M02Kcj025949; Wed, 21 Jan 2009 16:02:20 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 21 Jan 2009 16:02:20 -0800 From: David Meyer To: PAPADIMITRIOU Dimitri Message-ID: <20090122000220.GA25832@1-4-5.net> References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> <20090121185431.GA14875@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> MIME-Version: 1.0 In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.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: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG astowhether aWG forming BOF is necessary for 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: , Content-Type: multipart/mixed; boundary="===============1673011027==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1673011027== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Dimitri, > Uncertainties are intrinsically part of the experimental work: this > reference states "robust to known and designed-for uncertainties". Right, this is RYF (Robust Yet Fragile) behavior...see the second Eugene NANOG t-shirt (the black one) :-)=20 > Paraphrasing that statement it seems the LISP charter does not leave > room for addressing uncertainties (e.g. mapping system consider only ALT > so only ALT could be experimented) - a BoF session should clarify why > this is the case - Not sure I follow. Of course we want to wind up with a solid ALT spec, but the charter states that "The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems." IMO this admits the specification for other mapping systems. Good ideas always welcome. In any event, Brian really summed it up quite nicely: =20 ... =20 But I don't see the point in a second BOF; the idea that a BOF could resolve in a couple of hours the issues that the RRG has been discussing since early 2007 seems unlikely. Dave --yrj/dFKFPuw6o+aM 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) iEYEARECAAYFAkl3t4wACgkQORgD1qCZ2KdPcgCgk9/KLcvNb3CYOLIHV7syIaar mGYAn23ucEpPIHqLUgntopX9/hzK4x23 =Rshm -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- --===============1673011027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1673011027==-- From lisp-bounces@ietf.org Wed Jan 21 16:57:51 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED4028C206; Wed, 21 Jan 2009 16:57:51 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77EF3A69EC; Wed, 21 Jan 2009 16:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.004 X-Spam-Level: X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 FVwNQgQLR83t; Wed, 21 Jan 2009 16:57:50 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id DB4543A63D2; Wed, 21 Jan 2009 16:57:49 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0M0v5HL022892; Thu, 22 Jan 2009 01:57:05 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 22 Jan 2009 01:57:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 01:57:06 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E3B8@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20090122000220.GA25832@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG astowhetheraWG forming BOF is necessary for LISP Thread-Index: Acl8JLh7XWZ2e6C0SdSWbmZqSLX8PgAAtb/A References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> <20090121185431.GA14875@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> <20090122000220.GA25832@1-4-5.net> From: "PAPADIMITRIOU Dimitri" To: "David Meyer" X-OriginalArrivalTime: 22 Jan 2009 00:57:04.0937 (UTC) FILETIME=[57BFE990:01C97C2C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG astowhetheraWG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org David: > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net] > Sent: Thursday, January 22, 2009 1:02 AM > To: PAPADIMITRIOU Dimitri > Cc: routing-discussion@ietf.org; int-area@ietf.org; lisp@ietf.org > Subject: Re: [Int-area] Please respond: Questions from the > IESG astowhetheraWG forming BOF is necessary for LISP > > Hey Dimitri, > > > Uncertainties are intrinsically part of the experimental work: this > > reference states "robust to known and designed-for uncertainties". > > Right, this is RYF (Robust Yet Fragile) behavior...see > the second Eugene NANOG t-shirt (the black one) :-) > > > Paraphrasing that statement it seems the LISP charter does not leave > > room for addressing uncertainties (e.g. mapping system > consider only ALT > > so only ALT could be experimented) - a BoF session should > clarify why > > this is the case - > > Not sure I follow. Of course we want to wind up with a > solid ALT spec, but the charter states that "The working > group will encourage and support interoperable LISP > implementations as well as defining requirements for > alternate mapping systems." IMO this admits the > specification for other mapping systems. Good ideas > always welcome. > > In any event, Brian really summed it up quite nicely: > > ... > But I don't see the point in a second BOF; the idea > that a BOF could resolve in a couple of hours the > issues that the RRG has been discussing since early > 2007 seems unlikely. No one stated that the BoF will resolve the issues/challenges themselves - a BoF is the place to discuss what the charter can include as work items to achieve objectives (that are not limited to the design of the protocol specifics). These items are centered around the initial design goals that lead to this effort and how LISP after experimental work will address them. I suggest to have at least an item in the LISP charter that takes the RRG design goals as outline and for each of the goals documents how LISP protocol addresses them. Thanks, -dimitri. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 18:50:57 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F693A6A8E; Wed, 21 Jan 2009 18:50:57 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D575D3A6A8E; Wed, 21 Jan 2009 18:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 ribev-TCuo40; Wed, 21 Jan 2009 18:50:55 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 3078C3A67D6; Wed, 21 Jan 2009 18:50:55 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 15A166BE5DC; Wed, 21 Jan 2009 21:50:36 -0500 (EST) To: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Message-Id: <20090122025036.15A166BE5DC@mercury.lcs.mit.edu> Date: Wed, 21 Jan 2009 21:50:36 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG astowhetheraWG forming BOF is necessary for 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Can people _please_ trim the CC lists to just "int-area@ietf.org", please? Getting three copies is painful, but when some people aren't on some of the lists, and their responses are delayed until the moderator approves them, and so the they show up separated by hours, it gets very confusing. Thanks. Noel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 23:03:46 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24563A699E; Wed, 21 Jan 2009 23:03:46 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C223A699E for ; Wed, 21 Jan 2009 23:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 eH187a3VH0TA for ; Wed, 21 Jan 2009 23:03:39 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id ED9123A685D for ; Wed, 21 Jan 2009 23:03:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,305,1231113600"; d="scan'208";a="124711516" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 22 Jan 2009 07:03:23 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n0M73NPg014106; Wed, 21 Jan 2009 23:03:23 -0800 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 n0M73N28015943; Thu, 22 Jan 2009 07:03:23 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, 21 Jan 2009 23:03:23 -0800 Received: from [192.168.1.2] ([10.21.150.48]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 23:03:22 -0800 Message-Id: <45A96B82-9301-4935-A251-7B4DB8E8BD22@cisco.com> From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <49778EE1.8050407@uclouvain.be> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 21 Jan 2009 23:03:22 -0800 References: <49778EE1.8050407@uclouvain.be> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 22 Jan 2009 07:03:23.0022 (UTC) FILETIME=[83B58AE0:01C97C5F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2350; t=1232607803; x=1233471803; c=relaxed/simple; s=sjdkim4002; 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]=20The=20case=20for=20Map-Updates |Sender:=20; bh=jY8UTrT0P4m3ltNv9meTjIqEemsU9WjOpa6zO5+NAt0=; b=IOxvJT8WYbMPIF/UPtHo5GyC3nW5RYcu8Yj79QnIda6ZfY9OPYCHu1nNmI F2X6P7hHFj+ncDMGxXjBgs7mVbCIgyJOs5AEWGtsby3MRlODpTWLs5svT/L7 mQ4miQlv65; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] The case for Map-Updates 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > In the current LISP specification, two mapping messages are defined : > > - Map-Request that allows to request the set of RLOCs corresponding > to a > given EID > - Map-Reply that provides the mapping between an EID block and a set > of > RLOCs > > These two messages basically assume that the mapping database is built > by means that are outside of the LISP protocols (e.g. manual > configuration). I think that we should add a third message to add or > update entries in the mapping databases : > > - Map-Update : this message is used when an entity needs to add a new > mapping in the database or update an existing entry in the mapping > database. There should, of course, be a way to authenticate the sender > of the mapping update The mapping database are distributed. It is not centralized. When a site becomes a LISP site, the new EID-to-RLOC mapping is configured in the ETRs that reside at the site. So I don't know who would send the Map-Update and who would receive it. If this model changes because there is a different mapping database employed, then the message can be introduced at that time. > These Map-Update messages would be useful in different scenarios : > - an xTR needs to change its RLOC We have Solicit-Map-Requests that do that. > - an xTR is being shutdown or will be shutdown in some time and need > to > force a removal of the corresponding mapping entry Today, the xTR can just go away. In fact, mappings that are cached by remote ITRs need to stay in tack because there are other xTRs at the site which are being used. The loc-reach-bit for the xTR coming out of service can be set to 0 immediately until the time an SMR is sent to remove the RLOC from the mapping. > - load-balanced xTR are overloaded and their weight needs to be > updated SMRs do this too. Or you can source-quench the source by advertising the RLOC as unreachable for a short period of time. There are already simple mechanisms in place that seem to work well. Dino > I think that there would be other usages of such Map-Update messages. > > > Olivier > > > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium > _______________________________________________ > 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 lisp-bounces@ietf.org Wed Jan 21 23:10:30 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138083A69EB; Wed, 21 Jan 2009 23:10:30 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9423A699E; Wed, 21 Jan 2009 23:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.472 X-Spam-Level: X-Spam-Status: No, score=-9.472 tagged_above=-999 required=5 tests=[AWL=1.127, BAYES_00=-2.599, 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 a+4mtWS2NkXK; Wed, 21 Jan 2009 23:10:27 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 955A33A685D; Wed, 21 Jan 2009 23:10:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,305,1231113600"; d="scan'208";a="31588648" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Jan 2009 07:10:00 +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 n0M7A02w024608; Thu, 22 Jan 2009 08:10:00 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0M7A0Hh021398; Thu, 22 Jan 2009 07:10:00 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 08:10:00 +0100 Received: from adsl-247-5-fixip.tiscali.ch ([10.61.102.150]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 08:09:59 +0100 Message-ID: <49781BC7.2000804@cisco.com> Date: Thu, 22 Jan 2009 08:09:59 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090119 Shredder/3.0b2pre MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> <20090121185431.GA14875@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> X-OriginalArrivalTime: 22 Jan 2009 07:10:00.0070 (UTC) FILETIME=[705E4260:01C97C60] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1654; t=1232608200; x=1233472200; 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]=20[Int-area]=20Please=20respond= 3A=20Questions=20from=20the=20IESG=09astowhether=0A=20aWG=20 forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=JMhX3s3R0s0ucilFRhN0jUTctj9jp58UUiU/NV3XNEo=; b=Qqfh27GP8kvmy7lJwViLBN2sxT6sai9IXtGldkyCgUtmpoJfwzAkUYsO+1 aDHkCHaCzZbCncm1s8cu3bN+Hu6IrxIxEMpElKXlFqcGY9XfFaMynNMo0m9X TM7lPM12Z4; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG astowhether aWG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org On 1/22/09 12:48 AM, PAPADIMITRIOU Dimitri wrote: > > Your question is: does one size (of approach) fits all and the answer is > no. Indeed, these situations can not be compared (SHIM6 is a WG whereas > HIP is a WG and a RG) but none did intend to address the Internet > routing system scalability. It's not entirely so. The routing system was clearly in peoples' minds when HIP was in its early stages. Bob Moskowitz was involved in the Name Space Research Group (NSRG) back when it existed, and as a co-chair of that group I was asked to comment on the chartering on both HIP groups. The NSRG looked at HIP in the light of route scalability. This was one reason that Mike O'Dell (author of 8+8) was interested. Was there was any alternative propose to HIP at the host level as a layer 3.5 mechanism? That is really where SHIM6 comes in, which as I recall was an outgrowth of MULTI6 and Tony Li's early proposal on NOID. Bob Braden, John Wrocklawski (?), et al argued at one point (and I'm sorry I don't have the cite) that we have all the names we need in the IP stack. Both NOID and SHIM6 were, at least in part, evolutions on that notion, and a nameless (stack-wise) alternative to HIP. And so while I agree with your high level point that one size does not fit all, I would say that the policy here as I understand it from Jari is simply that he will not favor one proposal over another and he will not short circuit the RRG process, while at the same time he will provide a venue for work where there is sufficient interest to mature the specifications through community involvement. Eliot _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 21 23:15:24 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC943A699E; Wed, 21 Jan 2009 23:15:24 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E11A28C11B for ; Wed, 21 Jan 2009 23:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 kSrqqCv+f6gU for ; Wed, 21 Jan 2009 23:15:22 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8F5DA3A685D for ; Wed, 21 Jan 2009 23:15:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,305,1231113600"; d="scan'208";a="124712990" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 22 Jan 2009 07:15:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n0M7F53J027956; Wed, 21 Jan 2009 23:15:05 -0800 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 n0M7F5Zk017062; Thu, 22 Jan 2009 07:15:05 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, 21 Jan 2009 23:15:04 -0800 Received: from [192.168.1.2] ([10.21.150.48]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 23:15:03 -0800 Message-Id: <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <4976453C.4020306@uclouvain.be> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 21 Jan 2009 23:15:01 -0800 References: <49730E98.1030101@uclouvain.be> <4976453C.4020306@uclouvain.be> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 22 Jan 2009 07:15:04.0236 (UTC) FILETIME=[25AA4EC0:01C97C61] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6838; t=1232608505; x=1233472505; c=relaxed/simple; s=sjdkim4002; 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]=20Locator=20liveness=20problem |Sender:=20; bh=PRfiHEj1dLGF+3aHz/aoqR+GtdXovjxv2YHyrbsBBdo=; b=KFEPaFVQEN5JYkRNdE9N51Nii38BAhc3prVHCl6ea8nkd1e3Q7jFHiN1Pn jIrkO/sqmQzy3gBFQFvoEZsTOK9Mj8I3NEnBPKGyuR2BZ0i3fv1fLnNvIKYR +LfM3c8A80; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Locator liveness problem 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org >>> 1- What are the types of failures that we consider and want to be >>> able >>> to detect : >>> >>> a. Failure of an ETR >>> >>> b. Failure of (one of the link) directly attached to an ETR to its >>> provider >> >> These are covered by the loc-reach-bits and have been in the LISP >> spec >> for quite a long time. I think dating back to the -02 draft. > > There are some issues with loc-reach-bits that are part of the LISP > spec : > - The support for more than 31 locators is cumbersome (maybe 31 > locoators is sufficient for most deployments, including experimental > ones, but I don't think that it's future proof) That was removed in -11. > - They assume that there is an ordering among the ETRs such that each > ETR knows the position of all other ETRs in the loc-reach bits. This That's the price of compression. And it's not that bad. See Luigi for my reasons. I have commented on other designs about this matter. > ordering should be preserved everytime an ETR is added or removed to > serve a given EID prefix and the ordering must remain consistent among > all ETRs that serve each EID prefix. This issue has not been discussed > in details until now. Yes, but RLOCs are not going to change much. If we want to the total system to scale we have to keep the update rate low-enough. So we don't need heavy-weight solution. Please have a detail look at SMRs in the latest spec and give us comments about that design. >>> So the question I keep challenging people with is, with LISP >> loc-reach-bits and BGP route existence (i.e. "reachability"), is this >> good enough. Is this enough tools for an ITR to know when to switch >> RLOCs. If the ITR is running BGP, I think we are in a good position >> to >> day yes. > > LISP ETRs will be mainly deployed by stub networks. Consider that AS1 > and AS2 are two large T1 ISPs with thousands of stub customers. For > scalability reasons, the RLOCs attached to the ETRs of their customers > are all inside a large prefix announced by BGP (say 1.0.0.0/16 for AS1 > and 2.0.0.0/16 for AS2). In this case, a BGP withdraw will only be > sent > if the entire RLOC prefix fails, which is unlikely. I'm not sure that > BGP gives you mugh more information, unless we expect to see short > RLOC > prefixes advertised with BGP, which does not scale. Agree, but probing is a non-starter. We can handle a class of failures if major peerings go down because the entire aggregate goes away. But if a more specific goes away, then there will probably be some sort of rerouting happening closer to the customer stub network, probably in the customer's SP network. We are not talking about anything new here. That is the way the BGP routing system works today. We don't rely on unreachables, we either have rerouting occur close to where the failure is or we blackhole. The same is going to happen for LISP RLOCs. >> The case is where a peering connection goes down and >> an alternate path is not available because the transit policy for an >> RLOC is quite different than for an EID. That is, a transit ISP >> cannot >> tell it's customer is behind an RLOC supported by another ISP. And >> the >> EID is not known to the core (for good reasons) so we could sever >> connectivity which previously was not before we introduced the >> level of >> indirection. >> >> Having said that, c is the issue at hand here and not a and b. >> >>> 2- The focus of LISP should be to forward packets despite of >>> failures of >>> an ETR or failures of a link that is attached to an ETR and not to >>> detect failures. >> >> But having an alternate path locally and not using could be >> question of >> "a good feature we cannot scale". > > Sorry, but I don't see why a local alternate cannot scale It all depends if you want to confirm reachability before you switch to a new RLOC. Doing that requires polling from lots of places to each xTR. Which also takes time, so you don't have the best of convergence. And then when you have confirmed the path, before you start using it (before the next packet comes for encapsulation) the path might have already changed. >>> First, if a set of EID prefixes is served only by a single-homed >>> ETR, >>> then the failure of the ETR or of the link that attaches the ETR >>> to its >> >> If the site is single homed and the ETR goes down, there is no >> reason to >> fix this, because you cannot. > > What I mean is that if an EID prefix is served by a single-homed xTR, > then there is no need to spend time/packets/cpu to detect the > reachability of this xTR. Right, agree. Would have to argue for the same for the multi-homed case. >> Just like routers can't switch packets >> without the power on. ;-) >> >> Oh, and others have asked me to make packets go faster than the >> speed of >> light too. ;-) >> >>> provider will cause a failure of the EID. Such a failure will be >>> eventually detected by ICMP destination unreachable messages. This >>> is >> >> Another comment I have. Can all of us please stop talking about ICMP >> Unreachables. We can't rely on them. They are not dependable. They >> are >> off by default in core IOS routers. They are filtered by NATs and >> other >> firewalls. >> >> All designs should spec that if an Unreachble is received, you can >> use >> it but you can't base a design on using ICMP unreachables. Even if >> they >> were turned on, there are too many security implications. Also, ICMP >> unreachables don't contain mask-lengths, so this contributes to it's >> unscalablility. > > I agree that we cannot rely only on ICMP, but we cannot ignore them > neither. We should not assume that core routers will send ICMP The -11 spec says you should switch RLOCs if you get an ICMP Unreachable. > unreachable, but a PE attached to a CPE could easily send ICMP unreach > when the attached CPE fails. ICMP could be off on core routers, but be If the CPE fails, the other xTRs in the site will find out faster and they reflect the change by zeroing the loc-reach-bit for the CPE. >>> one ETR or one of its links. >>> >>> In subcase b, a cooperation among the two providers could ensure >>> that >>> the two RLOCs remain reachable even if one of the links or one of >>> the >> >> There is never cooperation like this between two SPs. My definition >> of >> inter-SP cooperation is agreeing to BGP peer with each other and the >> manual exchange of peering addresses. > > Paying customers can "encourage" network providers to cooperate to > provide better/combined services. Well, that hasn't happen up to now. ;-) This comment is way "easier said than done". Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 22 01:55:10 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAE93A69C5; Thu, 22 Jan 2009 01:55:10 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8EA3A69C5; Thu, 22 Jan 2009 01:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 zhGYI1dt7gm5; Thu, 22 Jan 2009 01:55:07 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id BE4573A683E; Thu, 22 Jan 2009 01:55:06 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0M9sIPY018708; Thu, 22 Jan 2009 10:54:19 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 22 Jan 2009 10:54:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 10:52:37 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E561@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESGastowhether aWG forming BOF is necessary for LISP Thread-Index: Acl8KqBqk+0DQdmoQuaH2a093Ffm+wAAXKOw References: <20090120190744.GA9467@1-4-5.net><00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com><20090121161745.GA907@1-4-5.net><00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com><20090121185431.GA14875@1-4-5.net><00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com><20090122000220.GA25832@1-4-5.net> <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> From: "PAPADIMITRIOU Dimitri" To: "David Conrad" , "David Meyer" X-OriginalArrivalTime: 22 Jan 2009 09:54:18.0526 (UTC) FILETIME=[647743E0:01C97C77] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESGastowhether aWG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org david: > LISP is _an_ approach towards routing scalability. providing it does not transpose the scalability problem at another level e.g mapping system (including at the edge TR), this point is related to the granularity of the mapping function and the EID/RLOC space ratio. also, the data-driven behaviour of LISP - its dynamics is driven by the spatio-temporal characteristics of the traffic and not only the prefix reachability (as in existing routing system) - adds dependencies to the "equation" of routing system design. => i would be less affirmative in making such statement -a priori-. in order to consolidate our understanding, the charter should include an item on how LISP addresses routing scalability and other design goals (at least as much as the experiment result allows). this would at the same time close the loop with part of the RRG work. thanks, -dimitri. > -----Original Message----- > From: int-area-bounces@ietf.org > [mailto:int-area-bounces@ietf.org] On Behalf Of David Conrad > Sent: Thursday, January 22, 2009 1:44 AM > To: David Meyer > Cc: int-area@ietf.org; lisp@ietf.org; routing-discussion@ietf.org > Subject: Re: [Int-area] Please respond: Questions from the > IESGastowhether aWG forming BOF is necessary for LISP > > Hi, > > Sorry for being a bit late to this discussion (day job and other > realities intruding), but having had a small role in the > Dublin BOF, I > don't think it likely (in the extreme) there would be significant > benefit from having a second BOF. I'd like to second Dave's > seconding > of Brain's statement: > > On Jan 21, 2009, at 4:02 PM, David Meyer wrote: > > In any event, Brian really summed it up quite nicely: > > > > ... > > But I don't see the point in a second BOF; the idea > > that a BOF could resolve in a couple of hours the > > issues that the RRG has been discussing since early > > 2007 seems unlikely. > > I'd actually go a bit further and suggest that any attempt by any > group to resolve the issues the RRG has been discussing (or > any of the > various other discussions that occurred prior to RRG taking this on) > as a pre-requisite for creating a working group to standardize an > experimental protocol in this space would be equivalent to declaring > no protocol in this space will _ever_ be standardized. > > LISP is _an_ approach towards routing scalability. It is not > the only > one. Standardizing the experimental protocol would allow folks > interested in routing scalability to explore one or two axes of the > possible solution space. To be honest, I'm unclear as to why > there is > even a question as to whether a WG should be created... > > Regards, > -drc > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 22 08:12:54 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20CE028C1B8; Thu, 22 Jan 2009 08:12:54 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0CCC3A67DA; Thu, 22 Jan 2009 08:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 ws8jMYycuZJC; Thu, 22 Jan 2009 08:12:46 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id B26B23A67E4; Thu, 22 Jan 2009 08:12:46 -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 n0MGCJ35010704; Thu, 22 Jan 2009 08:12:19 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0MGCJR1010703; Thu, 22 Jan 2009 08:12:19 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 08:12:19 -0800 From: David Meyer To: PAPADIMITRIOU Dimitri Message-ID: <20090122161219.GA10278@1-4-5.net> References: <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> <00275A5B436CA441900CB10936742A3801A2E561@FRVELSMBS22.ad2.ad.alcatel.com> MIME-Version: 1.0 In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E561@FRVELSMBS22.ad2.ad.alcatel.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: int-area@ietf.org, David Conrad , routing-discussion@ietf.org, lisp@ietf.org Subject: [lisp] Proposed rule for adding charter milestones [was Re: [Int-area] Please....] 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: , Content-Type: multipart/mixed; boundary="===============2079576775==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============2079576775== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dimitri, > =3D> i would be less affirmative in making such statement -a priori-. in > order to consolidate our understanding, the charter should include an > item on how LISP addresses routing scalability and other design goals > (at least as much as the experiment result allows). this would at the > same time close the loop with part of the RRG work.=20 This is the second or third time you've said this, so I feel the need to respond.=20 So here's how I would like to see this go (i.e., here's the rule I want for these cases): Rule: Anyone suggesting a charter milestone item must agree to the the following conditions: =20 (i). You (or your agent) must commit to write the document that fulfils the proposed milestone, and=20 (ii). If you (or your agent) defaults on the commitment described in (i). above, that is, if the document is not delivered in a timely fashion (where timely is defined by the charter milestone), the charter milestone will be removed and rechartering the WG is *not* necessary, and =20 (iii). The authorative AD(s) must also agree to these conditions. =20 Now, I don't know if a WG/BOF/proposer/chair can articulate such a rule, but then, in the IETF rules are made up as we go along, so why not (its not as if the IETF is a legal (or even quasi-legal) system after all)? In any event, I will say that without such a rule, arbitrary milestones (constructed for whatever reason) can be injected into the charter, and clearly, no one wants that. In the case of the document you are proposing (I think its a document, correct me if I'm wrong), if you (or your agent) commit to the above conditions, and if the document you propose does not hold up/gate any other WG document (i.e., no other WG document can have a normative reference to this this document), I see no reason not to add such an item. Otherwise, I would be reluctant to add such a milestone. Dave --bp/iNruPH9dso1Pn 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) iEYEARECAAYFAkl4muMACgkQORgD1qCZ2KdMrwCdGMX1k4d2sfFwapqtXjE4ElVf kTwAn2T2Q9NktlUDEebZQbWPfpUn68KT =8ZrO -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- --===============2079576775== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============2079576775==-- From lisp-bounces@ietf.org Thu Jan 22 09:34:29 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7743A6931; Thu, 22 Jan 2009 09:34:29 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822583A6BA7; Wed, 21 Jan 2009 08:42:53 -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 daLuZqbl-MmZ; Wed, 21 Jan 2009 08:42:52 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B29B53A6990; Wed, 21 Jan 2009 08:42:52 -0800 (PST) Received: from [75.217.136.252] (252.sub-75-217-136.myvzw.com [75.217.136.252]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0LGfuBE027546; Wed, 21 Jan 2009 08:41:58 -0800 (PST) Message-ID: <49775054.9090702@isi.edu> Date: Wed, 21 Jan 2009 08:41:56 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ross Callon References: <20090120190744.GA9467@1-4-5.net><00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com><49771CF4.6060609@cisco.com><00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> <4977296A.50502@cisco.com> <3525C9833C09ED418C6FD6CD9514668C05858248@emailwf1.jnpr.net> In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C05858248@emailwf1.jnpr.net> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Thu, 22 Jan 2009 09:34:27 -0800 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, PAPADIMITRIOU Dimitri Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ross Callon wrote: > In order to make an ID/Loc split work on an Internet-wide ubiquitous > scale, we need very good solutions and/or greater understanding to some > hard questions such as what will be the granularity of the mapping > function (how large will the mapping table be and what granularity of > prefix will be in it), how to do the mapping, how to do liveness > detection, what the scaling properties of the mapping and liveness > detection functions is likely to be, and what the manageability, > security, and robustness implications are. I guess that while we are at > it we need to figure out if there are other issues, such as MTU, that > need consideration. I could not agree more, but, as others have noted, the LISP WG's purpose is to split out the work of documenting the LISP protocols as experimental. This does not preclude the needed research above from happening in the IRTF. A note on these issues might be useful to include in the LISP documents under 'deployment considerations' or 'open issues'. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl3UFMACgkQE5f5cImnZrtMvgCfT7n3hc+/TCYz7D4qVhtWQMy+ +24AoK/cNNkHaiO/Mx0uYiAmmVkeiO+G =W3kf -----END PGP SIGNATURE----- _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 22 09:34:29 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C71528C140; Thu, 22 Jan 2009 09:34:29 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7836B3A699E; Wed, 21 Jan 2009 16:44:55 -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=[AWL=0.000, 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 TYfbA7f2xuP0; Wed, 21 Jan 2009 16:44:54 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id AA72E3A692D; Wed, 21 Jan 2009 16:44:54 -0800 (PST) Received: from [10.0.1.200] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 62CE14343DD; Wed, 21 Jan 2009 16:44:01 -0800 (PST) Message-Id: <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> From: David Conrad To: David Meyer In-Reply-To: <20090122000220.GA25832@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 21 Jan 2009 16:43:59 -0800 References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> <20090121185431.GA14875@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> <20090122000220.GA25832@1-4-5.net> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Thu, 22 Jan 2009 09:34:27 -0800 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG astowhether aWG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Hi, Sorry for being a bit late to this discussion (day job and other realities intruding), but having had a small role in the Dublin BOF, I don't think it likely (in the extreme) there would be significant benefit from having a second BOF. I'd like to second Dave's seconding of Brain's statement: On Jan 21, 2009, at 4:02 PM, David Meyer wrote: > In any event, Brian really summed it up quite nicely: > > ... > But I don't see the point in a second BOF; the idea > that a BOF could resolve in a couple of hours the > issues that the RRG has been discussing since early > 2007 seems unlikely. I'd actually go a bit further and suggest that any attempt by any group to resolve the issues the RRG has been discussing (or any of the various other discussions that occurred prior to RRG taking this on) as a pre-requisite for creating a working group to standardize an experimental protocol in this space would be equivalent to declaring no protocol in this space will _ever_ be standardized. LISP is _an_ approach towards routing scalability. It is not the only one. Standardizing the experimental protocol would allow folks interested in routing scalability to explore one or two axes of the possible solution space. To be honest, I'm unclear as to why there is even a question as to whether a WG should be created... Regards, -drc _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 22 09:34:29 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30F9528C24A; Thu, 22 Jan 2009 09:34:29 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0F928C18A; Thu, 22 Jan 2009 08:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 DDMAr5TlSxMT; Thu, 22 Jan 2009 08:36:05 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 973EA3A6A44; Thu, 22 Jan 2009 08:36:05 -0800 (PST) Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0MGYwAY025845; Thu, 22 Jan 2009 08:35:00 -0800 (PST) Message-ID: <4978A032.2040409@isi.edu> Date: Thu, 22 Jan 2009 08:34:58 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Meyer References: <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> <00275A5B436CA441900CB10936742A3801A2E561@FRVELSMBS22.ad2.ad.alcatel.com> <20090122161219.GA10278@1-4-5.net> In-Reply-To: <20090122161219.GA10278@1-4-5.net> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Thu, 22 Jan 2009 09:34:27 -0800 Cc: int-area@ietf.org, PAPADIMITRIOU Dimitri , lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Proposed rule for adding charter milestones [was Re: Please....] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Charters should not include applicability statements themselves, IMO. If you want to add the generation of such a document, that seems fair. Joe David Meyer wrote: > Dimitri, > >> => i would be less affirmative in making such statement -a priori-. in >> order to consolidate our understanding, the charter should include an >> item on how LISP addresses routing scalability and other design goals >> (at least as much as the experiment result allows). this would at the >> same time close the loop with part of the RRG work. > > This is the second or third time you've said this, so I > feel the need to respond. > > So here's how I would like to see this go (i.e., here's > the rule I want for these cases): > > Rule: Anyone suggesting a charter milestone item must > agree to the the following conditions: > > (i). You (or your agent) must commit to write the > document that fulfils the proposed > milestone, and > > (ii). If you (or your agent) defaults on the > commitment described in (i). above, that > is, if the document is not delivered in a > timely fashion (where timely is defined by > the charter milestone), the charter > milestone will be removed and rechartering > the WG is *not* necessary, and > > (iii). The authorative AD(s) must also agree to > these conditions. > > Now, I don't know if a WG/BOF/proposer/chair can > articulate such a rule, but then, in the IETF rules are > made up as we go along, so why not (its not as if the > IETF is a legal (or even quasi-legal) system after all)? > In any event, I will say that without such a rule, > arbitrary milestones (constructed for whatever reason) > can be injected into the charter, and clearly, no one > wants that. > > In the case of the document you are proposing (I think > its a document, correct me if I'm wrong), if you (or your > agent) commit to the above conditions, and if the > document you propose does not hold up/gate any other WG > document (i.e., no other WG document can have a normative > reference to this this document), I see no reason not to > add such an item. Otherwise, I would be reluctant to add > such a milestone. > > Dave > > > ------------------------------------------------------------------------ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 22 09:58:30 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B9E3A6836; Thu, 22 Jan 2009 09:58:30 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E6D3A6836; Thu, 22 Jan 2009 09:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 bhtCXuvHRXg6; Thu, 22 Jan 2009 09:58:28 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id EB04D3A6774; Thu, 22 Jan 2009 09:58:27 -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 n0MHw60U013192; Thu, 22 Jan 2009 09:58:06 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0MHw6Sp013191; Thu, 22 Jan 2009 09:58:06 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 09:58:06 -0800 From: David Meyer To: Joe Touch Message-ID: <20090122175806.GB13097@1-4-5.net> References: <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> <00275A5B436CA441900CB10936742A3801A2E561@FRVELSMBS22.ad2.ad.alcatel.com> <20090122161219.GA10278@1-4-5.net> <4978A032.2040409@isi.edu> MIME-Version: 1.0 In-Reply-To: <4978A032.2040409@isi.edu> 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: int-area@ietf.org, PAPADIMITRIOU Dimitri , lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Proposed rule for adding charter milestones [was Re: Please....] 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: , Content-Type: multipart/mixed; boundary="===============1116587533==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1116587533== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey Joe, A couple of things. First, the below "rule" was a strawman. And of course, if the community of interest wants an item on the charter, consensus rules (at least that's the way I've always done approached charter writing, and I think we all agree on that one). > Charters should not include applicability statements themselves, IMO. If > you want to add the generation of such a document, that seems fair. Agreed, fair enough. Dave --3uo+9/B/ebqu+fSQ 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) iEYEARECAAYFAkl4s64ACgkQORgD1qCZ2Kcg9gCfUeIlfV4ScAUKEVPuBRAMvC9O ikcAnjhuMYkbDCi+I9sQNNppqWTo/Ypr =NkUD -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- --===============1116587533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1116587533==-- From lisp-bounces@ietf.org Thu Jan 22 12:57:58 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF33E28C272; Thu, 22 Jan 2009 12:57:58 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4CA28C248 for ; Thu, 22 Jan 2009 12:57:57 -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 m+GaE6COseI8 for ; Thu, 22 Jan 2009 12:57:50 -0800 (PST) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id A9D6E28C271 for ; Thu, 22 Jan 2009 12:57:49 -0800 (PST) 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=f93cA6trcwKfwK51Z+RfdkkwWAc=; b=gD/cIcHdU4 0+yncrqP4cG2biC35nWChu818bi201SYoqBhAtz0aN7vQwp2qFpM+kNTem7lnTFf hsiS+ssohgdeNSPCUQ45mykR8B1YPwlECi0VQ2GZRTKnIOmtswrOUyySySW0f8FO Ga/onf9E1hHpEoyzqM3AslxH0PfTlXPLM= 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=0Bk6C M7xd6shrLO3PoaEZ8y7/WdWLeAoYQAYA1NfLD+YL3uKC+TxEX1KjqpWhP/ixf19I Sa5GDZ7Vt2iFBieTKdCDXP0Jnw6hmViW9Lysz0EwPdV1IgrlK6hW1bNEn5SupJLZ PmLAfWhNRrk+gCcJXs8tUayaPwRBhbBk+VzbaY= Received: from mbpobo.local (bonaventure.info.ucl.ac.be [130.104.240.230]) (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; Thu, 22 Jan 2009 21:57:19 +0100 (CET) Message-ID: <4978DDA8.5080505@uclouvain.be> Date: Thu, 22 Jan 2009 21:57:12 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dino Farinacci References: <49778EE1.8050407@uclouvain.be> <45A96B82-9301-4935-A251-7B4DB8E8BD22@cisco.com> In-Reply-To: <45A96B82-9301-4935-A251-7B4DB8E8BD22@cisco.com> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 731F9CF31E.415E6 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] The case for Map-Updates 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dino, >> In the current LISP specification, two mapping messages are defined : >> >> - Map-Request that allows to request the set of RLOCs corresponding to a >> given EID >> - Map-Reply that provides the mapping between an EID block and a set of >> RLOCs >> >> These two messages basically assume that the mapping database is built >> by means that are outside of the LISP protocols (e.g. manual >> configuration). I think that we should add a third message to add or >> update entries in the mapping databases : >> >> - Map-Update : this message is used when an entity needs to add a new >> mapping in the database or update an existing entry in the mapping >> database. There should, of course, be a way to authenticate the sender >> of the mapping update > > The mapping database are distributed. It is not centralized. When a site > becomes a LISP site, the new EID-to-RLOC mapping is configured in the > ETRs that reside at the site. > > So I don't know who would send the Map-Update and who would receive it. I see two possible scenarios. 1- The mapping server does not reside on the ETR that serves the EID (e.g. this is a redundant mapping server) 2- In a LISP site served by several ETRs, these ETRs will need to exchange information so that they all maintain the same EID-to-RLOC mapping for the local EID. When something changes in the mapping (e.g. new RLOC, different weigth or different preferences), it should be possible to dynamically inform all the mapping servers that are responsible for this mapping. > If this model changes because there is a different mapping database > employed, then the message can be introduced at that time. It would also be useful for different mapping systems than ALT. >> These Map-Update messages would be useful in different scenarios : >> - an xTR needs to change its RLOC > > We have Solicit-Map-Requests that do that. SMR allows to sollicit a new map request, it does not allow an xTR to update the mapping on the other mapping servers that are responsible for the same EID. >> - an xTR is being shutdown or will be shutdown in some time and need to >> force a removal of the corresponding mapping entry > > Today, the xTR can just go away. In fact, mappings that are cached by > remote ITRs need to stay in tack because there are other xTRs at the > site which are being used. The loc-reach-bit for the xTR coming out of > service can be set to 0 immediately until the time an SMR is sent to > remove the RLOC from the mapping. The other xTRs of the site need to be informed about the shutdown of the local xTR. If this is a sudden shutdown, they will be informed by e.g. the IGP protocol, but if this is a planned shutdown, then it is useful to inform the other xTRs and mapping servers in advance. >> - load-balanced xTR are overloaded and their weight needs to be updated > > SMRs do this too. Or you can source-quench the source by advertising the > RLOC as unreachable for a short period of time. There are already simple > mechanisms in place that seem to work well. SMRs allow to sollicit a new Map-request, but this Map-Request will be received by any of the mapping servers (e.g. xTR) that serve the site. These mapping servers need to be coherent and advertise the same EID-to-RLOC mappings. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 22 13:13:21 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271F028C28D; Thu, 22 Jan 2009 13:13:21 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D967428C272 for ; Thu, 22 Jan 2009 13:13:19 -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=[AWL=0.000, 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 v2dA3xqRqTrg for ; Thu, 22 Jan 2009 13:13:14 -0800 (PST) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id DCFC73A6938 for ; Thu, 22 Jan 2009 13:13:13 -0800 (PST) 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=5cI9YLybDFxmbbWt7dv2yQA7rgU=; b=A3/+khvVsM Vsm5Nu+LLvWVkx1bCh5uMOL7zYCDgKNziaU9hSEg93+lcpeyDOqX7XD/hd7ToJNx D2Vn0qgMn1bCAJev/LS0gbbj5LXQIShJExoz+qCnq1bDzVCLXOxzwWOcCRv55/Xg NxVsmSqac+4gnqsBU9YawLQ8u44JTcE3s= 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=mJZYi bTzjKaVc4PAK/J5dt8odqMpNYn6X0r9C71jVVVnhUaYzCt8FpUJGfitc0vc5BNtr nnbYVqrcU10GguFvgoXJxkQDZficSduBeG6a16Eq1FIyPvDHTUeWqDvUZBSM29xC WzgCwn4kDzjHU3SNyxPECJCPFJNNT8oKJCt4eY= Received: from mbpobo.local (bonaventure.info.ucl.ac.be [130.104.240.230]) (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; Thu, 22 Jan 2009 22:12:51 +0100 (CET) Message-ID: <4978E148.1050600@uclouvain.be> Date: Thu, 22 Jan 2009 22:12:40 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dino Farinacci References: <49730E98.1030101@uclouvain.be> <4976453C.4020306@uclouvain.be> <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> In-Reply-To: <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 2ACABEB679.BEFE1 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] Locator liveness problem 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dino, >>>> a. Failure of an ETR >>>> >>>> b. Failure of (one of the link) directly attached to an ETR to its >>>> provider >>> >>> These are covered by the loc-reach-bits and have been in the LISP spec >>> for quite a long time. I think dating back to the -02 draft. >> >> There are some issues with loc-reach-bits that are part of the LISP >> spec : >> - The support for more than 31 locators is cumbersome (maybe 31 >> locoators is sufficient for most deployments, including experimental >> ones, but I don't think that it's future proof) > > That was removed in -11. I missed this update in December. I'm now reading version 11 in details and will provide more feedback next week. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 22 13:15:09 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701A028C299; Thu, 22 Jan 2009 13:15:09 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA07428C272; Thu, 22 Jan 2009 13:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.199, 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 jnjw8omTis3n; Thu, 22 Jan 2009 13:15:07 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id F10C128C262; Thu, 22 Jan 2009 13:15:06 -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 n0MLEaoj020175; Thu, 22 Jan 2009 13:14:36 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0MLEaBP020174; Thu, 22 Jan 2009 13:14:36 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 13:14:36 -0800 From: David Meyer To: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Message-ID: <20090122211436.GA20128@1-4-5.net> MIME-Version: 1.0 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] LISP agenda update 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: , Content-Type: multipart/mixed; boundary="===============0518257745==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0518257745== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks,=20 Dimitri and I had a conversation about his request for a agenda item on how LISP fits with draft-irtf-rrg-design-goals-01.=20 The new agenda is included below. Comments please. Dave --- LISP (Locator/ID Separation Protocol) Last Modified: 2009-01-23 Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Secretary(ies): TBD =20 Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: LISP and companion documents (see below) are proposals that respond to the problems discussed at the IAB's October, 2006 Routing and Addressing Workshop [0]. The purpose of the BOF is to form a working group whose charter (see below) is to work on the design on the LISP base protocol [1], the LISP+ALT mapping system [2], LISP Interworking [4] and LISP multicast [6]. 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 (presumably using technology developed in the SIDR working group). 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 Recommendations for Securing the LISP Mapping System to the IESG for Experimental. Jul 2010 Submit LISP for Multicast Environments to the IESG for Experimental.=20 Jul 2010 Submit Recommendations on how LISP protocols (LISP base protocol, LISP+ALT mapping system, and LISP multicast) address the Design Goals for Scalable Internet Routing [1]. Aug 2010 Re-charter or close. Internet-Drafts: draft-farinacci-lisp-11.txt draft-farinacci-lisp-multicast-01.txt draft-fuller-lisp-alt-03.txt draft-lewis-lisp-interworking-02.txt Request For Comments: None References ---------- [0] Meyer, D. et. al., "Report from the IAB Workshop on Routing and Addressing", RFC 4984. [1] Farinacci, D. et. al., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-11.txt. [2] Fuller, V., et. al., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-03.txt [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-00.txt. [4] Lewis, D., et. al., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-02.txt. [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt. [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 --5mCyUwZo2JvN/JJP 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) iEYEARECAAYFAkl44bwACgkQORgD1qCZ2KcrnQCeLL/GSSjIrqc65xDKkGQSdlU3 7RcAni8edWkyALkFNNHgr3obuO1qDaX9 =lLVW -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- --===============0518257745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0518257745==-- From lisp-bounces@ietf.org Thu Jan 22 13:24:17 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F9828C2AC; Thu, 22 Jan 2009 13:24:17 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B343928C296; Thu, 22 Jan 2009 13:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 mQ6l-VbRIx6a; Thu, 22 Jan 2009 13:24:16 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 160A43A6938; Thu, 22 Jan 2009 13:24:16 -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 n0MLNxF5020961; Thu, 22 Jan 2009 13:23:59 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0MLNx1f020960; Thu, 22 Jan 2009 13:23:59 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 13:23:59 -0800 From: David Meyer To: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Message-ID: <20090122212359.GA20932@1-4-5.net> References: <20090122211436.GA20128@1-4-5.net> MIME-Version: 1.0 In-Reply-To: <20090122211436.GA20128@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] s/agenda/charter/g [Re: LISP agenda update] 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: , Content-Type: multipart/mixed; boundary="===============1826491837==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1826491837== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sorry about that (and the noise). Dave --qDbXVdCdHGoSgWSk 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) iEYEARECAAYFAkl44+8ACgkQORgD1qCZ2Kc8+QCfX5GoaCyezv0bP7fAXuOK/NpQ o5MAoIjNZw6T5Bc2MsAaIFQKHsAX5mLN =R8Ic -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- --===============1826491837== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1826491837==-- From lisp-bounces@ietf.org Thu Jan 22 14:26:23 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ADBE28C102; Thu, 22 Jan 2009 14:26:23 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84763A6856; Thu, 22 Jan 2009 14:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 AA2xeSG-e4xx; Thu, 22 Jan 2009 14:26:14 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 8B5D93A67F5; Thu, 22 Jan 2009 14:26: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 n0MMPwLw022785; Thu, 22 Jan 2009 14:25:58 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0MMPw45022784; Thu, 22 Jan 2009 14:25:58 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 14:25:57 -0800 From: David Meyer To: rrg@irtf.org, lisp@ietf.org Message-ID: <20090122222557.GA22719@1-4-5.net> MIME-Version: 1.0 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-meyer-loc-id-implications-01.txt posted 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: , Content-Type: multipart/mixed; boundary="===============0630017524==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0630017524== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable See http://www.1-4-5.net/~dmm/draft-meyer-loc-id-implications-01.txt until the internet-drafts people get around to it. Dave =09 --W/nzBZO5zC0uMSeA 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) iEYEARECAAYFAkl48nUACgkQORgD1qCZ2KcIKgCdHIfDEqN21arc8Hpo/F4DRoSs Wa8AmwcglTy6wvjvwdW9upfQa9lq5Ekd =zWq4 -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- --===============0630017524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0630017524==-- From lisp-bounces@ietf.org Thu Jan 22 22:17:08 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954DF3A6902; Thu, 22 Jan 2009 22:17:08 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48C03A6905 for ; Thu, 22 Jan 2009 22:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 OqKqUXln0tSW for ; Thu, 22 Jan 2009 22:17:00 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 621BE3A682E for ; Thu, 22 Jan 2009 22:17:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,311,1231113600"; d="scan'208";a="28581647" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 23 Jan 2009 06:16: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 n0N6GhfF029060; Thu, 22 Jan 2009 22:16:43 -0800 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 n0N6GhBt021166; Fri, 23 Jan 2009 06:16:43 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); Thu, 22 Jan 2009 22:16:43 -0800 Received: from [192.168.1.2] ([10.21.114.173]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 22:16:42 -0800 Message-Id: From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <4978DDA8.5080505@uclouvain.be> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 22 Jan 2009 22:16:42 -0800 References: <49778EE1.8050407@uclouvain.be> <45A96B82-9301-4935-A251-7B4DB8E8BD22@cisco.com> <4978DDA8.5080505@uclouvain.be> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Jan 2009 06:16:43.0123 (UTC) FILETIME=[29409C30:01C97D22] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2332; t=1232691404; x=1233555404; 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]=20The=20case=20for=20Map-Updates |Sender:=20; bh=00xuXdSGrjcWO08xHz6h/zKibWXg6QPktq3kDmt4R4c=; b=uA46jB7sYoEVA6ae7Jj367o2vkHPJ5dd7NelpFuaezyxcnoWnj8SFxXuTC 1H/ulkC2esrMYX2z29LN2+FLEDrNRqp9uKlnhKSKsFo7Cw5cu6KQOq18Fjpy nONjSpHpiiukG1uDJd/+Xw1bSQyez5uGoNsrBHDoqO9XM/YOC0jes=; 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] The case for Map-Updates 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > SMR allows to sollicit a new map request, it does not allow an xTR to > update the mapping on the other mapping servers that are responsible > for > the same EID. The point of soliciting a map-request is so you can return a map-reply with updated information. The way it works is like this: o I am an ETR with a mapping change. o I solicit at the rate I want to receive requests by setting the SMR- bit for the active sites I am talking to. Because those sites will need the new information sooner than the ones not talking to me. o You are a site that is talking to me so I ask you to send me a Map- Request. o You then send me a Map-Request and I return a Map-Reply. o I remember I sent you the updated mapping data so the loc-reach-bits I send you reflect the new mapping. That's all there is to it. >>> - an xTR is being shutdown or will be shutdown in some time and >>> need to >>> force a removal of the corresponding mapping entry >> >> Today, the xTR can just go away. In fact, mappings that are cached by >> remote ITRs need to stay in tack because there are other xTRs at the >> site which are being used. The loc-reach-bit for the xTR coming out >> of >> service can be set to 0 immediately until the time an SMR is sent to >> remove the RLOC from the mapping. > > The other xTRs of the site need to be informed about the shutdown of > the > local xTR. If this is a sudden shutdown, they will be informed by e.g. > the IGP protocol, but if this is a planned shutdown, then it is useful > to inform the other xTRs and mapping servers in advance. They are all configured at the same time. >>> - load-balanced xTR are overloaded and their weight needs to be >>> updated >> >> SMRs do this too. Or you can source-quench the source by >> advertising the >> RLOC as unreachable for a short period of time. There are already >> simple >> mechanisms in place that seem to work well. > > SMRs allow to sollicit a new Map-request, but this Map-Request will be > received by any of the mapping servers (e.g. xTR) that serve the site. > These mapping servers need to be coherent and advertise the same > EID-to-RLOC mappings. Right, but the xTR that is old will have loc-reach-bits relative to the locator-set it is sending. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 22 22:18:21 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBF63A6902; Thu, 22 Jan 2009 22:18:21 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 964D13A69C3 for ; Thu, 22 Jan 2009 22:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 jWubVYeI8qAq for ; Thu, 22 Jan 2009 22:18:18 -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 C1E1B3A682E for ; Thu, 22 Jan 2009 22:18:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,311,1231113600"; d="scan'208";a="132601996" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 23 Jan 2009 06:18:02 +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 n0N6I2UZ002937; Thu, 22 Jan 2009 22:18:02 -0800 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 n0N6I2HK022085; Fri, 23 Jan 2009 06:18:02 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); Thu, 22 Jan 2009 22:18:01 -0800 Received: from [192.168.1.2] ([10.21.114.173]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 22:18:01 -0800 Message-Id: From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <4978E148.1050600@uclouvain.be> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 22 Jan 2009 22:18:01 -0800 References: <49730E98.1030101@uclouvain.be> <4976453C.4020306@uclouvain.be> <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> <4978E148.1050600@uclouvain.be> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Jan 2009 06:18:01.0544 (UTC) FILETIME=[57FEB480:01C97D22] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=977; t=1232691482; x=1233555482; 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]=20Locator=20liveness=20problem |Sender:=20; bh=Qkcg2cURANU7T5Czp/14QO+i8XujZhfxPVjAtXqksss=; b=Hms7sKzXeZfvf2YddIDsGDKZvmF/u+v5f41TpKUi+wQNxQuJxeCtjbL3QV +kSBVgJrobgelYrdx4mgrX4X7EIsojD5J44lo/JxvH7ZvZnHqtgt5OayBg7U aj+tfa+q24; 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] Locator liveness problem 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Great thanks. Now that we have this list, we will announce updates to any LISP related specs. Dino On Jan 22, 2009, at 1:12 PM, Olivier Bonaventure wrote: > Dino, >>>>> a. Failure of an ETR >>>>> >>>>> b. Failure of (one of the link) directly attached to an ETR to its >>>>> provider >>>> >>>> These are covered by the loc-reach-bits and have been in the LISP >>>> spec >>>> for quite a long time. I think dating back to the -02 draft. >>> >>> There are some issues with loc-reach-bits that are part of the LISP >>> spec : >>> - The support for more than 31 locators is cumbersome (maybe 31 >>> locoators is sufficient for most deployments, including experimental >>> ones, but I don't think that it's future proof) >> >> That was removed in -11. > > I missed this update in December. I'm now reading version 11 in > details > and will provide more feedback next week. > > Olivier > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 23 05:53:56 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E6E3A6AA5; Fri, 23 Jan 2009 05:53:56 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F1C3A6858 for ; Fri, 23 Jan 2009 05:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 yHzc0N1yBBgA for ; Fri, 23 Jan 2009 05:53:53 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id 6FA213A68DF for ; Fri, 23 Jan 2009 05:53:52 -0800 (PST) Received: from [IPv6:2001:13c7:7001:5000:216:cbff:fe98:665f] (unknown [IPv6:2001:13c7:7001:5000:216:cbff:fe98:665f]) by mail.lacnic.net.uy (Postfix) with ESMTP id 97BE130846D; Fri, 23 Jan 2009 11:53:31 -0200 (UYST) Message-Id: <346EBDE0-A67E-4324-A3E0-3009147FFE2A@lacnic.net> From: Roque Gagliano To: David Meyer In-Reply-To: <20090121211359.GA17680@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 23 Jan 2009 11:53:31 -0200 References: <20090120162603.GA3374@1-4-5.net> <49778BA7.2060200@uclouvain.be> <20090121211359.GA17680@1-4-5.net> 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 Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] updated 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: , Content-Type: multipart/mixed; boundary="===============0368402856==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0368402856== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-140-1008540871" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-140-1008540871 Content-Type: multipart/alternative; boundary=Apple-Mail-139-1008540813 --Apple-Mail-139-1008540813 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit hi, I wanted to re-transmit what I believe I discussed with some of you at the Dublin meeting. Today SIDR has a signed object (called ROA) that maps prefixes to origin ASN, what I was proposing was using the same certificates from the RPKI generated a new kind of object (CMS wrapped) that maps EID to a list of possible RLOCs. I can work on some text soon. Roque On Jan 21, 2009, at 7:13 PM, David Meyer wrote: > > Olivier, > >>> 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. >> >> I don't think that we should restrict the mapping discussion to ALT >> even >> if ALT is the only deployed solution today. > > I understand your point (LISP is modular in the mapping > system). However, I was writing milestones here, so this > one needs to stay. > > So do you want to add another milestone around mapping > systems, and if so, send some text of what you have in > mind and we can work on that. > >>> Mar 2010 Submit the LISP Interworking specification to the IESG >>> for Experimental. >>> >>> June 2010 Submit Recommendations for Allocation and Routing >>> of both EIDs and RLOCs to the IESG for Experimental. >>> >>> June 2010 Submit Recommendations for Securing the LISP Mapping >>> System to the IESG for Experimental. >> >> I think that the discussion on Securing the LISP Mapping System >> should >> be finished before the finalisation of any mapping proposal. This >> discussion is likely to define a set of requirements to be met by >> mapping systems. > > In general, yes. In the particular case of ALT, we will > do whatever SIDR does. However, we do not want to gate > progress on ALT by whatever is being done SIDR. So maybe > we can have the ALT draft be self-contained (all this > stuff about SIDR could go in a Security Considerations > section in the ALT document), and whoever writing the > Recommendations Draft can also point at that. Does that > make sense? > > Dave > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-139-1008540813 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi,

I wanted = to re-transmit what I believe I discussed with some of you at the Dublin = meeting. Today SIDR has a signed object (called ROA) that maps prefixes = to origin ASN, what I was proposing was using the same = certificates from the RPKI generated a new kind of object (CMS wrapped) = that maps EID to a list of possible RLOCs. I can work on some text = soon.

Roque



On Jan 21, 2009, at 7:13 PM, David Meyer = wrote:


Olivier,

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.

I don't think = that we should restrict the mapping discussion to ALT = even
if ALT is the only = deployed solution today.

I = understand your point (LISP is modular in the mapping
system). = However, I was writing milestones here, so this
one needs = to stay.

= So do you want to add another milestone around = mapping
= systems, and if so, send some text of what you have in
mind and = we can work on that.

Mar 2010  Submit the LISP Interworking specification = to the IESG
 for = Experimental.

June 2010 Submit Recommendations = for Allocation and Routing
 of both EIDs and RLOCs to = the IESG for Experimental.

June 2010 Submit Recommendations = for Securing the LISP Mapping
 System to the IESG for = Experimental.

I think that = the discussion on Securing the LISP Mapping System = should
be finished before the = finalisation of any mapping proposal. This
discussion is likely to define a set of requirements to be = met by
mapping = systems.

In general, yes. In the = particular case of ALT, we will
do whatever SIDR does. However, = we do not want to gate
progress on ALT by whatever is = being done SIDR. So maybe
we can have the ALT draft be = self-contained (all this
stuff about SIDR could go in a = Security Considerations
section in the ALT document), and = whoever writing the
Recommendations Draft can also = point at that. Does that
make sense?

= Dave

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

= --Apple-Mail-139-1008540813-- --Apple-Mail-140-1008540871 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) iEYEARECAAYFAkl5y9sACgkQnk+WSgHpbO62BwCfUe5e4s4fmw5KTBLB1dV616ak 6fkAn0G6F/Jol1EFPjM1MgyGg7KVO76D =Xr8W -----END PGP SIGNATURE----- --Apple-Mail-140-1008540871-- --===============0368402856== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0368402856==-- From lisp-bounces@ietf.org Fri Jan 23 06:31:36 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E3128C12F; Fri, 23 Jan 2009 06:31:36 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A209E28C0DB for ; Fri, 23 Jan 2009 06:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 KlX9hrmoqVsi for ; Fri, 23 Jan 2009 06:31:29 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 51E9528C178 for ; Fri, 23 Jan 2009 06:31:29 -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 n0NEVCAb008497; Fri, 23 Jan 2009 06:31:12 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0NEVC6Q008491; Fri, 23 Jan 2009 06:31:12 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 23 Jan 2009 06:31:12 -0800 From: David Meyer To: Roque Gagliano Message-ID: <20090123143112.GA8470@1-4-5.net> References: <20090120162603.GA3374@1-4-5.net> <49778BA7.2060200@uclouvain.be> <20090121211359.GA17680@1-4-5.net> <346EBDE0-A67E-4324-A3E0-3009147FFE2A@lacnic.net> MIME-Version: 1.0 In-Reply-To: <346EBDE0-A67E-4324-A3E0-3009147FFE2A@lacnic.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) Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] updated 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: , Content-Type: multipart/mixed; boundary="===============2111179033==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============2111179033== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 23, 2009 at 11:53:31AM -0200, Roque Gagliano wrote: > hi, > > I wanted to re-transmit what I believe I discussed with some of you at = =20 > the Dublin meeting. Today SIDR has a signed object (called ROA) that =20 > maps prefixes to origin ASN, what I was proposing was using the same =20 > certificates from the RPKI generated a new kind of object (CMS wrapped)= =20 > that maps EID to a list of possible RLOCs. I can work on some text soon. Awesome Roque. Look forward to seeing your draft. Dave --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) iEYEARECAAYFAkl51LAACgkQORgD1qCZ2KcrcgCfSaW0A08DxDGW+Owf3ZElDf90 Wr8AoInagAPMW8UXoCCVRxcRkARVhH7O =Iv1g -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- --===============2111179033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============2111179033==-- From lisp-bounces@ietf.org Fri Jan 23 08:38:48 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FCC23A6A55; Fri, 23 Jan 2009 08:38:48 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10A73A6A55 for ; Fri, 23 Jan 2009 08:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 3qz8hSufOK9j for ; Fri, 23 Jan 2009 08:38:42 -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 327893A6929 for ; Fri, 23 Jan 2009 08:38:42 -0800 (PST) Received: from [130.149.220.21] (kea.net.t-labs.tu-berlin.de [130.149.220.21]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 854A670015D8; Fri, 23 Jan 2009 17:38:24 +0100 (CET) Message-ID: <4979F27F.7090904@net.t-labs.tu-berlin.de> Date: Fri, 23 Jan 2009 17:38:23 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Joel M. Halpern" References: <20090120162133.GA2929@1-4-5.net> <4975FEB1.7070600@joelhalpern.com> In-Reply-To: <4975FEB1.7070600@joelhalpern.com> X-Enigmail-Version: 0.95.0 Cc: lisp@ietf.org Subject: Re: [lisp] Please respond: Questions from the IESG on whether a WG forming BOF is necessary 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Joel M. Halpern wrote: > Given the target (a WG to produce experimental specificaitons) I can > see no benefit in an additional BoF. > I fully agree on this. Luigi > Joel > > David Meyer wrote: >> Folks, >> >> I'm being asked (by the IESG) whether people believe >> that we can go directly to our first WG meeting at the >> next IETF or if another WG forming BOF is necessary. >> >> Here are the current facts on the ground: >> o We have fairly mature set of core drafts >> o There are a number of other (non-core) LISP drafts >> o Significant global deployment is underway >> o We have 2 or more implementations o We have been discussing >> a draft charter (see update below) >> >> The question is that I would like folks to respond to is >> >> "Should a WG be formed following the draft agenda >> (below), or should we have another BOF?" >> >> Please give your opinion as soon as possible so we can >> close on these administrative issues. >> >> Thanks, >> >> Dave >> -- >> >> LISP (Locator/ID Separation Protocol) >> >> Last Modified: 2009-01-20 >> >> Chair(s): >> TBD >> >> Internet Area Director(s): >> TBD >> >> Routing Area Advisor: >> TBD >> >> Secretary(ies): >> TBD >> >> Mailing Lists: >> General Discussion: lisp@ietf.org >> >> Description of Working Group: >> >> LISP and companion documents (see below) are proposals that >> respond to the problems discussed at the IAB's October, 2006 >> Routing and Addressing Workshop [0]. The purpose of the BOF is to >> form a working group whose charter (see below) is to work on the >> design on the LISP base protocol [1], the LISP+ALT mapping system >> [2], LISP Interworking [4] and LISP multicast [6]. The working >> group will encourage and support interoperable LISP >> implementations as well as defining requirements for alternate >> mapping systems. The Working Group may also create EID-prefix >> assignment guidelines for RIRs, as well as security profiles for >> the ALT (presumably using technology developed in the SIDR >> working group). >> >> 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. >> >> Mar 2010 Re-charter or close. >> >> Internet-Drafts: >> draft-farinacci-lisp-11.txt >> draft-farinacci-lisp-multicast-01.txt >> draft-fuller-lisp-alt-03.txt >> draft-lewis-lisp-interworking-02.txt >> >> Request For Comments: >> None >> >> >> References >> ---------- >> [0] Meyer, D. et. al., "Report from the IAB Workshop on >> Routing and Addressing", RFC 4984. >> >> [1] Farinacci, D. et. al., "Locator/ID Separation Protocol >> (LISP)", draft-farinacci-lisp-11.txt. >> >> [2] Fuller, V., et. al., "LISP Alternative Topology >> (LISP-ALT)", draft-fuller-lisp-alt-03.txt >> >> [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation >> Report", draft-iannone-openlisp-implementation-00.txt. >> >> [4] Lewis, D., et. al., "Interworking LISP with IPv4 and >> IPv6", draft-lewis-lisp-interworking-02.txt. >> >> [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map >> identifiers onto locators", draft-mathy-lisp-dht-00.txt. >> >> [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, >> "LISP for Multicast Environments", >> draft-farinacci-lisp-multicast-01.txt. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 23 09:10:08 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81C9A28C1F3; Fri, 23 Jan 2009 09:10:08 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253333A6AD4 for ; Fri, 23 Jan 2009 09:10:07 -0800 (PST) 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 vugMU5gQFgEe for ; Fri, 23 Jan 2009 09:10:05 -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 872583A67F2 for ; Fri, 23 Jan 2009 09:10:05 -0800 (PST) Received: from [130.149.220.21] (kea.net.t-labs.tu-berlin.de [130.149.220.21]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 2D56070015D8; Fri, 23 Jan 2009 18:09:48 +0100 (CET) Message-ID: <4979F9DB.9030601@net.t-labs.tu-berlin.de> Date: Fri, 23 Jan 2009 18:09:47 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Dino Farinacci References: <49778EE1.8050407@uclouvain.be> <45A96B82-9301-4935-A251-7B4DB8E8BD22@cisco.com> <4978DDA8.5080505@uclouvain.be> In-Reply-To: X-Enigmail-Version: 0.95.0 Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] The case for Map-Updates 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dino, Dino Farinacci wrote: >> SMR allows to sollicit a new map request, it does not allow an xTR to >> update the mapping on the other mapping servers that are responsible for >> the same EID. > > The point of soliciting a map-request is so you can return a map-reply > with updated information. The way it works is like this: > > o I am an ETR with a mapping change. > o I solicit at the rate I want to receive requests by setting the > SMR-bit for the active sites > I am talking to. Because those sites will need the new information > sooner than the ones not > talking to me. This implies that you have bidirectional traffic. What happens in the case of unidirectional traffic? (at leats from that ETR perspective) > o You are a site that is talking to me so I ask you to send me a > Map-Request. > o You then send me a Map-Request and I return a Map-Reply. > o I remember I sent you the updated mapping data so the loc-reach-bits > I send you reflect the > new mapping. > So the ETR has to remember the ITR talking to him that have already been updated? > That's all there is to it. > >>>> - an xTR is being shutdown or will be shutdown in some time and >>>> need to >>>> force a removal of the corresponding mapping entry >>> >>> Today, the xTR can just go away. In fact, mappings that are cached by >>> remote ITRs need to stay in tack because there are other xTRs at the >>> site which are being used. The loc-reach-bit for the xTR coming out of >>> service can be set to 0 immediately until the time an SMR is sent to >>> remove the RLOC from the mapping. >> >> The other xTRs of the site need to be informed about the shutdown of the >> local xTR. If this is a sudden shutdown, they will be informed by e.g. >> the IGP protocol, but if this is a planned shutdown, then it is useful >> to inform the other xTRs and mapping servers in advance. > > They are all configured at the same time. > >>>> - load-balanced xTR are overloaded and their weight needs to be >>>> updated >>> >>> SMRs do this too. Or you can source-quench the source by advertising >>> the >>> RLOC as unreachable for a short period of time. There are already >>> simple >>> mechanisms in place that seem to work well. >> >> SMRs allow to sollicit a new Map-request, but this Map-Request will be >> received by any of the mapping servers (e.g. xTR) that serve the site. >> These mapping servers need to be coherent and advertise the same >> EID-to-RLOC mappings. > > Right, but the xTR that is old will have loc-reach-bits relative to > the locator-set it is sending. > Does this old mapping match with the new one on the ETR? Luigi > 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 lisp-bounces@ietf.org Fri Jan 23 09:15:10 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2AB828C21D; Fri, 23 Jan 2009 09:15:10 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C8C28C21D for ; Fri, 23 Jan 2009 09:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 9oBXOU29ir55 for ; Fri, 23 Jan 2009 09:15:07 -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 A2A9128C20D for ; Fri, 23 Jan 2009 09:15:07 -0800 (PST) Received: from [130.149.220.21] (kea.net.t-labs.tu-berlin.de [130.149.220.21]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 6C0D570015D8; Fri, 23 Jan 2009 18:14:50 +0100 (CET) Message-ID: <4979FB09.4020104@net.t-labs.tu-berlin.de> Date: Fri, 23 Jan 2009 18:14:49 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Dino Farinacci References: <49730E98.1030101@uclouvain.be> <4976453C.4020306@uclouvain.be> <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> In-Reply-To: <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> X-Enigmail-Version: 0.95.0 Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Locator liveness problem 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dino Farinacci wrote: >>>> 1- What are the types of failures that we consider and want to be able >>>> to detect : >>>> >>>> a. Failure of an ETR >>>> >>>> b. Failure of (one of the link) directly attached to an ETR to its >>>> provider >>> >>> These are covered by the loc-reach-bits and have been in the LISP spec >>> for quite a long time. I think dating back to the -02 draft. >> >> There are some issues with loc-reach-bits that are part of the LISP >> spec : >> - The support for more than 31 locators is cumbersome (maybe 31 >> locoators is sufficient for most deployments, including experimental >> ones, but I don't think that it's future proof) > > That was removed in -11. > >> - They assume that there is an ordering among the ETRs such that each >> ETR knows the position of all other ETRs in the loc-reach bits. This > > That's the price of compression. And it's not that bad. See Luigi for > my reasons. I have commented on other designs about this matter. > True. But I still think that will be impossible to maintain this ordering coherent among all xTRs when scale to the size of the Internet and mapping changes happen. Luigi _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 23 09:57:08 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1480C3A6AC5; Fri, 23 Jan 2009 09:57:08 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E393A6AC5 for ; Fri, 23 Jan 2009 09:57:06 -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 XOhrqa17NHXP for ; Fri, 23 Jan 2009 09:57:00 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 021A43A68E6 for ; Fri, 23 Jan 2009 09:56:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,313,1231113600"; d="scan'208";a="34675010" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jan 2009 17:56:42 +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 n0NHugEw015897; Fri, 23 Jan 2009 12:56:42 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0NHugdc003325; Fri, 23 Jan 2009 17:56:42 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 12:56:42 -0500 Received: from [192.168.1.2] ([10.82.255.246]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 12:56:41 -0500 Message-Id: <9F11BFA9-BD8A-4198-AD1A-F0722CAB01CF@cisco.com> From: Dino Farinacci To: Luigi Iannone In-Reply-To: <4979FB09.4020104@net.t-labs.tu-berlin.de> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 23 Jan 2009 09:56:40 -0800 References: <49730E98.1030101@uclouvain.be> <4976453C.4020306@uclouvain.be> <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> <4979FB09.4020104@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Jan 2009 17:56:41.0932 (UTC) FILETIME=[F27E48C0:01C97D83] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=560; t=1232733402; x=1233597402; c=relaxed/simple; s=rtpdkim2001; 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]=20Locator=20liveness=20problem |Sender:=20 |To:=20Luigi=20Iannone=20; bh=MELTuj3V8UiCeWYiiGQBgyqvdOkEnj55wTQbS4HOWDk=; b=yJylWeKSY+fh/PYCx1jom/lChsoNK+12KZet/qEsTlxu8GzkKqVN8/7IsG H/uTLkKdb6nv/JTEGWMTwumxUjUlaPXj+wKJ9IGhxSLyLuAN5g9Mu9zxwKZu fga2sARGLh; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Locator liveness problem 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > True. But I still think that will be impossible to maintain this > ordering coherent among all xTRs when scale to the size of the > Internet > and mapping changes happen. First off, the number of xTRs at a site are going to be a small number. So they can stay in sync and get into sync over a shorter period of time. Second, an xTR at a site knows who it is talking to and knows what it sent it last, so a 32-bit value per mapping entry tells you what the loc-reach-bits setting should be for a given site you are talking to. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 23 09:59:59 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AA043A6B07; Fri, 23 Jan 2009 09:59:59 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD8D3A6AFE for ; Fri, 23 Jan 2009 09:59:57 -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 jWPWm4qSMTUv for ; Fri, 23 Jan 2009 09:59:56 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 333843A6AF6 for ; Fri, 23 Jan 2009 09:59:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,313,1231113600"; d="scan'208";a="34675382" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jan 2009 17:59:35 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0NHxZfm015168; Fri, 23 Jan 2009 12:59:35 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0NHxWTQ004487; Fri, 23 Jan 2009 17:59:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 12:59:34 -0500 Received: from [192.168.1.2] ([10.82.255.246]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 12:59:33 -0500 Message-Id: From: Dino Farinacci To: Roque Gagliano In-Reply-To: <346EBDE0-A67E-4324-A3E0-3009147FFE2A@lacnic.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 23 Jan 2009 09:59:24 -0800 References: <20090120162603.GA3374@1-4-5.net> <49778BA7.2060200@uclouvain.be> <20090121211359.GA17680@1-4-5.net> <346EBDE0-A67E-4324-A3E0-3009147FFE2A@lacnic.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Jan 2009 17:59:34.0094 (UTC) FILETIME=[591C1EE0:01C97D84] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2559; t=1232733575; x=1233597575; c=relaxed/simple; s=rtpdkim1001; 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]=20updated=20LISP=20WG=20charter |Sender:=20 |To:=20Roque=20Gagliano=20; bh=1TkaIfoshImelLXTGBJNIKu7OxJ7SDlRjbNRsIKmPtI=; b=AaSrCi5vseb6FzthDzNjZ5TdD5B827xyh9eYUnbw70IbLJwQF61zWZnfgN DSW54re+A6ZbeJgWYijoODDE7c4PFQZgJXkiqZMdE/sOEwVShHn/ni2mtAjR Nx+uVOHe7r; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] updated 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > hi, > > I wanted to re-transmit what I believe I discussed with some of you > at the Dublin meeting. Today SIDR has a signed object (called ROA) > that maps prefixes to origin ASN, what I was proposing was using the > same certificates from the RPKI generated a new kind of object (CMS > wrapped) that maps EID to a list of possible RLOCs. I can work on > some text soon. > > Roque Roque, this sounds promising. Thanks! Dino > > > > On Jan 21, 2009, at 7:13 PM, David Meyer wrote: > >> >> Olivier, >> >>>> 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. >>> >>> I don't think that we should restrict the mapping discussion to >>> ALT even >>> if ALT is the only deployed solution today. >> >> I understand your point (LISP is modular in the mapping >> system). However, I was writing milestones here, so this >> one needs to stay. >> >> So do you want to add another milestone around mapping >> systems, and if so, send some text of what you have in >> mind and we can work on that. >> >>>> Mar 2010 Submit the LISP Interworking specification to the IESG >>>> for Experimental. >>>> >>>> June 2010 Submit Recommendations for Allocation and Routing >>>> of both EIDs and RLOCs to the IESG for Experimental. >>>> >>>> June 2010 Submit Recommendations for Securing the LISP Mapping >>>> System to the IESG for Experimental. >>> >>> I think that the discussion on Securing the LISP Mapping System >>> should >>> be finished before the finalisation of any mapping proposal. This >>> discussion is likely to define a set of requirements to be met by >>> mapping systems. >> >> In general, yes. In the particular case of ALT, we will >> do whatever SIDR does. However, we do not want to gate >> progress on ALT by whatever is being done SIDR. So maybe >> we can have the ALT draft be self-contained (all this >> stuff about SIDR could go in a Security Considerations >> section in the ALT document), and whoever writing the >> Recommendations Draft can also point at that. Does that >> make sense? >> >> Dave >> >> _______________________________________________ >> 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 lisp-bounces@ietf.org Fri Jan 23 13:31:02 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF8D28C225; Fri, 23 Jan 2009 13:31:02 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19383A685F for ; Fri, 23 Jan 2009 13:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 8c9944LdduOp for ; Fri, 23 Jan 2009 13:31:02 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id E992F3A680D for ; Fri, 23 Jan 2009 13:31:01 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id ED5552684EA; Fri, 23 Jan 2009 14:30:44 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 23 Jan 2009 14:30:44 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=51327; data-bytes=0 Message-Id: From: Shane Amante To: Dino Farinacci In-Reply-To: <9F11BFA9-BD8A-4198-AD1A-F0722CAB01CF@cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 23 Jan 2009 14:30:43 -0700 References: <49730E98.1030101@uclouvain.be> <4976453C.4020306@uclouvain.be> <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> <4979FB09.4020104@net.t-labs.tu-berlin.de> <9F11BFA9-BD8A-4198-AD1A-F0722CAB01CF@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: lisp@ietf.org Subject: Re: [lisp] Locator liveness problem 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dino, On Jan 23, 2009, at 10:56 AM, Dino Farinacci wrote: >> True. But I still think that will be impossible to maintain this >> ordering coherent among all xTRs when scale to the size of the >> Internet >> and mapping changes happen. > > First off, the number of xTRs at a site are going to be a small > number. So they can stay in sync and get into sync over a shorter > period of time. > > Second, an xTR at a site knows who it is talking to and knows what > it sent it last, so a 32-bit value per mapping entry tells you what > the loc-reach-bits setting should be for a given site you are > talking to. Re: your 2nd point ... does this take into account asymmetric paths? IOW, given the following topology: cust1 | xTR-1 / \ Internet / \ xTR-2 xTR-3 | | --+---------+-- | cust2 Let's say that cust1 has selected to send traffic to cust2 through xTR-2. So, traffic flows as flows: cust1 -> xTR-1 -> xTR-2 -> cust2. However, cust2 has a medium- to large-ish network and it's IGP has selected xTR-3 for all hosts to use as its "default" route back out to the Internet due to cost, policy or other "administrative" reasons. Therefore, return traffic flows from cust2 -> xTR-3 -> xTR-1 -> cust1. If xTR-2 is not xmit'ing back toward xTR-1, in the data-path at least, how does xTR-3 know what to set loc-reach-bits to (what protocols/processes/methods are used) and how fast will that occur? Anyway, just trying to understand if and/or how this applies given asymmetric paths are a common occurrence and I don't see that diminishing in an ID/LOC split world. -shane > 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 lisp-bounces@ietf.org Fri Jan 23 13:48:29 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6763A6B3B; Fri, 23 Jan 2009 13:48:29 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9103A6B3A for ; Fri, 23 Jan 2009 13:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 moHUSqw8ctIX for ; Fri, 23 Jan 2009 13:48:22 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BE0203A6B11 for ; Fri, 23 Jan 2009 13:48:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,314,1231113600"; d="scan'208";a="235628256" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 23 Jan 2009 21:48:06 +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 n0NLm6I1030671; Fri, 23 Jan 2009 13:48:06 -0800 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 n0NLm57x025015; Fri, 23 Jan 2009 21:48:06 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); Fri, 23 Jan 2009 13:48:05 -0800 Received: from [10.0.1.4] ([10.21.90.76]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 13:47:08 -0800 In-Reply-To: References: <49730E98.1030101@uclouvain.be> <4976453C.4020306@uclouvain.be> <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> <4979FB09.4020104@net.t-labs.tu-berlin.de> <9F11BFA9-BD8A-4198-AD1A-F0722CAB01CF@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <9264BA21-5F29-4B1D-BDED-74520D4DA60C@cisco.com> From: John Zwiebel Date: Fri, 23 Jan 2009 11:47:10 -1000 To: Shane Amante X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 23 Jan 2009 21:47:08.0624 (UTC) FILETIME=[23D80D00:01C97DA4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3056; t=1232747286; x=1233611286; c=relaxed/simple; s=sjdkim4002; 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]=20Locator=20liveness=20problem |Sender:=20; bh=QEEM+skAcGQAT43SI2RYwru5xcG6Cm4MheszG74RQu0=; b=bNmKGeFw9cP2PazzU9Hmz4elJNL+Xj5O1wVdLeDlQ6F5UZs3NMPG74SPCg 6blPGWMrugBBUZkcyDQJ8Q5Os8BH8b2luh6Zwc9YxnS/zHG9Hf1LQlC9ikvD n9ZjKDsaii; Authentication-Results: sj-dkim-4; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Locator liveness problem 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Shane FWIW: I have this running on a small topology. In our current implementation xTR2 and xTR3 will have the same ETR database: ETR Database: EID-prefix: 20.0.0.0/8 Locator: 100.1.45.4, priority: 10, weight: 1, state: down Locator: 100.1.235.2, priority: 10, weight: 1, state: up, local Locator: 2001::0100:0001:0045:0004, priority: 10, weight: 1, state: down Locator: 2001::0100:0001:0235:0002, priority: 10, weight: 1, state: up, local This information is communicated via the IGP across the EID-site. (running ospf) There is that period of time between the RLOC going down (in this case 100.1.45.4) and the other xTR getting the information which means a packet from cust1 could be replied to so that xTR3 sends the wrong loc-bits. But that is a very brief period. Hope this helps. On Jan 23, 2009, at 11:30 AM, Shane Amante wrote: > Dino, > > On Jan 23, 2009, at 10:56 AM, Dino Farinacci wrote: >>> True. But I still think that will be impossible to maintain this >>> ordering coherent among all xTRs when scale to the size of the >>> Internet >>> and mapping changes happen. >> >> First off, the number of xTRs at a site are going to be a small >> number. So they can stay in sync and get into sync over a shorter >> period of time. >> >> Second, an xTR at a site knows who it is talking to and knows what >> it sent it last, so a 32-bit value per mapping entry tells you >> what the loc-reach-bits setting should be for a given site you are >> talking to. > > Re: your 2nd point ... does this take into account asymmetric > paths? IOW, given the following topology: > > cust1 > | > xTR-1 > / \ > Internet > / \ > xTR-2 xTR-3 > | | > --+---------+-- > | > cust2 > > > Let's say that cust1 has selected to send traffic to cust2 through > xTR-2. So, traffic flows as flows: cust1 -> xTR-1 -> xTR-2 -> > cust2. However, cust2 has a medium- to large-ish network and it's > IGP has selected xTR-3 for all hosts to use as its "default" route > back out to the Internet due to cost, policy or other > "administrative" reasons. Therefore, return traffic flows from > cust2 -> xTR-3 -> xTR-1 -> cust1. If xTR-2 is not xmit'ing back > toward xTR-1, in the data-path at least, how does xTR-3 know what > to set loc-reach-bits to (what protocols/processes/methods are > used) and how fast will that occur? > > Anyway, just trying to understand if and/or how this applies given > asymmetric paths are a common occurrence and I don't see that > diminishing in an ID/LOC split world. > > -shane > > > >> 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 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sat Jan 24 07:43:47 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9AE3A6B4A; Sat, 24 Jan 2009 07:43:47 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F27228C0FE for ; Sat, 24 Jan 2009 07:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=-0.211, 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 jk920gP+KZnx for ; Sat, 24 Jan 2009 07:43:45 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3A74D3A6AD3 for ; Sat, 24 Jan 2009 07:43:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,318,1231113600"; d="scan'208";a="235992426" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2009 15:43:26 +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 n0OFhQcN032649; Sat, 24 Jan 2009 07:43:26 -0800 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 n0OFhQud027793; Sat, 24 Jan 2009 15:43:26 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); Sat, 24 Jan 2009 07:43:26 -0800 Received: from [10.224.17.251] ([10.21.148.157]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jan 2009 07:43:25 -0800 Message-Id: <54F6C058-FF58-4CA6-BF96-37DC00019701@cisco.com> From: Dino Farinacci To: Shane Amante In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 24 Jan 2009 07:43:22 -0800 References: <49730E98.1030101@uclouvain.be> <4976453C.4020306@uclouvain.be> <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> <4979FB09.4020104@net.t-labs.tu-berlin.de> <9F11BFA9-BD8A-4198-AD1A-F0722CAB01CF@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Jan 2009 15:43:25.0649 (UTC) FILETIME=[7EC01410:01C97E3A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2636; t=1232811806; x=1233675806; 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]=20Locator=20liveness=20problem |Sender:=20; bh=krp29viWMPGc9grvumlhu5+SDGClEIyXEMXhC1OgyXQ=; b=IrVH7Vm2nkzd6oKO73ziU6FvrzZtzXWIT+sQ4K8A6XfXGGI14WlovsRWrs Tl7w2t+fs/uzvWwo96HiCd9Ozw22EXB1xMlFAt7PXlN0L7geNHLcdnGLzq3O bGeIYd2nax; 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] Locator liveness problem 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > On Jan 23, 2009, at 10:56 AM, Dino Farinacci wrote: >>> True. But I still think that will be impossible to maintain this >>> ordering coherent among all xTRs when scale to the size of the >>> Internet >>> and mapping changes happen. >> >> First off, the number of xTRs at a site are going to be a small >> number. So they can stay in sync and get into sync over a shorter >> period of time. >> >> Second, an xTR at a site knows who it is talking to and knows what >> it sent it last, so a 32-bit value per mapping entry tells you what >> the loc-reach-bits setting should be for a given site you are >> talking to. > > Re: your 2nd point ... does this take into account asymmetric > paths? IOW, given the following topology: > > cust1 > | > xTR-1 > / \ > Internet > / \ > xTR-2 xTR-3 > | | > --+---------+-- > | > cust2 > > > Let's say that cust1 has selected to send traffic to cust2 through > xTR-2. So, traffic flows as flows: cust1 -> xTR-1 -> xTR-2 -> > cust2. However, cust2 has a medium- to large-ish network and it's > IGP has selected xTR-3 for all hosts to use as its "default" route > back out to the Internet due to cost, policy or other > "administrative" reasons. Therefore, return traffic flows from > cust2 -> xTR-3 -> xTR-1 -> cust1. If xTR-2 is not xmit'ing back > toward xTR-1, in the data-path at least, how does xTR-3 know what to > set loc-reach-bits to (what protocols/processes/methods are used) > and how fast will that occur? As JohnZ said, xTR-3 knows by running an IGP with xTR-2 that either 1) it has gone down, 2) it's CE/PE link as gone down, or 3) the PE router has gone down. All these cases cause either a default route to be withdrawn from the IGP or an external route that xTR-3 can track. When this occurs, xTR-3, when it encapsulates packets, will clear the loc- reach-bit associated with xTR-2. So even when there are asymmetric paths, as long as one xTR at a destination site is returning traffic to ta source site, the xTR will always provide liveness (specifically local liveness) of all xTRs at it's site. > Anyway, just trying to understand if and/or how this applies given > asymmetric paths are a common occurrence and I don't see that > diminishing in an ID/LOC split world. Hope this helps. Thanks, Dino > > > -shane > > > >> 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 lisp-bounces@ietf.org Sat Jan 24 11:51:24 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0F728C110; Sat, 24 Jan 2009 11:51:24 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C38428C0CF; Sat, 24 Jan 2009 11:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 3YmpH0+EE2+5; Sat, 24 Jan 2009 11:51:21 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 48F573A68F6; Sat, 24 Jan 2009 11:51:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,318,1231113600"; d="scan'208";a="236067327" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2009 19:51:04 +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 n0OJp4J3005488; Sat, 24 Jan 2009 11:51:04 -0800 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 n0OJp45A018355; Sat, 24 Jan 2009 19:51:04 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); Sat, 24 Jan 2009 11:51:04 -0800 Received: from [10.224.151.60] ([10.21.121.232]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jan 2009 11:51:03 -0800 Message-Id: <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> From: Dino Farinacci To: Robin Whittle In-Reply-To: <497B1F7A.9030407@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 24 Jan 2009 10:26:11 -0800 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Jan 2009 19:51:03.0945 (UTC) FILETIME=[16FC1F90:01C97E5D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11412; t=1232826664; x=1233690664; 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[Int-area]=20Please=20respond=3 A=20Questions=20from=20the=20IESG=20as=20to=20whether=20a=20 WG=20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=hBuGcYUVI8LVCGe45Tue55NR90KPSeHbbUAyOsoE0zQ=; b=rBt8KrUCNkDS3K9ue8VX4Zu8tRu4noMs1PnN4uya0969TQQXMKZF/7GQsq Kt8wPzrt4s9dxJHkhPoGgo5Ok4SFz0xdf7lonycAf9hdJXOxul3rdPZuXbKN VGdmxCJGoA; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rrg RG , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > LISP has too many fundamental problems to be considered a > potentially practical solution. Some of these problems require LISP is not perfect and still evolving but let me point out that every design has fundamental problems. At this scale, it's very hard to be perfect Robin. And as Noel has stated so many times, the hard decisions must be made to incrementally deploy this. So things might not look pretty on the surface, but jeez, you got to do what you got to do. Else, this will all be academic. We really want to solve this problem, sincerely. This is not lip service, we are not just writing papers, we want to rev the Internet, this is serious. I want to address each of your 7 points below. I have cc'ed the lisp@ietf.org mailing list so the folks who want to focus on details of LISP can see this thread. > 1 - Delays in delivering initial packets in a flow. This is either > due to sending the packets along the ALT network (which takes > time and involves sending substantial volumes of data packets > over the ALT network, rather than just mapping requests) or to > sending mapping requests only, and waiting for the ITR to get a > response before it attempts to send traffic packets. We have a memory/bandwidth tradeoff. So we have to make a hard design call. I'd rather have mappings cached and timed out so they can be updated when they need to then to hold all the possible mappings for the Internet in an ITR. There is no such thing of a free lunch. You either store all possible mappings or you fetch them when you need them. > According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10 > & 11 the experimental LISP ALT network's ITRs drop initial > packets and send brief map request messages. Even if we think > this delay doesn't matter, I am sure enough potential adopters > would - and therefore make it difficult or impossible for LISP or > any other such solution to be widely enough adopted to solve the > routing scaling problem. Then why was/is ARP deployed in a 10^4 host-based bridged network with basically the same properties. First packet loss is not persistent when you look at all the traffic that originates from a source site to another destination site. The host vendors are probably thinking, if we do LISP in the host, you could wait to send your TCP SYN before the mapping is available. Guess what, you don't send that TCP SYN before you get the DNS Reply. ;-) I wonder why? Well I'll spell it out. If a host needs an address to make the connection, we can say it also needs a locator to make a connection. The design choice of LISP *is to just change software in CPE devices* to get the feature of decoupling rather than changing all the hosts at a site. That's a huge deployment advantage. So these CPE devices get packets before they have mappings. We don't even want to consider a host to CPE router signaling protocol and all it's complexities to solve this and to keep the architecture pure, we don't want to snoop on DNS, SIP, or any other protocol that can give us a hint on where the host is about to send a packet. So the cost is *either* first packet loss or sending the packet on the ALT using it as a request for a mapping. > 2 - LISP-ALT's long-path problem > http://psg.com/lists/rrg/2008/msg01676.html > http://www.antd.nist.gov/~ksriram/strong_aggregation.png > > [Fix? Another fundamental problem in the architecture. Could > be partially solved by more meshiness, but that would greatly > increase the complexity of the network and so raise more > scaling problems.] Well this I believe is a duplicate of 1 above. So it's not really *another* problem. > 3 - Problems creating a highly aggregated ALT network in order to > speed the flow of packets up and down the hierarchy, while also > making the network robust against the failure of its routers and > tunnels. This has not been discussed much on the RRG, but it is > an obvious problem. If we can do this with BGP, which we have decades of existence proof why can't we do this with a tunnel topology 1) where a tunnel can be rehomed much quicker and easily than physical links and boxes we have to do with today, allowing aggregation to occur at the edges of the ALT network, and 2) these tunnels stay up because there is robust connectivity below the tunnel level to keep them up, hence there will be less route-flaps for EID-prefixes. I think it's the complete opposite of what you claim. I think BGP will be more stable and scalable then the underlying BGP. Plus, what we propose for the use-case of BGP uses quite a few features of it. Recall this is eBGP over GRE. We have an infrastructure where we can 1) ping to see liveness of nodes on the ALT. We have traceroute to determine the path a Map- Request takes on the ALT. We can ping/traceroute "underneath" so we can see the diameter of the tunnel. Not only do we have a solution but we use existing rudimentary tools for management. And the address allocation hierarchy can map this logical ALT topology. And if the Registries are involved in managing part of this ALT network (which we hope and think they will), we can keep this consistent relationship. Do you realize the goodness of this? It's huge Robin. There's more too, you then throw SIDR in the mix and we have secured the ALT, we have secured mappings, we created a PKI for routing use. In fact, the first SIDR deployment could happen on the ALT to be verified/experimented before it goes on the underlying BGP. And note, that the infrastructure will/does carry exactly 2 address- families. So we can do 6-to-6-over-4 with this approach. That means we can get two site to be *IPv6-only* and be able to talk to each other. If you are a IPv6-only site now or a dual-stack site, you could talk to the new IPv6 Google services. I think this is a pretty huge feature. This is clean and architecturally pure, no double NATs, no CGNS, and no applications breaking. > 4 - LISP-ALT's Aggregation implies provider dependence. > This is Christian Vogt's critique: > http://psg.com/lists/rrg/2008/msg00259.html Not true. Aggregation here is for the EID-prefix. Service providers do not carry EID-prefixes in their cores so you don't depend on them. The decoupling of the address creates this. The dependence is now on the ALT. And if your site resides in a specific region of the world, you get your EID-prefixes from that registry. So readdressing your domain would only occur if you moved it from one region to another (let's leave mobile ASes out of this for now). > 5 - Path MTU Discovery problems. Despite Fred Templin, myself and > others discussing the inherent PMTUD problems in any map-encap > proposal, there has been nothing from the LISP team to indicate > they have a solution. They seem to think there is no problem. In section 5.4 of draft-farinacci-lisp-11.txt we describe two proposed solutions, one is stateless, and the other is stateful. The stateful creates no new table data structures but requires storing an addition 2-bytes of effective-MTU state per mapping. > 6 - Lack of business case for LISP's Proxy Tunnel Routers: > http://psg.com/lists/rrg/2008/msg02021.html You cannot fault a technical design for a business case. A PTR is solving a technical problem. And if we want to *truly* keep lots of PI type routes out of the core *and* avoid NAT solutions which are just way too high in opex, the PTR is the only solution we have to turn to. And on the contrary, I do believe service providers, interconnect providers, registries, third-parties and even governments will provide PTR services. Will they make a ton of money out of it, well that remains to be seen. > 7 - The scaling problems of potentially thousands of ITRs each > probing reachability to one ETR, and likewise, one ITR probing > reachability to many ETRs - this is one view of the "Locator Path > Liveness Problem" of draft-meyer-loc-id-implications-00. > http://www.irtf.org/pipermail/rrg/2009-January/000809.html That is not in the LISP design. Everyone just thinks it is. ;-) Dave and Darrel's draft is providing a warning about how bad probing can be. They do not take a position whether it should go into any proposal. They are just saying, beware of the Frankenstein that may result and can be an interpretation to not do probing at all. Like I mentioned in a previous RRG email message, one has to ask the question if an ITR *should* switch from one RLOC to another when there *may* be a path failure *somewhere in the middle of the network*. Please note my very fine qualifications. If we want to solve this problem, we could do this today by having a host switch it's TCP connection to another A record. This doesn't happen today because people deal with packet loss, since it doesn't last long *and* rerouting actually works quite well. Van Jacobson always made this comment and I'll never forget it, "The fact that the Internet drops packets is it's greatest feature". What else can either an xTR or TCP host do when sending ICMP Unreachables are off by default in most modern routers, or they are filtered by firewalls, and route aggregation hides failures close to packet sources. >> Unless these concerns are adequately addressed, claiming that LISP >> is an appropriate solution to the problems discussed at the IAB's >> October 2006 Routing and Addressing Workshop is nothing more than >> a proof by an emphatic assertion. > > I agree entirely. > > I believe the LISP team could have made much better use of the RRG - > by participating fully in the debates resulting from these critiques. We were asked to do research in RRG. That was a reasonable request. So the research stuff in LISP has been and will continue to be presented in RRG. As for the engineering issues, the real details and bits and bytes, we want a forum to discuss and work out issues in an open forum. I've been going to IETF for 20 years now, that forum is called a working group. The working group doesn't have to standardize what it is working on. And the charter and the numerous requests we have made requests *for an experimental working group*. > Experiments won't help solve most of these problems. I am not > against experimentation and I think it is great that there is a LISP > experimental network. > > However, I would never have taken a proposal to the point of writing > code, running a network and inviting others to write compatible > implementations when the proposal had so many fundamental problems. There is constant implementation feedback back into the design. Experienced engineers know how this cycle works. You start with something you think can hold together, you try things out, you refine, you revisit design, you go forward with implementation. That's the process of *detailed* engineering. For the old timers, that was the difference between TCP/IP and OSI. Sorry for the long email, Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sat Jan 24 11:51:24 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CC228C126; Sat, 24 Jan 2009 11:51:24 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D2A28C0CF for ; Sat, 24 Jan 2009 11:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 EoZOq7Q9ah6i for ; Sat, 24 Jan 2009 11:51:23 -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 06B0428B797 for ; Sat, 24 Jan 2009 11:51:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,318,1231113600"; d="scan'208";a="133174257" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Jan 2009 19:51:04 +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 n0OJp3n6025301; Sat, 24 Jan 2009 11:51:03 -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 n0OJp3IA020170; Sat, 24 Jan 2009 19:51:03 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); Sat, 24 Jan 2009 11:51:03 -0800 Received: from [10.224.151.60] ([10.21.121.232]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jan 2009 11:51:02 -0800 Message-Id: <7E1EA1E9-C52B-4B62-95A3-C45D2AEA2D79@cisco.com> From: Dino Farinacci To: Luigi Iannone In-Reply-To: <4979F9DB.9030601@net.t-labs.tu-berlin.de> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 24 Jan 2009 09:28:00 -0800 References: <49778EE1.8050407@uclouvain.be> <45A96B82-9301-4935-A251-7B4DB8E8BD22@cisco.com> <4978DDA8.5080505@uclouvain.be> <4979F9DB.9030601@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Jan 2009 19:51:02.0867 (UTC) FILETIME=[1657A230:01C97E5D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4372; t=1232826663; x=1233690663; c=relaxed/simple; s=sjdkim4002; 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]=20The=20case=20for=20Map-Updates |Sender:=20; bh=t8WAUCgg1Onqn2PKrO4M1xTbC00fXe3GAPYwyjD4ooY=; b=asF3uD7K2/qmwAXYPJ8WPn9RoW28eoyO+jsBvb+uTVbrp6hvTbWEHUVPmA Zm/LQCk7+e/+94QOuLyR4YyCFOIyMgPmjWIvxwup/auFiXzhMzSNr7Rhz7aI l3E3LCnay/; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] The case for Map-Updates 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > Dino, > > Dino Farinacci wrote: >>> SMR allows to sollicit a new map request, it does not allow an xTR >>> to >>> update the mapping on the other mapping servers that are >>> responsible for >>> the same EID. >> >> The point of soliciting a map-request is so you can return a map- >> reply >> with updated information. The way it works is like this: >> >> o I am an ETR with a mapping change. >> o I solicit at the rate I want to receive requests by setting the >> SMR-bit for the active sites >> I am talking to. Because those sites will need the new information >> sooner than the ones not >> talking to me. > This implies that you have bidirectional traffic. What happens in the > case of unidirectional traffic? (at leats from that ETR perspective) Well the SMR-bit is in both a data packet and a Map-Request. So if there is unidirectional traffic from a site that needs to be updated, the site that has the mapping change sends a Map-Request to one or more of the remote xTRs. >> o You are a site that is talking to me so I ask you to send me a >> Map-Request. >> o You then send me a Map-Request and I return a Map-Reply. >> o I remember I sent you the updated mapping data so the loc-reach- >> bits >> I send you reflect the >> new mapping. >> > So the ETR has to remember the ITR talking to him that have already > been > updated? Right. But look at the failure cases, and let's see how bad it is. If you mis-set the loc-reach-bits you are basically saying that some xTRs, which are up, you are erroneously reporting them as down. That, in and of itself is not that bad, because the ITRs at the remote sites can just choose another RLOC in the locator-set. This would only occur for a short period of time (i.e. the rate-limit time and propagation delay). And in the case where the xTR is reporting an RLOC up when in fact it is down suffers packet loss for that short period of time. Remember, an ITR can switch to another RLOC in the locator-set anytime, as long as it's within the set of high-priority RLOCs so it can adhere to the policy of the destination site. An ITR can switch when it sees no packets from an alleged down RLOC. I realize that in unidirectional traffic this might not be the case. But there are few cases where a site has absolutely no return traffic of any kind from any host at the site. >> That's all there is to it. >> >>>>> - an xTR is being shutdown or will be shutdown in some time and >>>>> need to >>>>> force a removal of the corresponding mapping entry >>>> >>>> Today, the xTR can just go away. In fact, mappings that are >>>> cached by >>>> remote ITRs need to stay in tack because there are other xTRs at >>>> the >>>> site which are being used. The loc-reach-bit for the xTR coming >>>> out of >>>> service can be set to 0 immediately until the time an SMR is sent >>>> to >>>> remove the RLOC from the mapping. >>> >>> The other xTRs of the site need to be informed about the shutdown >>> of the >>> local xTR. If this is a sudden shutdown, they will be informed by >>> e.g. >>> the IGP protocol, but if this is a planned shutdown, then it is >>> useful >>> to inform the other xTRs and mapping servers in advance. >> >> They are all configured at the same time. >> >>>>> - load-balanced xTR are overloaded and their weight needs to be >>>>> updated >>>> >>>> SMRs do this too. Or you can source-quench the source by >>>> advertising >>>> the >>>> RLOC as unreachable for a short period of time. There are already >>>> simple >>>> mechanisms in place that seem to work well. >>> >>> SMRs allow to sollicit a new Map-request, but this Map-Request >>> will be >>> received by any of the mapping servers (e.g. xTR) that serve the >>> site. >>> These mapping servers need to be coherent and advertise the same >>> EID-to-RLOC mappings. >> >> Right, but the xTR that is old will have loc-reach-bits relative to >> the locator-set it is sending. >> > Does this old mapping match with the new one on the ETR? Umm, I don't quite understand the references. Can you restate? Dino > > > Luigi > >> 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 lisp-bounces@ietf.org Sun Jan 25 10:02:38 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7206F28C0E3; Sun, 25 Jan 2009 10:02:38 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0EE528C164; Sun, 25 Jan 2009 10:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.319 X-Spam-Level: X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, DC_IMAGE_SPAM_HTML=0.001, DC_IMAGE_SPAM_TEXT=0.001, DC_PNG_UNO_LARGO=0.558, 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 D0oUmKLTEiwA; Sun, 25 Jan 2009 10:02:37 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C897F3A6A49; Sun, 25 Jan 2009 10:02:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,322,1231113600"; d="png'150?scan'150,208,150";a="34829119" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Jan 2009 18:02:00 +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 n0PI200t017598; Sun, 25 Jan 2009 13:02:00 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0PI20Rt016777; Sun, 25 Jan 2009 18:02:00 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 13:02:00 -0500 Received: from dino-macbook.dhcp.nanog.merit.net ([10.82.244.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 13:01:59 -0500 Message-Id: From: Dino Farinacci To: HeinerHummel@aol.com In-Reply-To: Content-Type: multipart/mixed; boundary=Apple-Mail-18--951548461 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 25 Jan 2009 09:56:45 -0800 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 25 Jan 2009 18:01:59.0919 (UTC) FILETIME=[04DABFF0:01C97F17] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=88046; t=1232906520; x=1233770520; c=relaxed/simple; s=rtpdkim2001; 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[Int-area]=20Please=20respond=3 A=20Questions=20from=20the=20IESG=20as=20to=20whether=20a=20 ... |Sender:=20 |To:=20HeinerHummel@aol.com; bh=EY9if89uBex2McRXOcWe0778CxA0ci7uFn4cvM043Rc=; b=iXj+XoSik5UD/K5resr5rQMYUp1nSiZf95+mdsRe6IyisdUjGqLKyRiEvP 58YDHK5i/qBc6e3spo6wRPBZvW2/48LYZdtOvHe0TScXKP6tLajhF3Od9HYQ WM6+wRZ1Dc; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: rrg@irtf.org, int-area@ietf.org, routing-discussion@ietf.org, lisp@ietf.org Subject: Re: [lisp] [rrg] [Int-area] Please respond: Questions from the IESG as to whether a ... 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: , Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --Apple-Mail-18--951548461 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > Just a simple question: Is the ALT GRE-tunnel hierarchy a tree ? It is not required, but it should follow the address allocation delegation. What we have deployed on the pilot is in the enclosed diagram and the EID-prefix assignments follow a registry allocation hierarchy. This topology supports both IPv4 and IPv6. Once the apnic box is up, the container with ntt, dscott, and iij will connect to it. Dino --Apple-Mail-18--951548461 Content-Disposition: inline; filename="Picture 1.png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; x-mac-type=504E4766; name="Picture 1.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgCAIAAAC6s0uzAAAABGdBTUEAANkDQtZPoQAADzdpQ0NQ Q29sb3IgTENEAAB4nJWXCThU3/vAz3Dt+zZ2xpJ9GYw969j37CSMGctYxjT2JUuhREkLKiJ9SQtS EkpChUpRRFnKmgqJLCn53aG+3//z+z2/5/f8z/PcuZ/7nve877nnPXPf8wLAJYIjk8NpAAARpGiK s6UpytPLG8XwBiAABPiAGBDB4aPIJk5OduC/ttXXsDbcXilTbdVanTila3yRCfLJN1fSOjH538dt N3YK7BAAhBLMvME7bEzlgB12pXJcNDka5hAq40NwBJiTYVaiuDpjYa6i2gne4UYqB+xwF5Vj8cHU sUMA0HOTCEQSAAxzMBsSAqPwcDfVL4EQhY+A+QQANIYREZGwfc5eWC6HJ1PgsZzrMEtT12VnyoQ1 APQg2Mbbf2ShEgBU3wZAROIfmex9AARwANxQ+Ee27Ly9Vgjki6ggDfVtEYLVFAC6sa2tZRl4bicB 2Mzf2vpRvrW1eQkA2hEAHoTjYyixv9cLgegB4H8977zz70YLO4QDTKNK6wCF0B2gP8twg7GdaYj5 M8sSGzM7P4cEpzKXHrcJjx2vK58H0pcfL0AUJAtFCUeLxIjGiyWJp6EyJDIkD0sdlT6+64zMedky uSr5WoVGxU6lAeVxlVU0s5qkuoaGGyZJs0zrifa6rrweTv/87lFDcSOi8R1TVuw+s1sW3JYUqz4b Vdtjdl8d7Bxr9nA4h7s8cRN2D/e478Xu7be3yuebL9bvqH9PAAfekXAy8EUwc4gJMSa0Jmw8godk FhlHvr7/bRQUjY7xi82Nuxc/m8iVZJhMPlCa0pk6kjaRPn1w7tBixlLmatbmESib9ShXDl+u6DG5 4xp5+idM8q1O7jnlftr7jG8BvpBYFHY27BzxPLE4tCTkAq7Uu8zlom258SW1v+QrZCt3XZasQl0R vSp4je86VzVnDWstXe2vG+t1yzfnb03XD9/ua3h2p6Oxqamu+frdK/cuthTcP9569EFGW3p7Ygfl IekR6XF4J64L243snnhy82nqM5se/p6Z5/UvMnqd+8T75l8+eJXf7zegPLDx+ulg4RDujfKb728f D+eNuI+Kjk6NVb+jvNd6/328eSJpUm9ydaphOnnG5APth+7Z3I8Onzg/vfpcOOc5LzA/tFD0xXNR YHHga/6SwzLbcve3jBWTla3V+2uJ65rri9+rN8J+yP+Y+Vm+6f9L/Nfbrf1bW3D8IVpuCEnHS8/H wMHIwsTItMn8neUL6xTbG/YejjbOOq5y7tM8mbxxfGHIffyOAlhBXSEtYSURVVEVMS1xQ5S5hJGk jpSytNIuJRkFWbSckjxaQUsRq2Sj7KlCVE1AZ6uVqDdovMAsaHFpY3RcdBP1LusPGjAaahrtN642 mcUqmoWZ11qsW5lb59gM2anZJzv0OQnvCXZucEW42buf9Bjxkvcm773ps+ar43fAvxW3idcnxAbe CVoOUSGGhl4N+xQhQ/KJLCK/pvBEuUbnxzyJY4y3Szie+ChpMvnzgS8pK6nf0zbSfx2iy2DN5MkS PCx6RDobfVQvxzTX+pjjcc88nxP++YSToaciT5PPUAoiC0lF5LMR54LO+xd7ljhdMC/VKlO+qFyu dEke3gdylTKXpaukrkhflbomfl2kWqhGsFbgBl8d902OWxz17LfZGtjucDUimwSaBe4K30O1yN5X adV8oNtm2u7Q4f1w7yPLx6jHS53dXcXdEU9MnvI/nX/2qOfs84gX2F7R3tW+npflr+L6HQYkB1Ze dw8WD0W+MXnL9XZ0+PpI8qjVGNfY8Lvy96HjKuOLE42TJ6ZCpo1m+GfmPzycPfuR9Mn8s+DnT3P3 5o8t7Pui8uXHYufXk0u+y/LLS9/urmStOq0JrI2sl38nbqA31n/c+5m2af6L/deLrYid+NOs0S5C 3+i+0M8zzDPOM40xD7P0sz5la2Gv4SjlzOGK4ybA3wA0HwffMrKP/5pAhqCPEFqYTnhQpEI0Rsxc nEN8FFUhESGpJ0Uv9Vr6yq4UGTdZJTlGuQ/ynQpViseUopX3qpiqqqBF1JjU1tSnNfowDzRvaJVo Z+vE6uL07PR370YZ0BssGg4Y3TY+ZRJrSsR6mFmY61jIWApY0VmtWn+0eWPbZddgX+lQ5JjtFA/v DXcXO1d9NyV3cQ+kJ5sXjdc37497J3ze7uv37fHr8L+Pawloxt8kXArMDqIE+4VYEVVDhcIYwlbC pyL6SPcja8jl+wsoR6Lio0NifGMd4gzjVRMkEnmToKTl5PcHnqfcT72Wdjo99WDQIccMTCYyC5G1 dnj+yGT226O9OZ25zcdqj1flFZ/IyU89ST5FOO12xqIAUyhdxHeW7uy3c9Pnh4p7Su5fuF5aUnbq YmZ58qXIv3AVHpV7LltX6V+RvAqujly7d72omlLjWKtyg/3GQl3PzSu3cuojb7s0aN5B3llrHGlq aS65m3IP14K9v6uVrnXyQUdbZXtGB+6hwSOhR6uPezsrunK6i5+0PZ14tvVc6IVur3df8sviV139 869FBh2Hct48G+YZ8R9tesfzPnX822T6NPvM5VmnT1yfX8/XfCn4mr9cslK3NrOB+un/K4Ua/53c R230WgAUxQDgOQ6AcwUAeZtwqmMFAAnnUSc2AFx1AaI9DyCuZQKEad6f/AGov4yACz4TKAMj4ArC QRa4BB6CaQQzQh3hgziCaER8pBGlcaM5TvOElpHWijaHtg8SgghQHbRF50h3ie47vRP9VQaIAcfw gFGC8RDjLJM9Ux2zEHMG8xyLB0s7qzprCRsDWwzbBLsjewuHIkcRJwNnFOc4lxNXC7cidxEPHU8M zzSvC28bH5qvDMmNzER+5w/nfy/gJfBC0FLwgdBuoQZhLeFmEUORdlEr0V4xT7FpcYr4FipXQkzi lqS15LhUkjSvdN0up11LMoWyhrKTcrnyuvIzCmcUzRSXlSqVfVUEVHpVs9HmakCtRT1VwxRDi2nX zNSy0xbTodFZ0B3Ua9e/tbvC4LRhplGccagJ3nQf1sXMytzUwsjS2MrY2tjG0tbJzts+0IHseMip cE+dc7fLuBvCXdbD3jPOq9x70Idjn54v3u+0fztuGS9L8A0sDOoJoSdahmaH9URwktwjy8hfKCZR OdHvYjFx2fEjicpJh5NnU8xSS9J+HHQ/1JQpnpVy+G220dHbuT7HRfIG8s+eCjgjVfCpqOZcSrH9 BZ7S8YsNl/IrCJetrqhc473+o2bhxoebU/VjDbONK3dZW6RaHdoiO1IflXU2d489Y3iO7vV8eaK/ a5D+DXY4Z3TkvcxE8tTAB4WPBz5PLtgsXllmWYlam9qw+HmPun+oJwnADJ8JpYEWsAOBIB1cBB3g I4IbYYiIQJQiBmjYaKxosmge0zLROtIW0o5DilAi1EknQBdC10zPTk+k72SQZ8hm+MzoxFjPJMZ0 mOkrszdzF4smSzkrN+sh1lW2YLa3cOTbODQ5rnJKcZ7j4uQ6zPWLO5Z7iYfIM867l/c1nwPfE6QF so3fgL9RQFvgjqCGYI2QmlCtsJpwIxz1DlFb0QExP7EF8WQUE6pIQkHigaSb5JxUlrSYdNMu912r cNT1ZYfl0uRl5V8oxCuiFLuUopQllPtVMlQ1VKfQhWpWaptwFiNhpDFDmie07LWR2qs6E7pP9Rr0 L+8+Z5BtmGgUbuxn4mG6B2tlZmCubYGxxFhpWWvaGNha2DnZezsEOSY45e6pdG51GXRdcxf1MPWM 8CryfuZDtw/t6+F32L8eN4HnJVgFpgTVBc8QpUJxYaXhYySRSD9yxf6FKPXohJiHcezx7gnFidPJ WgeyUl6miaeHH2zKYMvEZdUc3si2P3oTzmebeVX5vqcETz8rOFSkfXblfEMJqVSubLb8xl9xlcZV PFc+XLtXfaY2ti7glu1trTtqTSp3MS0GrZ5thA6TR2qdQt2sTzafrT9f6P348lv/z0GWN0LDmFGP d0nj5ZOvZqBZzKewufqFta8Gy+krL9flNyg/+/+OPwvgBzJAFziCEJABKkAnmEcgEVhEFKISMUbD D//3C2nGaGVoo2kfQyJQHDRAp0NXRs9MnwTnnBCGCUZ/xjGmfXDmCWCeZiGyLLLGsW6xZbMj2cs5 VDlaOfdwTnMd4OblruGx55nnzefT5htB5vLv5p8T+EswQEhaaED4uIiVKEL0gViKuCkKQnVKnJDc KyUntSLdsatAJkwWK4eU+yr/TOGyYrqSj7KhiqQqreo0ulutWr1QIx0TpOmgtVtbTUdb10DPWN96 t4cBzjDMKNb4kMkZ08vYW2bt5gMWn60gawEbTVtXuyj7kw71jsN76J0xLn6ueW7dHghPE69U704f vn12vil+jf4LAfJ4AqEycDZYJiSc2BwGhbtGXCR9I9vur6RsRXvFNMUJxsclvEzCJJem0KeGpPUe xBwqzWTPij08nG15tC3X/dhaXn6+xsnR06kFkoWPzoadFy5uu4AvY7nYdCm0greyqyrtqta1ueqK WkKd/M2F+uqGhEbbZrG7Sy3PW++0JbTPPnR4dK8T3XX1idjTUz30zxNeLPd5vXzerzNQOgiGvN7c GIZG3EYvjI29lx73mTg2eXdqaHrlA++s4kfjTw6fnecc5+0XbL4YLap/RS0xL31Z7vtWs5K7Slwz XedcH/t+fSPxh/VP/p+jmyW/Oqjx36mXthszNjI8koKyw5r9j+Lu/9siwmP++OCGL1ZSgIPjb54l RztRa0EkfG1ExbqYw3dOuNzhDCJaWP9mFAFnZguzCMzoxBCsA9UGzHZBFAvnHTsIz1CcjRPM7DCH BpLcXH7L48nh2zUulY+So02p+gIwFwdGmf/RqU8McfX4PfYxJcbZDWZpmPvDIm2df/taJwSa/Z4b DUQKd7DbmTMNLzHaeruWhVkBWAAcoIBg+CuqDH9LscDs9y8KlqNgioR7A0EUrDe1rfdHy337mfhv o5RB0La92O0xYWAG5gg/4kEKbGtHoxvgYRkOkP5I0NfQH9E//+6negzf9vpHYvsfkj8z/EeXCAjw /Y8c/0dO9RxxMyi2KDJBzz0EkoHUIU3IFDKADCFdgIKQkBBQhjCQDmQCGUH6cJ/u87k7c3/72Vmb gL/f0Ra2GghitleE9B/rhf8/swE7tfv2GQde/2J/KrWuJ6X9+z6LDozfro+xkeQECjE4JBplQiaH ByqhrEl4FSWUOhqtC/4FWOROX0OR2JYAAAAJcEhZcwAACxMAAAsTAQCanBgAAAAkdEVYdFNvZnR3 YXJlAFF1aWNrVGltZSA3LjUuNSAoTWFjIE9TIFgpAAw8WR8AAAAHdElNRQfZARkRNR6sTuBwAAAg AElEQVR4nOydBXwURxuHd881ubu4GxCBhCjuEopr8fIhpbi7eylerGiLU4q7uzvBAiHudvHz29v7 Zm/DEUISLOTuknnaX9idlXtndmb+78zOzKJarRaBQCAQCARSsVAMbQAEAoFAIFURKMAQCAQCgRgA KMAQCAQCgRgAKMAQCAQCgRgAKMAQCAQCgRgAKMAQCAQCgRgAKMAQyEdI8vPF4iypQmNYM5QymVgs zpMoDWtGBRD//OqZexFwNiSkCoLCecCQysHTY392Grlm1qG7Ixo5FAaps+cOGR0uUeDA06TQGEwm y8pi2IiZdT2tyeMPLh07cOBUHsf8p5+6d2/XiIoiw5rV3n7rFThEY7BCO/f65+9NVlzml/z632vm 5bKaTRrRnNwd0qXxjWib+08OWTJQMuTEgkkrLz82Fwo4LCaC44RJVCqTwaSZOy5btcSaiRa924W1 I9pN3EpuBzRstXzD9hZ+Tt+VOqqMCf2GUwNDV8wYjn7+7BJ4fXrFsKUnzYQWXA4D0RIA+xnAfip1 zvINHtbcb7MLlybaCNyyNHiaVG3Npn7bTSAQU0ULgVQKjs4ZCaRl7O5wfQiW88aZWryPp3P/LTg4 Jk/p26Q6BS0UIxRFBZ3Xq3Ft6wBHROgxauyYut6Eijs16pmn0nz2px9vXwJuZe7fRokXhtTzskOQ WtHSD9duG9ezNOU79K6g2A13TmyOUGj9ho/t1NQfnGDuUis6X/U9iaPOuGdPQas166fBP39yiTz8 Z2Rp8vjX6TffblheDE33jNKl6m++CQRiokABhlQSjs4tLsCAnIzU+KiXVKKKF+47efLw4cNvknNx TDqwNqEmXsGNVm7dd3jv38O7dN56IRKc37K2I+LdXaHVqiSZpDC8TJOV/bvq/NiaDrr2H88rWlGo uKQAx0o/Em+lrCA5KXnP8sHg3DHbL8RFRzx58Oj5m6hPNXH7mGYInf08JQ9s/9a7BTh/y8MM8pBc UlBQIFFjxe4sBYFKNVa4r1GriG1cJsnPysrGdT/wLuxhXDqIu+r54wdx2QqFJDc2NjZbIi96Hw1B qRKtkktTExMOL+wO/JY6I7bHRkeFPbgf9uSFXPezuEYjk8kVqkIb5HkZ5y5dV+FatUpZzFq1SiGX y8kfAqlHo1GLCjCwnTj6ya8Dy95v4gqFosgRXC5XfHI6BGICQAGGVBJKFGCALDOWSgFHWmar8I9D kKuvEnLz8gok0vcKkRdgjVK9ugPJlWXFeeoEODKnzKYnjk3zcNY3bbeHicngEgWY5OW57eD8VrNP ld4WVU4KpiI0dlhyHqaSTe9OdGsfjCjAcdXBP36lUQloDtV3X32hOxk7v3UGTRdKE9qsPn4fyO2y ZnVotHrTRnQhT5556pUq8QKdRhs49lBO3FPgWFCpXva2fAqFQnWol6DTT0W+eMPsETQdvcauycwv VdKSrmwGzf3ARjOK2p+V/KZrkCt5+bkX8eDQuvlDEBTlsGgsBhG46exjnBBp9eNLu3lsIiiozaDE fPnHAqx5c/uwK52uu02XWLGEuLVG/fbB+bYhukAP/+PXw69sn0KnWR57k0v+dNix5eDY2ktxZT0m CMQogQIMqSSUJsBycbyuLdsy570AY9J0XZuY6HmmEFCpIvu78UB2pUH2KFqt1v96tyCbv0iHZSq8 rE5b8fPdKNGP3Wjj4L7gH7/pJ8lwUoCjShLgiIt7CHdgVhkCrJ7WGAgwfdDIX63Mdf2+NVrna/CL i1oU7fgVuAdiGvzhum5oka5tGouXK1M3CanxUR9xw+VvjswBp/UZsTU/8SXpfOgZvPmJPCdBxKUX DXRwHYuVYl/q3Z0UykcCrMl97UQr0j+NUu7FFayY0fcjG1D0Ulz+lV2Liv62f8fBqrwPAvz6yNyi tlEog4DTsWnaoI+77tGBnYik5ls56prQyhbexOUrLseX8ZggEOMEjoKGVBLUOPE3KNDhcyciVI51 gTjxyJ71gwb0bxcaaolrNNkpjatbvYyPyMxEtFGvdh24CrSt08gVWf9NoKOoPOV5h5CQIB2BgYGT 1x8mBy6qCjKDmgzSOmsFDSyOvLgMAgtOriQPaREN4uNpyyrhta+ZnSVQmSt3n2pKG/6IScPCtAim 3vHX9sw8jVe99s/PHaDnxP08/zo4uGLxtGp2IrDBY9G1mLL7nPPAjZ45b14NZxsialQKcB3IG7f9 eV1azBNC0tztGFRgCjCGLitIR3TjLmdvuxp1YRU4+C425vD0xtlS9c/TlufJlK/PrQGBaE13pJRX 1kJnF6CCefKb+pADcxcnYZqgRrOzCyQHpnZAtPiVK0+qCWyJhv7oDak5+ZtH1EK12tOnb/054Xct wtly6nV+TlpTH7uwi3cT5bj+Pks2HAGaOmv7RUleeh0qBcd3PHh4Y9aGXVoLj+vvkjUarF5NV5C0 /ZYu6u5LKchM6fzX05d7J157i7vU6zuq2fcNUoNADAHN0AZAIOXDy9xELdH6wks7Qa93GrVcSbft 1n90135EmEYpmdfZ//eLibGZOQiGNOs3avn4QRZ2Tm721mTjMins2rknj/H312uqheOjESqKbxkV GJ+nQfKQ3NQTV1XEIXFuKmg40iny/KxMxBwtUWG1pLDJSo8JqtHKECaHd+7iFWsbm+quTgwaRZqa JgX3c7CfOmcZENBBY+dMmToJRXCJBkPsrJYuXAi86R6DJ02fPYPLIL1qrz//HmHDRd6+eilyqZF/ eSUIMvevrsULdEfrj+3XJHz7Tp0l6odnk8G/E3771YzNSIrNAPf3bRFS+ojk4tF6kJICggYsHSnk cVt1bYkuP61SqNg0om5xCWhqK+C3atkZ2fw67e6Nu7lKnpV9n1AvPoPi4OaAhGcrP8zCUCQnxCHC oDEDWnLp2m4BlIeP8azIiFy5tn6jzk2q24NkK5AC453dnF1mrdp+OHTw6TFd35kTr8mHjx7Ppn7b 4G4IxJDAFjCkkgDasUBiHIQssC3Nybx+8cSx848wTCWR5OuOpz98/OTR0zCZKq+vq7mFmXe0WIai qEYtu37hyMkrcQgxL4ioxM1t7UKCg9wdrPVdu9XbjsvNzhZniMXinLy8gicHZoMTFelvf9+fglLp 6/Yce/70TXJy/P/qWBSkpN3JVBCtcRyxdhAxgFU4lhoXfmjzpqgM0gyEwTQj/klLx8qcAEihUgND gmtWcwHqC3a1xBtUBElJ/annwndJWatmDHx46kiWGif0KzWzTptxL2PTd66c9PbMfykyte4GVDa4 kEKr5l1TxCnsXtYqcaVUCi5xGTnKkk0VWtiBQCxPrNI5FwoVhknSt+85Anaa+ruUZhiVbW6NIErV B/NtmDzwN+l5LK5RrVm3F4SbW1qSh1RqYh7ziePHQLOb5+MDGumYQpWar5aLI1+8ikSE1kK6XjgZ fIEQUYnfJeWpCtJ3hhGOlMicUHE1Jge2R93anhCfjVgFWrAo/s1/Hhhki2gT3uXm8dzbDe0R/Pn8 AYEYIYbuA4dAyodx3euA/Czq+HNtd3cqhQLEFbVp2rYaDWyTWZ0IQSkT99/5xY2QQAqF6h8SIKJS dS9xkRr12uRmPXdC0c6TFn/Jz93auhhcxqvZXKYufBl6ZNNEECL4dZ9G/s6RgSKoRbcuofZU8PvE i83fNp0gz8uJeax709klv7S3rFhWSyqFzTfPVX54haxR5jb1ddSZbdeoYR0qMBth/huR3amRly7Q omGjerpAyuZHiY2Jd8A1E2QfLo85vgikSJ8R2+OeHgXJ4T38IPjt1Ac7gGk+dXtcWt4dBFLs/Ku5 FXbkbnuRXVrENXkv3SgUS88Q/XDpdxcWs3Vp6+SkazbbeUXlKM+vmooSHRIUFxcqkcBs20tvM1cO qYnofAsWi3goP41brMqL0b8DXjyhF3EJl0c+Mq9Oy5UF8QG2ZuDJNevUsfD1sG8/me53xZFXSele vOvalzwvCMQIgQIMqSTMG9aGVFkOl2dhae3o7Lzp2Nn/OTnZ2ds7OTm76AgKbf4kqaAgM9rd1clC JACILCwdHJ3mrPlPNysmJ9Tfafrqg1/ycy8PbnFyrHEn5cNoYVVujKuzY5dVt3AspSaPqVMappm5 wMbW3qV5n3dp+YWnFaS5u7lO332n9Hsr5rZz8fTpKvtYoTGVfHQtbzsbaxsbG3sHx2HL9wOTQbt/ Ydvm9rZEqJ29Q6dJ61QY3qV1iLkwKLHIXJ6c14ecHB1n7Hskjrxpa2XZbPEVLTE5+L6VSBDcsiOm VizoVsvaytLK2tacz3FCBA8ysOJG6cELRnRw7TTxQBHj8AsrZ4LbWohENnaOz5IJ8SYFmMI2EwqF 1jZ26y6+In5Rmvmrm4tIKBIIRU36Ty8AEcDyOzs72No3y1fhOC6fNaidpUgEDjs698ySEROTkp6d c3a0s7CwtHewp1FcvLrPIEfFpb8+Tag0NyBFUrqpEIhxA1fCglQSNGpVTl4+EGA6g8lkMOgMOmjz 4bgG1NcUXTP3o5eExFxSYtkM0EQDp1Lfr9eh6+eloF/2PhGIH7jzRyG4BtV1ZMsLcqVKjEKhM1l0 whT6x4MtQKEr8zd0pRIt6RQtplbrFvai0j78NAjEdHZTyNYkplKoNCiH/dEaXhqdtSiiVSmVNAZL 157UKmRyhMpgMYF5IFwFkmN699p/ns55LUny4X7VulRalUoFEptKZ9J1feYXVk9rO2l5/y1PN/f3 otFBEtDeR41IeRA9FpOl6xoAyYhptBTyKvBclMRzQZhstn5ANE5Ma9bQZM8srBp6/zL/3o65KIot 68iffloxaf+NFX2awNe/EBMFDsKCVBKodIbl+1ePeoBQUUoc54BSWGx2CcHoV4yKKKa+5M+RG2y+ gM0v/crPKXyJ2kseodEZJQV+NIkI6OunBZtaaC3KYLL0F7I4HKDXmwcGrH+sYbEYygJx+Lt4h1p1 PDlfOzoEZTBKWLOTQaFxOB+lM0hh9scpD3yJDz+GUphFjsoS79RrN4yIHoWS8PZZPq7t2qYVgiLK jOj5pxXghBGhwVB9IaYLFGAIpMqjsAh/fYXcdK/Zbut/26lf2AlQOgwK4SgIbXjfcxMKlSnLCI/O KOylGz5z08ju9YBluekxhPz+tNpZxPlOOyEQAwK7oCGQqo4WxyUFuVK5ksJgWwjMi63U8W3gSsnL 8Bgffz/6990MUylycnI1GpxnYc1l0gpvptXERLwWVvMV0mADGGLCQAGGQBC1Iv/hk4T6DWoB6Ul8 9zpTRQms5Q2q+eiHDzjuvnaWJXzqR4vJHj57UzckqGigskD8OEnT0Nvmy386Jzkmm2nnYVnY76pV Fzx8FV8noFYxYUmKeCGo5ssj3i9rwp89Tc1RePoFOFp+aF9Kc9IfPXtJEzo18Pd8L6Da+FdhFl7+ vI9VKjPmBd3BR6B775sS8ep1YoZzDV9PZ2t9zGLCbiXm6aoFNrtGNW87ER/HVC+f3HqXkG0ucqnX IICmSHv8IqZIxcGr1ziIWdiPrHn74H5ivqJ6TX9Xewstrnl7716qEqtdp54FjwWEM+Hd63cJYs+A Ok6WPK1GFR72JC1P7RtSx5rPQiCQqoZhx4BBIMaAJPUdx0wgJpYjxge09rHybq3S4DimcHeyPPws qcRL1DlvnX1qF5tIFPvgoKD31s9/PqkQPDfhZStH2oz/IvQhO4b3cA7pWPSDCMCOd/dP0qlWj3KJ 4b4H5jQW2TQd0bubyKW2/P0waY0qo7Urv+7ACY62osXnw8nQhMcnaVSrZ7lFBgnjmqS3D+g03qU4 Yv2K+Ktb+GaiSVNGWQqtHqXnvz9JNakx3dk9FODt7cRmOj9Nl+9d1M3OtcaChYuDfd292o9/c+tQ TZ/QZk3tUZTdMDTUz+9/KXLyNzX7hllb2zacOrytwMz9XpL02sbfLO0cf+sWwG70S75a8/z8Zp6t 29zZv7KYzJfpkm2z/yf0DJk+cQiHTk/OV35pskEglQUowBCIVotJ2jC5jxNztNKYes17DO4ccCZR ppQkW/OC02T441M7a1tZdhm3mJwA8+rKf8GenuPmL3by9ismwPEPDgp1AvzgxK76fp5+gd2vvE7X qBXjJi1fP2tQrZrB208+1p8sjz3CYQa1auqrF+Ck69s96wbX/ViA786e7BkcWAclpVTh6+TxNlsF pPTlnet5Gjzh0pZt55/f2z2x7YAF4CpZThSX26lAjWvVmaFcr9aNg0gBnjtiYmS28sWWPx3dXZpS uNd0AvzvkB7/G70X/NTZ+a0WX4p6/4OqaY2tX+QVfuFoQJe6IzdentiIejqV+CgFaAoP/LnX80xi uyD9NYfeNl/9wVZcJekk5EekEl9XXDWj1/y9V4QCm7RcORDmvh1C/r4RO6aJ9VHdtxd3jq69cPOp nrXd3+QpgYtxdV67P889Ks8HCoGYAnAlLAiEWB560sy658ISIs7u9m7YulurVivWX8x5e8pl0Pis S1MmbLuy6+bdEYGUGiGDC5KuNhyzfe2REyFIklZT8rKX6tQrLeadWfff6U1z24wc1B3HNUf3LFLU 6v3vplkrRo8reL+mJdMhNFl8u2eb953YmtSWXTbs/nev1cevYAOmzHp6+04Lcq6NKilXoehSt1W9 hiG/LdvBQxGeo0ctNyuNWunoEwSuY7DtGOjFXAU2f2TvkLXr+tctXNCqfpv6AhbVs9/g8FdvO7Qp LPXt5409vHdc/Xp1B6x52TfYschvqu7eu3vnzp1D2/+4cPN16ya1+0xZ1M3FIbheg/4jZkxYsd7P 8qNB13pQOvd4Vl4NW152xM0NO57X87OmcFh8NgNBKE0tHB6/jMbYlvVciWFTjZp0eJv+FtFkvI7K QrTqS6fDU3LLWJwTAqmcQAGGQABo3YEztu+9u2rn5SatWoU0bRZ7avXVHSsm/6/R7Z2vosMfz5w4 bvWusynvjkbduhTar2/9mp49R49FqSUXH7ptk8WtbJfPnjrt940andwC8ezZvnmtxm0b1cL16orS eQIeq1CNcax/aEibqQPV8W9zpNmPnr3S341lJuAwqVpS67WYRmy++/Lxu9evN5Q9/jeiQOjVsl4N O1SDYPlKhPwlBHmxd+Ki14I2XuyIpKxH924qMfynzj0s2VQGl89n05H3bsPvk+f/PH7liVMnlv7W ovvCU0W8Cc2rh/fv3rsTm8fed/ZxZ29zl3pDcjPfbl+3spm3eceAwMsReaWmI4o+ProhqOmYOVt3 t3Bi43ihu4ES3yakIlK1SoOS+0wqb+r67X/0b1y3fv00R0stHIwCqXpAAYZACLg2dfGr204+Kmga 6GzlGWKjfjZ/R2Y9DxuBPbVV9zFHjhzZt/+f6VOnWViZxb1LUmuR/KxERK8ZyoQWDQbJcG1eXqZW Q0+89Pual9qFqzfu2bKA+HKB7ixSd0uf4Iu4hvRSJrzd9+/RlMyk05culaxHTDcrB4RBo1FoDC5O o9MouEaNYbjAxjEm8hG4Qp7xXMHtbm7uPNTX8t/9+++9Sbh48GiBUqPSrW5RjARJnn+j+jZWti27 tXkZFl9EgNm/jZ84efKUKZMntKzriUuia/uEhGej/nUaDB03Jbi2MC6roJRI4E/2L+oz/9Bfl84M 7BhCZXGdJIrEXOAZaC4kvqvvU83KinnpeRo47/jR49UcamYkpe6//fL27Tvc/Og67s5f8pggkMoE nAcMgRBQGZzOThk3fUa48GgoajWtT4OBe61t+KzOcxbMq9fuf3lvs+5t17TaM7NlW+cFXu0GJlFe HsFx28KLmVaO2vO16rdIeflo1cUoM9HlnNuH9m3n3zjzr0RshuHaspfeIFbvoNAW/7GK2MFSur8Y sWDq+GIXYBSKrunIGN05qG+Xtg08mPcx95ke3Df/9NmE/7J+0FCbqYGdB0vf7t/655WIhg1dGvYh rto5sbv/vD8tudQGPjbrrsYH2xIjjdUUlGyGj+7bttvInnGdWm7ZcXjv5Qe0D7+FarQI+v57hFRz r63ze7QLdPCp2zL86V0L+5+3hhDffNR+EiVMmhs6fGmOudvk3i3GqvKaTzq09a+BtZ1aD+mGPdW2 3hXikDh6dvvONeMG9Nr/QHtxfci9vUcn1G/bPMTsclb1RbWhAEOqHHAaEgRSCI5riMWsyEUatUTn KbmMlhbHsrNyaGxzMx4D1R3KzRLT+RZsmn55KRCIZYtzmDwRj02EqKX5eXKNUGQODoBzNBoNeean q1cSv4OiRVe/1J/8kW0aDUolP7mnlRdIpBguEpiBq3RmosBm0gCGmYjP/HCtfmnM9+tQFrsVolLK c/MkAgsLRpHu9KIn6MEwdU5ODp1jbsZh6K391FQN8U2qQkC0gGHKgpw8FcVSZEZehanl2TkFIksr GpHOWoU0XyLXiiwE5TH3GAIxMaAAQyAQCARiAOA7YAgEAoFADAAUYAgEAoFADAAUYAgEAoFADAAU YAgEAoFADAAUYAgEAoFADAAUYAgEAoFADAAUYAgEAoFADAAUYAgEAoFADAAUYAgEAoFADAAUYAgE AoFADAAUYAgEAoFADAAUYAgEAoFADECV/hhDVY47pNwp41u/lRVYgiCQYnxVPVCFBDg3N3fVqlUW FhaGNgRSCTlx4sSpU6doNBqFQqFSqcR3+CqjHo8ePbpatWqGtgICKQ4obsagZWKxePbs2WCDrApQ HWWcTyvjWOVj4MCBHh4ehrYCUgmJj4/PzMxkMBgsHXQ6nSyBhrarnOnWrVuLFi0MbQUEYqRMmDBB Xw8wmUxQCQB3vAwNrloCDIH8OJKSkthstrkODoeD6r5Hb2ijIBBIxZGXl5ecnAyKv1AoNDMzAyFl d4ZVIQHGcdzQJkAqM1FRUXw+38bGhuyFBo1gQ1tUzsASBIGUTVZWVkxMDFBfUFhADfDZeqAKCTAE 8kOJjIwUiUTA2+XxeGwdhrYIAoFUKKQAAy+cxWKBFjCTySy7HoACDIGUD2KxWKvVWlpaKhQKDMOM YUgIBAKpSKRSKagHGAwG2FCpVKAdXHY9AAUYAikfQJED3i6pvrgOQ1tUzkCXAgIpG7VaLZPJ5HI5 UF+NRvPZSqBKC/DevXv1CWS0lUuPHj1YLBb6nmJHExMTr127Rm4bbRSEQmH79u2Rz41HQN5HwTgj Qlpehv2gyGE6tDoq0DQIBGIUANHVN3y/pB6o0gI8fvz4tLQ0Y56vGR8fn5qaamVlRaPRyFf6xTTs 2bNnvXr1AkcNaORnCQ4ObtKkCTkegZycU2x4sLW1tZOTk6HM+xJycnLCwsIYDEYZ03z15a3Kqu+L Fy+MPwX8/PzKmJ2Zn58fGxtLbhttLNhsdo0aNYpFAVT9r169IreN1nKk9PQXi8XJycn63WJRMJIY mZubu7m5lSEZ+vz/hV64UVfcFYCRSxeo60EbV61W83g8Pp9PTjAFgUXPIaeaGcrCLwG4hCAWHA7H zMyMy+WCKBQrgY0aNTp69KgBLfwsu3fvzszMBOkP6j79U4CzjIrRtWvXiIgIQ1tRFsBFkEgkwJGi 6vhUCa5fv96mTRsjL1B16tS5c+cO6QuSpoJYFBQUgMzp7u5uaOvKwtbWFjQqyCpLbzl5aP/+/cOG Dfs05cEJxvM4Onbs+N9//+lbEZ9dZ+OzGLX8QADAKwS+LWgEg1xI02Foi74a4ECAWAiFQpBZ9WtF GXPHQ4kAHwK4QQKBAEQE0XWnG9oio4N8voa2oixAxsvIyAAuFHAHwV+yQBV9lKDVYvweLShQpDtY dLUHYDlZRRjaurIAOYS0HKQ/cIOKVWjGn/JKpVKf8mT++c4174z6aUEAMTEx4KnjOE6urkL24uqP GknPTNkA+2NjY2UyGbAcOOl0HYY26qsBD0IkEgFnCDwIMgpGXllUMKYy6CwhIcHMzAx4UcCXArmx 2EM0iViQHi0ZC7IRBmIBcqah7foigOV8Ph8UJWC/yXmxoBJLSkoyNzcHKU9K73dGAQqwsQPyK3jG XC7XwsICFDyTqCCKoVKpQK4FsQBRIAcHmoTfUIy4uDhQ/ID6guIHHgdoeRjaIuPCVJ4pEGCyD4Ns gYG/+kOmMnqOfKdDDg0h3UFTsRzRpb+lpaXeckOb83XI5XKQ8gqFAtRmZN8DALaAKzMSHeCRA/U1 UekCTgOIAlAv0BQmp+gY2qJvITMzExQ2Gxsb8CxM9EH8UEwlQaKjo8FDBLUnOaii2DoJJpE5gQDH x8eDTMjTQUbBJCxHdI4sOahFb7kJIZVKY2NjQSUGXHBynY2iDtw3AAXY2FHqMNG2LwmwHERB3/Y1 lZq6GMD5JWNBzvE10VhAxGIxaHgBj5B0B4s+R1PJnMDsrKwsIAAgT5J+OWI6DhCwHEgvcMf1LQoT Gg4C8gyZ8sD+cmlLmFgXfBXky6eUGTP6WBjakG+HrC++ZHJ91cRUHq5CoSBnbJtuNwbIgSAK+v4k 04oF6cWWaLnxD6oAeUbfliiXlIcCDIF8KaZV00FKBDhSevU10QcKzDa5hq8efcO3mOUm4dfqU768 rIUCDIFAICaJyakviem6PuUOFOAvBfg9hjahHNFKCgpgCYBAIBADAgX4i3j2z1gOu3Gy4is0S1MQ 99fGzZFpBT/Oqm8m9eUVkcjhelIJtqW+PLl5875cZQkdLHFv7m/asqsSuCFxzy7/veMhDh0QQ4Op VWpNqY9BKZdrKuNDkkkVhvhZrVwu/+aLNSoFpjGBLmKTMLIoUIC/iKTIFxpNAf413SZpd/aMHjPy WFjSj7Pqm1HKs3GNBi2p7jsydtbIEb/E5Ks+PXR1/6qRkyarf7x5Pxjs71Ftfx28WFUJ63bTQjOq TfWfuq0u5ajaz8N6yfYbnx6QJT/xsfaOM8qMmJ/26tbtp4rSvQp1wnFzAf9edF5FWgVIfHTC3Mwj TPJN+oSr7R3smk/aUVqs8jISTx/Zt3brlhsPXskN11P4cvdoOq1Vulqb8Ob+/WqptDEAACAASURB VCeRJlG+4TSkz4MhyKtHylIOKl88eeUXFPTpAYc2s9LShltaWX16CFfLM3KUttYCDFNSqExKhQ/C pyClZs5RV8J65cosRaxPDw2at6ftGGkJB0wMZVYOEX3oexoaLDcrGecQ3UollQClUi7VYiXIbNyr +xHiPBk4YnyrOKxr3H5uVOKjDFmQVckFRVmQptEY4FvRMkmmRqNCSvcMygBYC2zGS1HWgpi71p5N VBh5FO09den+ZdMMMq8o+uktBKFi6uxRPvXvOzgnJ8QxKr5u/UpgLVQqWlXOcP9aXAqFQeHMvX5f 6+TKZ6AZkTf9atawsbZ2dPEYs3RT+JnNgXXq1ahVS8Dj2TpXq+HuKhKKGnTsg2uR+LOLa/r6v8wC TUnl2nEd7KwBNtW9at6PztqwcLizi4NXdUcmg23l6Po2Q2aoODatbh80cCmoDc7tW8C3dEqSquZ0 aFE7dKpSixSkR4UE1nZ1cXH3qD5sxnIphuxePLhxq/aGMrU4atmDG2dPnjobl1noG717eGnO7Hnr N+7NVBK1zIn9fz+LSj65a8OwEeOeZRCdfq9vHgoNCQ5t3u3fCKIdYGJ9VaaPFlNm50oQYi6HihQg ms4RLK2OLC1ckZsGKi4qHdGoVMY2lmf01TNXbtzxETJT46KkxvS2hlq6z/2dMAR2A7r3OHb9RUpy fF1f1wOnHstLf3Hw49bLBPcNu6frt6OKNrx6cOr0OToFFWfk4IQDAdyHH/Sz3wsU4FI5tHHO1ufR feeu3b9ztSUbRdgsZcL9uj7NwyPjpy35g6kSn7wcpsZBFYBFvn6dJ5WmJ0ZHyvm1ajrdu3gvWY2/ fXQkKzNFo9Ue+mvehPVn6nQd1VwmjYoIP3vxiVKjUCtkMSkFq1fOVqUm3Hudaqg4ZqkUuJroi83P SpfIZCiifZqckiqXqLIj6oUEPg6PHjl5Tm1Mtu2P6WHpBVEvr+ZkpRjK1KJE3fy7mrtr/eYdunTu 4G7D3nAz8veZv/rXa7N4ycJxYwbYsB0zJfmLp/8WVMOpy6CxWzevC/rfzrPz+tRt1uvS4yeXrl/M BbX2T60ZMO9XLJsXjnB0dWvawI/JYLnXrheT9aWvJNPf3fmpRUMPDw/fwPpLd53QCXNy42puDBbL 0r7a6n/Pgv2bJ7cE1PQU6j5R1XL8XxUly7LRPRu72tuCH2Vxbd9K8TUjx4xafBrPe+Vb29MzsEkN RxtrJ++WTRq4ODn5BvfN/kiZ1H/NHV7L28vLq+aUbVcrUCAkv/UM9XBzq+FZs9vgsWq1okVAjdqD NmJaJDfqrqeT47xT0Xf3Lwzw8XJzcw9u0GTf3biyb8cUuW3Zu4Mef3PMqBFvY1JsHSwZpTc7y91h 0qqyJ7VuzEdRGmq25MlbxNGZi+aM/7nP3O0RyugjdjaikHp1BBya0NL6VHg2OH/ZiAF+3t6e3r7j 5uwtX0u+DVgJlcqbh7edavlvnjum94DhXj7VQIvp4bGTCRhj+tFXE4YOthZwAvydabqsVrvzqJzn 21AU3Xf49B9De6CqzPBMRVp0MnA6KSj6+Po5rZaRF3HmkFQqrB7ctHEt8v6Dtl0b3iVAjSByVQkv XCsKilc1SyISICOoNHINnqZRIxj+4vzut0mq3/bemTrm1w71rBBExGcgOSni0pslFYn6t7FzojWi v68/j7p/HDgNaVmxe7fup/g0/H3WLwhRyFN0Xq9WK/LYdvFqcypFi2tHbDtnE9QzJr0g4fERCgVF 5MYQkaqFBJPK88R3n0b/NrRv6ssH996kFz2K47gGw4glGj7uJpUmP2lds+mVu8/adeueGhW2budF ta4Sl3PdZsya5YxlT+43/FFy/uU9f4ZFJg6cMWto12au1vyKiZE66d6uw3fotm6zp0/w9fDg05DH r9+9yczUYArQ1E9+cSsyOSMz6e3VW/ecHXmvn/x76FGm/tojG8eOWbwlmWprqXqzalira+EZFWGx VjO1R9Pthy4FNWmBRr45tmPfcylqQ5W+2Dn3YYLk/MFd75LyPAWxbX9dpOA7Bwp5T+/dWj19YzHN BE8K0z0pzXs1lWdEdxk89sjxs3lSZddGwdQKXNnq4J+zVl9+1HzgmJlTBrGoCCIwY2GSZ29iIvIL MFUuhiBPHzwK/qkXJydz2e7Hz/cOmr55j5RhxqdK1y0efzOztBeLFQcU4NLQyOQypVol12UyctY1 TuQ4Tcs67ihRweNqdWH+G75gEYNBvPKJT8m2cbRGUdnDiCzy7ToF0RTkFgBxS8ilz93wX9T9C/4O ZjnRsXRbn9W9A7RaorcUU2AGiiNAGx6RWfgSjkFjkyvRpCuS3+RptbzBLWsC69aFibU8b2tzBtU4 5BfR5KTHpfXpM3FgE18tJgGPxJslTs9WSMPvzFpx2L9u62OPEq14RPL/b/Cswa2aHYgMTzs6GFOo Gvfq4GrNs/OoaUJL31U+2iw7vXZmXwRF82Qf3ryIH20zZzCYuq/UOfk3x4pU+Ve373qFUYf/fX/d iuU2Qk6zpl504vHZ3n58ZfGiRZdO/44giY9fZ9as7Yeq5ev/2Fu7y5Q1E/tUzAOm29RwFPGjwx48 SKFsOnTQgUl5q8EQYqwmCv7jWoQky8VWXGTG5nMn/14Nct3NJ/HvL9WcPXqG5V7vzdMrt57eZWu1 T8OiK8BgjUpx4GaEFrF5/fhGpFbrEFDPmc9Ys3YmE83et2nH7i1/23nVc3qwNl+OOZljx5+/pvMt 6ncNLZqYL09uY+o+ywaeFJPeKFlO1Ixc+5ritOTz+5aLzLmbF+zMwCruvcCjezeq1Wl6cse6JcvX urvZIxiCyXOJVH6/UIZb98nndi0BBiWmxk8YfRhB7M9du3F29zoEydpzqiLSvGzgIKzSoPo1aZ1+ 4i8rs4Y9GkluPYlEPHwFAhGKqDv1GLKyjfnDd5mI/OqkJm3AqRotznELtEGQzOgEgbcLqFzuP0xw 1b3swLQUj+qeyKVYd9/a3LyXvjV+ZbWc2IOiYbGYQLGpjr4CoHcJCQjiW5Fx05cPIZd35+CWX3nx dy7sRrQChPA2tIgt26uhK4pmte8xfAjn9st3yYhfMwEd0eLgmDG8ctMgciQtKzwnO3XdgtnAIE93 Z2JNd63fzcdHqwm0l47+F1vtfyCASSU6w6zdPME2jU7bvWXvmE5NqAnPiH4wKtTgigb4nTTHwH/H NMUi92IgN6k/dLvynYIGDB6o0DAFApaDd8OiLyy1xMQSvGdoTVTn/+F44YOj6DZyM7JBMItO6zlr v4d/y0FTlo8d0P7yq1VH/phQEV4W3SksJnzyqJEHT2ysc+zfOHEiERglxXX2u/eeYs9ioSglTZLJ s/FjU9Dnt18gTckrlTkpmZ7VG1jTqcCrRytqFUYtrsSIsVTpMrVo7YErQ9qHUHAtq+EwX485m5aP A8W/+47lac+GgjMfPHvb6Zcxa5ctMGd/ZJi1l9/Agf/DEZTLtXT0DrJgUdLePd936tHI8b+26Ttl 6NZDy24oiKlltIopX1hBvgRHcZUWAUWdSMj3P6t9kZ9w9yXYmDN2BAWTgjYQSyKLAKoc1MtFwMrR Ep2OOMvw8md4C4yWfhPWZCYmTPjz9N6Lun2p0m/wuFUvLk/YsGv4LV1IwrVEZCCQWy4LiCmuaxZr ze3sQS64cyps4c8NkQMnzVj0iX/+l5XbY+neTVd0F52bPSR8fzj1UQy4EGG6CgVISkFSKQNBfzjb lgz16T5nx987iR0GApr0wTT2Mzubmm0mbZz7YsSCv5frThOy6UDOXLxq0lIqevpECVDtqjWqfXL3 Ous96zU6P5fK8/VvVDP51oum/jWISgbHz7TuWuyiraMatp13PsTLjVyHB7kWpiFeEBjC/qqKBlFy uGYcBKW6BvIRNCs+TX+IaRu4cev2Eq/iUkHew3qPnLerPTM8MSf88N3RPu4IktbQSTRpRM9Ff2zV ams08ed0r2HL6Tj5n+2rQht3jU3Ir5gYJV5Z1XzSkXkLFlC14rX7XqVIdS6FG49KlmY5kDouk815 HZ5B49t6IUj+qxcI4q27lOPiF3Ds0MEek33OrF8E1KBeQPUKMJhCZdOJr/cofhk5gRp9WiBsU3fZ vVsTg6d1rNVzzS2tW8NdA/zfqfwQ5EmtJqG92gQN+snvscQ6K/y2/g42Nepu21636D0fn94/ZfKK ufO3jv3FYsXNx0jNrgJ6hZUrmqt/UMzq49YW7QY2zyCaCgGFI+NRHwGGSMGGyIxHM+eDKCU9DutL oa18sqb/QEby5WUIYjuuS42KsrNUoACXDsoYt/rE0EVSBKWx2QxMo2VQaePWnhu8KFeDMsz47Nys fIGl4OeCHhwOB0F8jt24YlstmGbBTY6NoogcrHgjFKNwBp2CIGZL9p6fvVUGXHkmuBGN2mrhnqGz cV0bjHs3Mp3FE1SwELiE/JyX357D5aEus2WS8XK1hkFBMrMLXHjMzU9ebkQoNAo6bN7O/hPXaamU wGqOIi83JoJM+OfJGK1RvLM4fOrq5XNnItOkipQb83//15LDOH7xbtjje2HhcXS+sFZgSEAN53dD J9ZsX09/SZu5Z163v//w2SuOlbOTJV3C8akgHx3yHkvnaozwbMLvZDjyOEhcTtSXLLPRdOqskc9v bTy8JPSwrl355t/I/Cng34LcnPlLtyBI4KWwwx4CloUDc/ua6fv/RIF3NXpgl4p5ycAVitJf3B/Q pQ3w6uzd+vrxKb4UWoydBYsjdAG2cojXUiiKEv1KDIGvH3JBehWlAi0ghuzO/2Pj/ZvBx1bPA7uL d9ytU134Q00lU5rCYD++drxeq58XTfgN7Fo6Vl//iw/Y6DJnY7W1tWt1GQGa6X5DNv4ZLpuwbte9 Y7uA5ePWrCLGTCBoaUPm2gyfMv7u/TVHbv6xCUFqNH9w9C9eBTq2ExdsSY5P23jk3Nqjuv2UbDVL UA1B1G627kGNEeRfFoOGULk1qyEx8mvz48MPe/ke3gPUF5m2Zbcfp8LMLBUowGWBohQur3BABzlo FqVQzQQWZIiFlQj81akvgFK3cXMy3MbZrfASOkV/H6B2+tvS6Ez++ymMIosSJgr/cIh4FdrD4vDI GYtcvjlxhEoYHXZ0be/Z2+0cHXLeXYpKw5d0agFqNJRK+65PX5Yb+LlT52k2bnVFMeNWnwP1Ag94 NSx2cKPQ4EYfTho3b8XH73op3kENwP8Vbi2kkLELdvSfptH5nYKrT14J7dw4YwZgdF4pp/OeRqSy hZY0OnXdwbszkhLUNJ6jnTD6XbKbl0vPvnNRXF0gU5pbWLHpRB/p5ssx85OSJEq1lb2ziF9BX5kV BQ5Mye6YmpFFY5k5O9nSUPTw23cYhcmg08KyMoEvCM75Y9kqc0+Q65gL/30wQmnB9XJNSe1iZS2g ogHXY3KTUsUog+/qaPmjHdvqTQenpXW1Mqci5s0j45PEWTlaCl0osmDo/FCa0PeROJPJExJKS2WP W/PvoLnrJQqMay4w47BBMUqIjsHZ5iXqKp1juergtXk5YqkSt7CyZNIrVFOYPOsNB28vEGdqaWyR gKNQIxwm/ZVcQmNxqYgmKaWbjS1RS6+8FT1Dac41t4iOT0hJzdTSeU72hqh4PwEKMKQEbGv4/NS8 QXp2vmvL3wa27DGyS0NDW1QEPHvu2P4viKFjCJXFn3j0uYBVwvszONLK2GByzOzetzmqe/ro/i1L KYXWNuQGhcZwcK1Gbnt6u4O/DJ37yDX7cDKVOMe9nC3+PChfYAn+1+/TmFyySuULRGRIn4FDyQ0n z2An3YatTaEHz2TzPdwraMA2SEQr60LJodBZ1rZ2xY6bCy0+7KComciqSOoiHKElUjoohWJuYW1e TpZ+NRSqhbUtuclhEn+ZLK5uj+pgV5iFRLbu5POgMHiOLqX5fAYACjCkBGxrtf5zQyuy28rolIxi efNNUlR0kgaludXwsjSroOYOBAKBlC9QgCGlYHTC+wEzkV2gqLgLD4FAIKaFUYypgUAgEAikqgEF GAKBQCAQAwAFGAKBQCAQAwAFGAKBQCAQAwAFGAKBQCAQAwAFGAKBQCAQAwAF2AQw4glBEAgEAvlG qvQ8YIlEEhwcbGgrykKlUvn4+FB1nxkvTYbr1Klj5AqN4ziNRiNjYWhbvp0yHgEEAoF8A1VagPPy 8rKysuJ0xMTEpKamymQytVqt1RrDR/cIgG4JhUJzc3MOh8NgMICGFdOADh06NGnSJDk5GdgfryM3 N5f4VrZGYyibiwEMBl6OQCDg8XhMJpNU4mLn/PTTT6tWrcrIyMjOzk5PT8/PzyejYDwPAtjs7+9P fAOVySSfAhTjTwGlaciQIYa2oixABgNZkU6nk+5UiQ9x6NChRv5wQbkAtQEoSsViMWPGDD6//Ne2 xHH88yd9GaCCBZaD9C+xUTFo0KDy+qEfBLCZtL+82hJVWoBBJgCpyWazQZm0siIWSpXL5RiGGU+9 D8qYmZkZqcHATrLIFT0B7IJAcAicJhKJlEolEAmgXuVYZr4TYCEwD9gPzONyuSDBPy14//vf/8Ri cWJiYlJSEnCGwDb5IAxl86eAIkdGAVRwLBYLpLmR19EGISIiIiEhATzEqKiolJQU4EiBDGk8viAA lHTwEEFhAXmSlIFiz7Ft27bA0wJZEXi0sbGxQLBBVjQqpxwUn59//hlEgSxN+o4lELJ8+XKQ/rE6 gDtLWv6dVUH55vOBAweCckT64sU0eMyYMSDDgMwDUh5UAiAioIFkVG0JYG27du3IlCfbEt8vw1Va gAEgB4MMAZ4xSEpQOI3qeSPv1QtU+tbW1iDXAms/LQ8gHwDRtbAg1lIHJxubDwEMBmaDLCvUUaJ6 keeACIJYgCobxAL8BRWH8cQC2AyiAOpu0hMqRxe40kA2DkAqgSQC7ix4dqCqMipfENE5UsAqkM3A 30+zItgGqgDqVlDiwDmguQbOAVnRqHxBYCSZFUFpIjWYjAJpOShE4JBUKgUxVSgUQIANbe9HAINB Nau3vGghIhMfJDj5gEDOAXH5fgeiHAEWgppWb7++H+V77lmlBZjMsqC+AEkJHjbIr6CkGdXzBgDb QKYEzxtYSPrsxc4BgeAoqO9IGQZZ1tjqCzKdyWZ6iQJMFjyQs0lnwtheBCA6dQEWksUP1M4gzWEL uBhkVgSJQ747AM+aLFBG9RzJDAaKEnARStMA8ikDy0F0yKxobE65XmhB3UU2xYDlZBYFlgNrQQiI oBFWBcBa0hcHdpJVQdGjpJtraWkJ4gI2gOtjVPWA3sUEKa+3Hwrwt0OWN7JrF+QMkFmNqqQh7y0E 5jF0lPi8yQIJNsjMbWxVHvK+n1wfhU/bjmQUyNqEdHtBFIzHE0J0FoIHAWpkkFuAkZ96QhC9AJNl iuyJMaqHiOieIzCSzGYldimRAozo+sZAJUuqr1EVqKIeLUhtsvpC3nuxZHMCeD9k578RWg4SFtgJ LAfpXEyAyW4wcA74C2TYqJq/JGTKk/aDv99fCVRpAUbevwYmy6RWh6EtKgHyZUlpY39IeSP9X9KB MMJYUIrwaSz0JZPM30bV+ayHNB5klXJ591P50AsD+SiBL2iEz5FsKYKHqB8K9GlWJLuUyKEVoEAZ mwYg74s8GQu9U062IElVA1WBEXo/SBFHtsR3qGQTUx8RY3MgkPcpTzbYyPGksAX8XZAPG9G9HDK0 Ld8OVYehrfgu9GNJyCJnbAUPeT8aBY5/LgMyE5ICTNb+xvkcy/AFyUxIVgtAgI3TKSfN1kehqM2k QgABNiHLix7VN4eMM/8Utb9c5iVWdQGGGA96hTO0IZBvpxL4gmTdamgrvgWyE8J001/vD5luFL6W KiTA4KEOGjRIqVTK5XKFDrKXxticLIMglaox7MP7bzabzmBUlTJQFKVSo1B8NHCUy2WAdsVnLwS5 qFWrVvpezcrqRsyfP3/GjBmg7JCFqEqUIBA9aT6i784F7R6uGVK5nq8RdlabKG5ubuSrNJLP1gNV SIB5PN6JEyfImaaA+Ph4I5ynaCjUak1YWJpYLCcrU1DJ1Khh6eRkDjYMbVqFAmIfH58TFZWjUhXm CpACtWrZWFvzQGkq40JQ2MzMzPTrjZj6sl+lcfLkyeTkZH0JysnJMbahtuWLVq1Sv3mGZ0gKV+1l shn+DSh8c0PbBTFS2Gy2UCjUT/f4bCVQhQSY7LsnB0CCilImk5FrVkABJnF2dszNVZw/H6VWE+5w ZKQ6OTm3UydP0KgztGkVir29XUgI/upVxsuXGWTI69eK2FisSRNXKytOaVeBrMXn80HBMzc3B2Wv Us5T0pcgcjanVCoFMSVn+lbKRrAmI1l57wrQYETXG0Rz92YGNUIoVas4QL4Kch6zfqLzZxvBaKUs OSUCYiqXy3Nzc7Ozs8ViMfhLzjOD3S9FUSiwe/cSb95MIHdB/qld2+ann6pVNRkGAHfk+vW458/T yV1QjuzseN26eVtYlCDD5JIpAGtraxsbG/3qoRVr8o8FlCCFQkGWoCwd+lVfKl81Iju5F3v3HMEJ 7xxlcdjdh9LsnRC0EvZqQMoR/dKKoBKwAg47hwN2y2gHVyEBRoiOVjWoMkDbFzjvZN1hhCPdDQ5I kISE3H37Xr19KyZDLC05PXv61K3rWPladWVADsdOSMg7ciQ8LOyDDAcE2Pbt62ttzSt6Mjl9hZx+ w+PxgCNM+r8GsPtHAooMKDig+IBCBDYqZfNX9SZMum8tLi584sz6rTndh1B4Zoa1CmISFJvoTA7q LqParFoCDCoLUGUAGQZ/MR2V0nkvFzAMP38+cufOMLm8sIu+cWOngQMDbG15ZV9Y+QAZ5NGjpAMH XkdEZJEhLBatU6canTt7CQQsMkQ/ABUUOf0cwcr3GhiUILUOshxVshKklcukJ3YqTuwih1xRhFbc X8YyG7SpZEOuID8OchoYuSgKuWZA2V541RJg7Xv0Dd8qFf1vQCpVz5595cmTVKDHCLHYFnXOnKaN GjlXwTHSGg1+7NjbvXtfZGRIyRAOhz5lSv2mTd2AHiOfzHGslL0F+hKE60AqUQnC4iLyV0zCot+Q u/SaIeazN1CEloa1CmJakKW+aCUA3wFDvguQQR48SJo+/bJEoiJDXFzMN2xoZ2dX/h8+M35wXPvX X4/273+pHybN4dA2bGhfq5Z1VRsxXnnAcdnpvZL1cxGNbjg3nWE2ZhGrfV/Y8IX8aKAAQ74IoDdb tjzetes5uUujUbp395k8uUHVrKNkMvWaNfePHStsLYFEcHY2X7Ei1N1daFjDIF8LXpCbNbS1NjON fOdPdakuXH8CvvGFVAxQgCFfCsgqUVHZU6deSkzMJ0McHPiTJzds3NjZsIYZBJAacXG5f/754M6d whHjDAY1IMB20aLmIlGps5UgRoX8zH7JliVaSR6xg6K8YbPZnQegTLah7YJUFaAAQ74OjUZ76NDr rVuf5OcrEd08pVat3CdNaiASVcVqC8e1Dx8mb9v2RD9bCchwly5ew4YFm5szDWsbpAw0makF6+eo 7lwgG740d2/+5JV0Lz9QJRraNEgVAgow5FtIS5OsWXPv6tVYMvtwOPRRo+p07epVBQdnIbrX5OfO Re7aFRYdnUOG8PmMQYMCgBKbmUEZNjrk105K1s3R5hFj2lE6g911EHfgZJRVFT1IiGGBAgz5RkDG uXUrfsWKO6mpEjLEz89m9uwmVfY9KIbh+/a92LfvZXa2nAyxtOTMmNGoQQOnKriMiXGC52VL/lqg uHy08I2vnbPZrPV0nyBD2wWpokABhnwXQHXmz79+6VK0RkMuIo3071975MiQL/mAQaUEJMiSJbfO n48kV/QECIWs7ds7OzubVcqJSSaDVquOfJUztiuiUhC7FAqzWUfzmevg0pIQAwIFGFIOJCTkjR9/ LiGhcHCWhQV7zZqffHysDGuVARGLZYsX37x9u3B8FoWC+vpa//57KxsbrmENq7Lkr5mhOHcAwXSf uqLSBMv3M2rXheoLMSxQgCHlg0KBnT0buWLFXbWamCALJKdhQ+d585oIBFX01RqOayMjs1auvPvs WRoZwmLRGjVynjGjkbk5y7C2VSnUEc/zF4/WJMeSu6xmHXljFlKEVdc7hBgPUIAh5Ulycv6GDQ8v XYohdy0tOYMHB/TsWdOwVhkQDMNv3YrfvPlJdHQ2GcLnM3r08AHJwmbTDWtb5QdTS3askh/drlUS 3c4oX8AfvZDVqitcYQNiJEABhpQzoOV3/nzUX389SksrHJwVEuIwZUqDKjs4C9FNGt6798WBA6/S 0wuXsQSN4IkT67Vs6U4uYwkpd7C4d/mrp2GvHpG7jMBG/InLqPYuhrUKAikKFGDID0GjwZcvv3Pm TKRCQSzvR6Ggv/0W2KePL5dbqb7Q91WoVJqtW58cPfqGnEINmmEODmZTpzasU8ehyo5Z+xFo1Ur5 qX2STQsQ3ae+UQ6fN3Q6u9MA2PCFGBtQgCE/kLi43DFjzurnKZmZMdevb+fjY1mVxwPLZOrZs6/e vZtIft8C4OYm2LSpg4UFpwqnSrmByyS5U/pgb56Ru6jIymLbJfhNBYhxAgUY8mMBzb6TJyP++OM2 uQuaevXrO65c2YZKrdJqk5EhnTr10qtXGeQulUoJCLBdvrw1XLjje1BcPVGwZrpWWkDsoCh3wARu vzEIDb5rhxgpUIAhFUFammTFirs3bsSRu0Iha8iQwJ49a1blLwjhuBYI8MqVd8PDM8kQLpfeurXH +PF1eTwow18Hnpedt2ik+tmdwqUlXT3NZq2nefgY2i4IpCygAEMqCJDRLl+OXrfugb5HOijIfurU Bh4eIsMaZljUas3FizFbtjxOSSkgQ0Qidt++vr/84geaxYa1zVRQXDsp2bIIz0gldzk//wbavii3 Kn4uE2JaQAGGVCh5ecqNGx+eOBGh0RBvQOl0yq+/BvXuXbMqD85CdLOVxE2AggAAIABJREFU/vnn 2cGDr3NzFWSItTV34sT6TZu6giQyrG3GDF6QK/l7ueLUnsKlJW0c+ZOXMwIbw/FWEJMACjDEAERE ZE2dehG0+cjcZ2vLW726TY0aFoa2y8DI5djSpTevXYsDG4humLSnp+WsWY3B36rcV18yWi0W9y53 ci88R0zsUmmMwEaCpbuJ1VAhEBMBCjDEMICMt2/fS9Aa1q+ZXL++09KlLXm8Kt0URnSdBNOmXXr6 NBXHibKJoqi/v83y5aFCIVw/qxCtWiXZtlR+ZDvZ8EU5PPN5mxkhzQxtFwTydUABhhiSrCzZ7NnX Hj1KJnf5fOb06Q3btKlmWKsMDpDelJSCCRMuxMYWft+QwaDWq+cAZBjOGMZiI3Jn/g9PTyJ3GXWa m81cRzGrusu8QEwXKMAQA0Mu1rhgwQ2JREWGBAXZz5jRyNVVYFjDDA6Q4Tt3ElatupeUVPiVC4GA 1aOHz8CB/lV2/SzJrtXyg1u0ct2CYihqNv1PVrNOCB1ONIKYJFCAIUZBXp7yn3+e/vffa3J5Cjab 3qdPreHDg+G7T4UCO3Xq3T//PMvMLFzG0s6ON2BA7W7dfKrUXGosISp/+UQs/Cm5ywhqzJ+ymmpt Z1irIJDvAQowxFgAOfH587QVK+5ERGSRIXZ2/NmzG4eEOEAZlkpVW7c+PXr0jVxOfFAPRRE3N+G4 cfXq13es9ImjVavkFw9L1sxAcN3Skjwzbu+RnD6j4FBniKkDBRhiXIAMuW3bk337XgHJQXRDkLp2 9Ro5MkQggEOQiGUsZ8688uhRslKpkyIU8fe3nTmzsYuLoLLKsEacVrB8kurxTZA1wC7VuZpg0d9U Jw9D2wWBlANQgCHGSH6+cuTIMxERYjJ7MhiUuXObhYZ6VFaZ+SoyM2WTJl14+1asHybdsKHTwoXN K9syllpccfNc/pLRCEY0+hEqlfvLePA/bPhCKg1QgCFGikaDv3qVOXbsWamUqH+B9Hp4CLdv7/RV S3YcPXp06tSpP8zG8iEkJGTv3r3oe77kEpA4795lT5x4Qf9imM2mh4a6z57dtMQbVK9e3fhL+tu3 byngMb9PhOyJPbGXDwq/aGQmFG0+R7VxMF31PXbs2JQpU0o8pNHFsXIwa9asQYMGfVVmrspU0bGU EOOHSqXUrm1z/HjvLVueHDkSDlp7kZHZoaF7+vXz+/XXQAaD+iU3yc/Pj4iIoFK/6GRD0aRJE2An jUZjgFiBaOso+xJwlre35alTfa5di12+/G5OjlwuV584EXH7dkL//n69e/sWWz9ry5YtLVq0+JGR +F6Cg4NBIoAUoNPpmme3pSsmackVNhCE020Id9BkU19asqCgwPiz4vezZMkSMjMDwKP8ksxclYFJ AzFqhEL2tGmNNm5s7+VFfFFOqdT888+zIUNO6KcOl43xN/sQIlLK1NTUrKwsUEeD7S9vD9FolNat PY4d6zV8eDDZ/5yVJV+79sGAAUcvXowmO6gRE0kEAEiEzIT4tFUzxTP+h2UTH6ig2jgKluzkjZpv 6upbdcjNzU1KSkpPT8/LywOZGcMwU8l+BgEKMMTYQVGkTh2Hf/7pPGxYEJtN9Nm8eSMeOfLM77/f EotlZV9rEoVfoVDEx8enpaWRAozj+FddzuMxfv018NChn7t182YyifSJjMyeNevK0KEnnzxJQUwk EQAxNy9FTflFfHqfSoNrtAizeSfh5rOM+q1Mt9u5CpKTk5OcnJyRkaH3Jk0l+xkEKMAQ04DBoA4d GnT+fH9vb2JhZFCojx590737f/fuJYIyXtpVJlH4gQAnJCQAAQaNBrCtVqu/4SYWFpyZMxufPdvP z88GtIx1c7rShw8/PWbMueTkvHK3+UcQsW5hRlJCAaZVc8x4C7aazd5IMa/SX8oyRUDbNyoqKjEx USwWS6VSkJlNogwaCijAEFOCy2Xs3t1t2bJWdDrxLg0UcCAwffseyc9Xlni+SRR+0FAAjQZQYUkk EpVK9T1DcszNmf/80/nQoZ729kSfLYg9cFC6dv2v/Iz9gaQpsGy1RulUg7/1Aj24maHNgXwL+hZw PiiTX/M+pWoCBRhiYqAo0ry52+XLv3Tv7k2GREdnt2u3b/36B5+qrUkIMIZhBQUFoLkA1LdcWgxO TmZHj/b666/2AgEbMZFEAEhxRBvaizN2MUKhmorNX0WlH4GFEF/0kufl5QFXUqFQgIwNBbhsoABD TBLQFJ42rdH27Z0cHc0Q3XqNu3Y979Pn8OPHKYY27asBYgN0V6NDq+P770mjUerUcTh5sve8ec2+ cMS4waG27EqpVgvXTcupfAL8ta/2TRQguqQfiesor/xcWYECDDFVKBTU39/22LFev/0WxOEQy/FH RWWPHn12yZKbBQUl90gbJ6CG+kG1FUiWjh1rnD3brxzv+QPh8Ml0MLQdkG8HPL5y9CMrPVCAIaYN iqJAgHfv7hoURKzLj2H4sWNvO3c+cO1aHGhVGtq6r+MH1VnwE8sQiHECF+KAVAZcXQWbN3c8dy5y zZr7OTny/Hzl1KkXAwJsXV2lhjYNAvkikpOTMzMzi4YYYSPSysrKwcEB0Tm+hralMgAFGFJJABVC u3bVW7Vynz798s2b8aDuevo07eLFJ9OmGdoyCOQLWLly5Zo1awxtxWcYNWrU8uXLaTQaVQeU4e8E dkFDKhUMBnX16jZ79nS1seEa2pZKhvbGmpYBAR2TpSbWsQ8pR6RSaXp6elZWFjloHw5y/k6gAEMq Id7eVocO9ZwwoR6VCnN4eYG/uxr2POy0AoODpKouEokkNTVVv8hGpRyvXpHALmhI5YTDoffr55eT U+97b6TO3vLH7lbDh3lYsZ6c3pMqrGelSXYPbGilG9kkjnkUrXKo62X/Pb+QkZGxadOm77WzTC5f vvzV1+DyG7fC/GtXe3TnZpaC3r17x58WHTs/y9qdmbtkyjJRp4HB9DwZYt6wTi0aBdFqFA9u3EjL 1zjX8PH3doUfjays5ObmxsTE2NjYkN8OoVAoYAN2RH8zUIAhlRlybeTvIfX2/pHzJi6t02VyM7P6 XYdgQUMdH22pNXTpyU1TtbK0ul71Y9mdc7MOm9EqWx0kjz7RskU/7fuhQPvfZh5v3eWgdT/JrREH V695uXoNsc4Wgg5bcWbDmPrj+3X568gN8uvEs3ffXdCvbmVLjh+PSTQl8/PzExMTganmOpjMyvUJ 6goHdtBBIGWhVmHgL59NQ8i5jUyroCCPc1um77mR8OjM+hg1PuD30XxqJZQbXCPHtVozK7t/9/wF WjgSqeyKBtMyKRpJ+msEYbFtlm3+x01A3zxl/KG/Fm08cr3ByMVrp/XQ4nh4fApiAlIC+RYUCgVo BEskErlcDuf7fj+wBQyBlA0hrm4OAgRREpu33v31bMGJgH6LJ3Rxefmczub93q9BJe6B23vmUfva 5s5OPgE1zacDXc3DqBxzGwRxH7Nlym8d26AX/IcduHbJFRy5s2n2beIDiN7rR7atxAlSxcEwDEiv SqXSLx1jaItMG9gChkDKhlhU6/mb9MK9ej6Wfj0HdwmJCXt2TYPXH7nf1rwy98IxWAyExqnfpAmT FFUeSjWzdADt46wCRIudWHYNSK8Mw0A17Bs47tmbGFXBzYg3kZihzYb8IMiFruCCZeUFbAFDIGVh H9jSCkH+GNhinyUVwzQIA2gN9fd5E3Yc70vn2x9Y1O77Bxzx+Xx/f38rKytHR0dLS0uwy+WW5xwq UGOWwzAZ3dtg5P1tHu8bFvJ42bPodMfGo0YP9Nh36Wp8zPnJo569vHUnE2ucobxiSYetYAjkM0AB hkDKgmYVtH7bipNXH+J0nqeztbxmDQqCpDyLB4eCO02zY5dDHxKbzfb29nZ3d/f19XV1dbW2thYK hd9/Wz1qtfrWrVtfexVd4BHaqoOdBZvcRens1ePGvPZoQy5ryXfwdatm79eg9fyF851E3BcOTlv/ vZgnV3mPCuk/chJUXwjkS4ACDIF8hp+HTOoxWP+ui2hMbjp9HGcJV60cakizfjAM2ybnLjT+0HRG aQPmLyU21Ingj3eX6f8t66hfkbBWkx7rGncnR0FD7YVAvhD4DhgC+TzoB8Be5osbD2s3aRdiXZnf /iKliqmWePuHYu9To8jZUH0rDm38u/DIxAxDmwH5LmALGAL5WiynLF9t1fgXStWUG7rDzC1rLBs3 NrQdVRpcrWjUqH6S10Ds5lrT+NozpCSgAEMgXwvabdA4Q9tgQKjdfh1raBuqOhQa68KFCxK23Zf0 Ycry8zR0Lp9FVanVDAbxEj8vO4crElK1uBqnMKCAGw7YBQ2BQCAmBq5Rjho27MT9cBRBHp36x8vR ysLCvmlo51uxYkQj2TBnRJCft5dX7S69+otl0l6NHLy9QnzdbJlsTujonbLk6w4WopAmrWzNqRwW Y+fNd4aOTdUFCjAEAoGYGDimeBv5NjVLLEm417fTkFSZdd/e7WJuX4iJTF81oNuYxZvVwuqegvwT B/e9jBfLpdLkhLAUhU2HQJtLGxeI83OkCBJ264ptYAcbTL1g6y04pddQQAGGQCAQEwPXSNUqFYoi e5b+GYWY77h3e/3G7Ykyxf9amO/Yf8m9Yd+wGyen/xwMzqzmJCIu4Fmdefaon785gsQpMeIbgpaB oQ/P76CC/eQUuJyVoYACDIEYmOzs7LS0NLiqH+SrQBGEQaG8kmRa+dbr4klMHMdUSlz3gd5qTlwK sW6K7mO9qpTkGKRBy4717KgZcXEgIP3Fa/C3w5C5NI0qk7hMA3OeoYACDIEYGAzDjh8//g1rZUCq OEoN7se3znx92W/w7xf2rXG0tFq49xwLQa7dfnjt3vU2c06Bc55GpKlAe5dXG0FowW3agxBxbg74 6+hgQ2WbNQNbt+8pNAaNRhUGCjAEYnhA8/fUqVOLFi1SKpWGtgViAlCoXBqdKeIwBi1fN6id/+sd s37qPzG9wK1N405rD/6hTnreokFziYJYk/tsWIqLPYIjCrDtHBQA/qKO1cFfPoeBUFiNiYCLBUr4 FtgwwGlIEIixcOfOnV9++WXXrl3luxQlpPJBYwlikzNpbB6Ngv59/N6ihDi1lmrn6sqkUJAa0yTZ g9JzFdb2DvLUaIqVC/XnNAqXyFH2Tce/ed3F3dMzLbW70NoWhEy4HNclm2HLgS0xwwAFGAIxIl68 eNGhQ4cDBw40atTI0LZUNEUXG4N8FhaXT26gVLqDW/Wih7hCa3edC8dzraHbtyHDKRSOl48P2LCx tSVD2CIXH1EFGQz5FCjAkMqMo6Nj+/bt5XK5VCqVyWRKpZL8irih7fqAWCzWaD56BZecnBwaGrpt 27bevXtTqeWzSsLq1auXLFki1aFQKDAM+4bPyaWmpha9Cthm+74e/06A6FKAOHA4TCaTRqOBO0MZ hlQFoABDKjPNmjWrWbNmSkpKnI6srCwgxkB+DG3XB/Lz80+cOAGcg6KBwMj+/fuHhYUB1SSXLvoe gJjt2rUL6Hp8fDxIBKCjEolErVZ/rSMCbgKu0u8CvWzbtu132kYC1JfP51tYWIC/LBYLCDAIKZc7 QyDGDBRgSGUG1OOgUcXj8UQikUql4nK5QEKAABtPIxioY+3atdeuXQt0sdihlStX3rt379KlS2z2 /9k7D/imqreP3+ydJt27pWVTKKvsvQVZgiDKFBQURFD2lKEI8pcXUZaAIEs2soeAgGyBsldL9947 O++THAixZZQ2zU3S5/uB9Obm5t7nntxzfuc54zmCcl6Cw+GAsMnlcqVSCS4mqYW8bSIUE0U4T5Uq VcpjmPmZQc6lUqmrqyv8RlDnQAFGKgMowIgjA74UCA+oL4gQyHDZhKeiASX7448/1qxZs23btmIf XbhwoUGDBocOHapatWqZzw9iBgIsk8kgESA1wNGEWkgZmqDBTvO3cM569epZqq0YRJdoMNgJdSZs hUYqAyjAiCNDBBgUCMRDIpGQvk9bE2AikD/++GOLFi0mTZqkUCjMP3306FHLli1/+eWX/v37l+38 oGRw++BZQmrAa5k7wot1SIPNwcHBlpJJODlx0wEQY0t1fiOILYMCjDg4oD0gElCgCwQCnZGynQc8 VPPv1qhRo0OHDhaxkJgHMjxq1CjwdOE1Pj7e/IDU1NTBgwfHxMRMnDixbG2zcH6iauBcgvqWLRGK XRreurm5leE8rzo5ABbiICyk8oACjDgyZHgt8YD1Rsp8qlmzZpkPVx4yZEjv3r0tYaMB0wycLl26 /PPPP926dXv48KH5AeC2gnP89OnTJUuWgBf7tueHFCAyDzJc5ipIyXNKJBKLnIrAMMOCp0UQmwUF GHFwSGlu8TKdtOta9pyEgICA8PDwd9999/Tp08XEcuXKlbDzzJkzZZj/YxK2Mo9vKpmGFZQCCFJJ wKGGCGJz8Hi848ePL1iwoKTmgWdcq1atO3fu0GIYgiAWBAUYQWwR8FNnzJixb9++kg3O2dnZrVu3 XrduHS2GIQhiKbAFCUFKRZcuXcz7gENCQqxw0d69e58+ffqDDz6Iiooy35+TkzN27NhHjx59//33 OGDYYZg4cSLdJrwBMqgC++ktBQowgpSKw4cP03LdJk2anDt3bvjw4adOnTLfr1Kpli5dGhERsX79 emdnjOdr98CvCfWq2NhY+E0jIyPj4uLgLfzKlho0V35Aelu0aCEWi4VCIZvNxmAp5QcFGEFKBY1V fl9fX5D/kSNHbt++vVhxvH///nv37h08eLBGjRp0mYdYBDJM3RS4TaFQ8Pn8soVMqSBAcUUiEdgm kUhAgzkcDk4YKycowAhiB0C5vGXLlkaNGk2ZMqVYLOsnT57Uq1fvzJkz4J3QZR5Sfsi4ehA2uVwO PzGXyy0oKLCpuOUkkppUKnVzc4NXIsB0G2XfoAAjiN0wceLE9u3bt23bNjc313y/SqWCnXPmzJk9 ezZdtiHlhITsJlOrQYZdXV1J+7PtBG4jFkJdkEQMFQgEJMoN3XbZMSjACGJP1K9fPzw8vFevXnfv 3jXfD67SvHnzbt68uXPnTpyea6eQeG0gaUTkiPtrOwJMGWd+A2Ae2AlijN3A5QQzKoKUismTJ5v3 xjVu3HjQoEG0WFKlSpVTp06NGzdu165d5vu1Wu2+ffs6duwIGuzh4UGLbUiZMYUqIwHMSbxum1Jf yiykmiliKHrA5QEFGEFKxbJly8ynIQ0dOpQuAQbc3d23bNlSs2bN7777ztwq4Ny5c1A52L59e6tW regyDykbpBsYGzAqD9iAgCB2CbhK8+fP37hxY8mAzPHx8eAHg39sa/4TgiDmoAAjiB0zePDgmzdv gkNcbL9KpRo4cGCxZnMEQWwKFGAEsW+Cg4MfPnwYFhZWbD+4v8uWLWvRooVNTWVBEMQEdjYgSKkY MmSIuTfZsmVLGo0phlwuP3Xq1OzZs5cvX26+Hwy+cuVKrVq1Tp48GRgYSJN1yNthg2OvSoLjny0C CjCClIoNGzbQbcLrkEgkS5curV69+vjx44sNy4qIiGjatOlvv/3WvXt3usxD3sjEiRMDAgLotuIN PH78ePHixSwWyxQGC0dBlwcUYAQpFbZf0LDZ7M8//9zPz+/jjz9OT083/yg1NbVPnz4//fTT6NGj bf9GKi0TJkyg24Q3MGzYMHiW+Hy+UCgkgTgwGmV5wGYEBHEoevbsefPmzbp16xbbr1arQZ5HjBih UChoMQxxAPLy8uLj49PS0goKClQqVbG2FuRtQQFGEEfD19f3xo0bnTp1KrZfr9dv2rSpYcOG+fn5 tBiG2Ds5OTnR0dFJSUlkpSYSLYRuo+wYFGAEcUDYbPbhw4cXLFhQsnnwwYMHAQEBjx8/psUw5FXY hZLl5ubGxcWBBwyusE0tlWinYB8wgpSKAQMGmDe4tWvX7osvvqDRnjfC5XKnT59eq1atDz74oNhM pMzMzKZNm27YsKFv3750mYfYIwqFIjs7m6yWCA+VTa0VYY+gACNIqdi7d6+5AIvFYhqNKSUsFqtf v34XLlx4//33Y2NjzT+CYhSqFFOnTn2pl4wgLwVEV2lEZwTVt5xgEzSCODhNmjS5cuVKydDQUJh+ 9913oNAFBQW0GIbYHaC4pN8XG58tAgowgjg+np6eZ86cGThwYDFnF0rSffv21a9fPzExkS7bEKTS ggKMIJUCNpu9ffv21atXs1isYh9FRET4+fldu3YNWxQRxJpgHzBSKSi/tIwdO9b8JGFhYRaXq4rr i61WrRqxFl5BgEtO39TpdK1bt/bx8XmNDVlZWeZvExISqlatWk7DzBszoR5AAhxinzRSSUABRhyZ TZs2icVii8Stbdu2bbE9+/fvL/9pgeXLlx87dgyMBGkkC55b5LTmgOPboUMHi5+2/JhutkGDBvn5 +eCmkxiHFZQOCGJToAAjjgw4WH369CnZ6GpTLF26ND09ncvlCgQCeCXh/Sx4fkgEu4jZm5SUJBKJ oMJEYhziuvSIw4OPOOLI2EWnplKpjI+Pl0gkcrkc5AeU0uICbMGzVRyQCM7OzqSRHDxgUm+g2yj7 QKtSUFw+PDRaSD1MNPsBB2EhjoxdTJZQKBSxsbHJycm5ubmwbfH4uvYiwJAIqampGGLpbdEXJdbj CbpPW9srTM5mMvdcuLNuzviNJ++QT28eXvvZjBUx/54UugRFqw2HD+/RavrqQ7SajDwDPWAEoZmi oiLQHrVaDU4wWWTGsue3FzGLi4vjcrkymUwul2OU/9KjVebep6j7i0eTt9O+WyI5suWm64n30x6K KO3wz0bf1nTt4JtVlJmXqaICOUUXr16oUxvk+V16zUYo9IARx8YutAekFzy/rKyswsJC2LYLmyuC fCMY4LCMcARnHyd91b1VRIxiyapvqPRHtWr8GP7LoNtx1LhxYzw4FCV3ChYaDoRCX1tJHzGbAwUY QWgGvD2lUgnSW8m1R6VSQQpojVTaRCgDRdk58CptPbZFVc9IZR6lo1qMGNe9CpUQMbn7xP0UVXPs mHcMx+UXJiuffUWnx35imwAFGEFoBsSGCA+ZFFtptQdSgEQYptsQO0OjKILXsJ6D2AyqsdiZehCf zXT5ds3PkJJJavWwxYtrOvP4EiGlztmx5/iRP3dnFFIcViV9xmwN7ANGEPohoovag5QBgZMcXuUi DrxWdeFT1JmINGWLpr0oahxFuc0YZlgWunarTr7U5LmDu5GvoPzaCCjACIIgdgzfq+6jG5dd6tSF 7d7fLtnS4+tm3rwnJ/6Ct62mr67uYej4FfvWjyzMvHA53MnD7/Zf+/zb9qfZaMQICjCCIIhdw6ze oCnZEniGfPReCGwc3/YTxRGumdDFdBBXIG/fvj1sNKw9mRYrkZJgHzCClAttUYFCpXnzcQ6I/szS dg0a9EwowClDNoY+98T2cLGwfZCLiG5TkNeBHjCClB2dRlGtWkBqjaFZf/3IqXQDS3WPz4TfCs9R aHQUZdPBPisdDOm2uJgCrgefVekeSvsCBRhBXom2KE/J4gu5HNOeorw8jlDMZlI6vZ5pWD+BM378 +DTXxkwHLejSYh/9e/uJyN2/VZN6TF3R2fPh9UOrXrtwLkPB6dev5zsL9h2Z6RHEz/1xxtK6Az9O ubD9SRo1aeoMCR8LFpqRufvL6LYBeSOYTxDkBZfOHPht/ZaEPG3bbv3GffL+sJDa+1wbTGlXJTo+ r/eQSe+186ge6Ne2/7gHp7fdyuJu3PfXRy1871693mB4V3AAE+9f+nTEiIeZgt6Dh3/91WhvCb+U F01NTV29ejX1fGmgTZs2DR482PwALpdrPkD6/PnzzZs3f80BERERgYGBZU2DFxzcuKDvqG90OkNM Zq+OXz5YEdaxw2D98zHb2x6m7e3UZ7fX0Ozj/b9e9D0F/4w8Etb/Y3Kv8l8dQRwe7ANGEIL+5vZp rTr12Xn80oN//5n6+dDND3M4Wp326sGfVm86dnjnB+93SSoqUikVW9f+EJXLcNEkzf18llajPHH2 1PVHj1XZj98LbX3yVqpQoFq78OvT16Lf7tpGyCzYkvOAtf/ljQeUJxVMqJLODx85V+7R9vyt8JZg YZxGpy0C46RuXts3r4SqQn5B4UmNRs9nMxnGK3IEX6093lUq3rH7ssoiFiCIo4MCjCAGdCrFexNX 63S1rzx+umn+Fwyx54Dq4is6DUV1vB+f9vemJcz8hL33n61I/9etxyNbBylUd7SaXGVRIezZ/82i qxrtopO3bt++l12k+KhDTVrvxgLEnt6Xpac2HtjasraXgEGxQxuxjKXFlsPXBg4c+s+ZvwfXcdJT eipbTVzvsPadlw5rflmvpXRYrCBIqcCcgiDPAL9S0HNgNZmhx5fBZDCZ7K4cLhUW7CFmy739KCZD o0hSFun7zP61vgeVFP3ItFgej8U8mxHnXK3j2Ja+8JbFZjtAj7CqCGobeo2hc1ufDRWUewnE8eby uRRb2LxNGx65fSkz49ET+Ntm1GIGi92QyaIepisx0AOClAIUYAQxYlATPTt8+/kb4fuObNXlph6O zOFTDMa9oxu275g7ZoZex/MTGaLYt6pZh8kQBNcPKyhQ6YxKo9TqggROmfE3Pv3f9n9P7+nVsf22 v2/QfDvlpkr3Ic4U49O+rZs2an5Nq0uJ/Sm18L9Ny89bwjkiQ6gHEY9DMdl1DW3T+9LzcWISgrwZ HISFIAaYHP7asSMHzF3WPqwRpTe0qo6duHsYeMWF8WMHf6jX61sNnNCrVhCfD7pjUBe5n092QUIR g81isUVc9sgZ0w5cu/n71MGbDcLkM3ThWywpKBKJqlevLpfLPTw8ZDIZbBc7YO7cueb9vn5+fsUO mDNnjvlbOMlb3ftLEXh32PPrT+tO/aNjizq9OyD81hOhc7WunXv6uDy7NQZHuOKrL+9X7+5Vy2vk 8GFNq7lQDPbAee8/Pq0WcrFmjyBvBgUYQQiMLrP+9+TjsfcjEqtHmeEUAAAgAElEQVTUDGFnR8Tz Av/o+C1VrfepDV9xuc7NG4Pjqz9z/qp/7Xpw9KDPvw1unyAXetx7HC2Qe/C5rFOX79y6fLFQx6nb vIWMzy39hUGAw8LCgoKC6tatGxgY6O7uXuyAYvpaElDot73b0tB25Lg2H4+ljMOzoQYAr0ePd3zx MYM95JtFZHPdbxvJRovx64+OrwhbEMQBQQFGkOcwGG4+wW19gg3bHmHelPYP2OC7t2jZhvesU5cR 0jiMbDn71ujmWwM25B7eZA+bJ2rUtrP1ra5QTP3cpg2k4oiOjqbbhDcAjwGTaWjeIK9IOUEBRpBX oKdSKb0+V4NLFCFWYOnSpTk5ObGxsREREVFRUXFxcdnZ2SqVynbWyALRbdmypUQiEYlEHA4H3mK1 rJygACPIK2Cw1t26tVzDE2Ahg1Q8hrhqLJZAIHBycnJxcVGr1UKhEF5tZ31okFuxWCyTyeRyOdiG Glx+UIAR5JXwxc6lDWeFIOWGzWaDAIPCgeML8lZQUPDSuCt0AVrL5/OlUqmrqysoMZfLhRoD3UbZ NyjACIIg9APyBqIrkUhAccG/dHNzA/f3pZHRaAREl8fjET8YxBhqDOgBlwcUYARBEPoBJQM9A+ll MpnwSnp/bacDmAAuLxgJFQVQX+IBowCXBxRgOyMmJoZs2FS9uJwIBAKo71PGMgjzM1JpAeklrdDg ZdpU47M5xEjSY425tZygANsZ7du3v3r1qoM998OHD9+yZQtkaahZk7yNkxyQSghxggG6DUGsBP7S dgYok6urK91WWJiioqKEhATStyQSibhcLiixg1UyEARBioECjNAPCHB8fDyor1arZbFYpI0LBRhB EMcGBdiesM0+ofKTn5//9OlTuVxO5jmA+oITjK3QlQ3Gc+g2BEGsBAowQj+FhYUxMTHgB0skEmdn Z6FQaMGqxoEDB2x/tiKJaUDCGlSEAv34448LFy6EdC4oKIB01mg0eiNa7dstW5Senq5S/WdNJG9v 7/KbR/o+yeAjSIrKM7oHHk6yYb9166CgoDp16mDNqWygACP0o1arc3NzQXcVCgVogwXHfw4aNCg5 OTk+Pj4yMjIqKgr0A+QHLmeRk1sEKLZ69uwplUpFIhHIT0W0vcMJN27cCIkAtZzo6OikpKS8vDwy x/RtT3XkyBH4uvmed955p/wWguJCCsjlclN4h0rS/jF37tybN2/SbUW5GDt27JIlS+C5ZRmh2xw7 AwUYoR9QXJBepVJpWfWlnocWgmIdHGvw/8C7ggvZ1AQPUEeQXrkRqIJUUHQhuHE4OVwC6h9wRUiE ssU45POLRwYLDAwsv3kgt5AIJASjKc5w+U+LWAHIVmlpafB0QUaDp9d2cpZdgAKM0A9pC4VXi8f9 gXIcNAOEB/QGxNjNzU2lUr1tu2uFAnJIhn9DFQHshFLM4rNQQNGhZAR5o4wK6urqStzfMnjAYGex PaGhoeW3kCQCFOIyI2Bk5WmFtndyc3Pj4+Ph6YXKE/5kbwsKMOLIQDkOpTmU6aBqoEBEfW0quhCU WWAkkR+JRFIRAmwKsURi/UNBaeoDfttTlfSAq1atahEjyRRwgRHSDWyR0yIVDQhwQkICPEvEA6bb HDsDBRhxZMADhkKBiBwUEER9ba2VjAQBBsgQpIpofSUaT17LrL6UMRRwsT3u7u6WMJAiY9BImMNK or629hyWDeIBw4NB+lDoNsfOQAF2EP7++2+6TXgzbdq0sfJoSSK9pGQH781mizyyzjlpd60IASYa D4lQZukllPTOScu2pSC3jy2ZdoRCocjOzs7Ly1MqlTY1usIuQAF2EEQiUcOGDem24nU0adLk7Nmz JJg7URrrlLNEzyqJU/UqSFKXP8FLngHjJlZyQHRVKpVGo7HBpSNsH8w8DoLtzwGAsjslJQXcUIFA AK/EIUNfB0HsGjKCkkgvur9vCwowYj1iY2PFYjGZcmNqdKXbKARByo6pUwPVtwygACPWIyoqCqQX KstkQBBpi6bbKARBEHrA2e6I9QABTkhIyMjIKCwsLFskJgRByoZSUfjGY/Q6bX5+kXFTW1ikrGiT EBRgxHqkpaVlZWUVFBTggEkEsSZFKbf5AtHCvxNff9jpXd86u3uk5qnO/zRKJGweb0MxWx0TFGDE epB4k2UOw4QgSBnRaeBl2fGrr6/zqgqzDH/0VGZKJEWpGZhHKxgUYMR6aI2QUBjo/iLIG4l9fDfP EoFTOQJDiIzOQdVKOeuAY4FrIm8GBRixHibRRfVFkDeiTr0aElYvuGYDXze53COwcf26nh4ewTX7 Zho+1B1d8XVIzWAfH7+QBk2OPsrYPTOkWp1GYQ1C3N1c/FsPSom52DikhouTlMlkytzbJBrXkDy7 dHCgr6dEIn9v8grDe71q69xhNasG+Pj412/c/HJsLp13WylBAUYQBLFFdFpVXq4+LSI8IT07OzXm +q279Wo4P320f+eV9MdHF/Ud/2MGy3tQj6b3wq+t238r6ea9iPs3/s3khwV4xUVEX7946vq9x03f H/Xjwkl169Sm0lPhhMmPw4s8moTI+Pt2nsqnqOMrJgye/7vSJXRAu2q3rl/+81wk3Xdc6UABRhAE sV3knh1ScmNchdQ3v53atXox7Dl5+d687rOUlNeRE0e+Htob9rzXh0TB8/r79PFpE8d+0K9brdrN 4P3R9csuxTJW/f6t1FjSc4UNb53b3SPIl4qNTC/M/r8vV/FENa+d2TN+QHv4tH2b6rTdZGUF5wEj L0en1eiZbNbzLiO9TqvVMdhsrLEhiFXx6z9WxmTrGYzYzCShe00xRT26cLue4ZMCXzeJJsrQRax+ Nly5Tv0AF6fgz1p/ZHiTn/Lww2GfH/l92c4Td58cmgR7+i3d6Cniagz9P4Z1weAvh10k5nNydYbv azQUxqWzMlieIi+lYEwjUdUP1prezxjTo37HnjrsukUQK6PQsDgyHl94914qR+pVg0WpHtzxE3Ip Knfphm2fzv4FDln6v13FvrR9waCWH0z5+MtpAd7OVFRcntoQ8YZk34ZtRRT1ODJZ7cHn5Bck/X7o WO+pG2H/pu1nTF/HjG4dUIARSqdWpGUYxl9oNEoyOkqXn/nvXY3i0imNUgk7dJQ+K+FJSkqeWo8T AxHESvCkXoZGYaHwhR5yXerVpfJVl+cnP3GXi5Z89tGhv/+F3ZkXlxfEwd8C07whdw/vW2cO9Hmn y73IlMGTpwZJebCze+dgeG3SqQ+83o5SLb33N6VRje79zt0nsbAn8vI2FptjzO+IlcAmaIRateCz r5ftDwl2vXkn0jOozsKPGn6yYLMWvN24nVzBrq+Xz/t5wjcKw7TdpwI2T95nbeqeUSz7b6vCkdgW oXImo5UWEREF38rPYwnELIb+jz92i/zqgCj/cDhypkbCk7glJqdlZOXyxU48hiojX+8iUA1TCeTP S/SOn/yQO3BWfqGCJ5TIpWKwV6VUcozLOXu2HZeU8IGLpyeH6a8uys/ILhA5yZiq/AIdz0XKS+s1 10nK7TH/VO50tYRnjbuszKAAI1ShplCZn33rkWbyV5/839K1md5Tv11QZffP8+/mSxfMmdWqbXu/ Rdw9uzecu5Y5Y+GU6s3bMO1ZfSdPnmx3K7dotZaYCmoJIiIiiu2ZMGECLZbQwvDhw0NCQsgi05RV ZJgvEhv/Mlp36kb2uHgHuRg3WFyBu4eAHOVtmOVLeZl/k8GUOMklZos1E/U1wvb09ny2xRd5eIoM WwJn4zkomZNRFFgciRgnA1c4KMDIM/osO7qgW9b//e9XQUCjzz8dkHBw4dNYp0mTDGM3mtVrlB77 z7mY2ClTJ0nt3PlNT09fv3493Va8BVZbOLk0LF++nG4T6GTTpk1+fn48Ho/L5ZIFQG3np0HsERRg hMqKjOL4Nfrt05baiC1aSq9VGfwtY7nywkfUQ0Fj/11D4PWSZRDpNgSxS1JTUxMSEpyM8Pl8kyuM IGUDBRihdAyVUCgVUBQroIGYYqTHJlBUdbtpn0UQa5GZmZmSkqLT6YgHzOFgIy1SLtAVQCjXgKoc DosCH5fnLxFRsdnR8GCwDOMvXjSvMZgsB3ha7KjfF7FBkpOTY2Ji0tLS8vPzVYaZtLbSN4/YKegB I9SX8zePnKkz9u1KrzyKFcnc4cH49kDKFPWLQZAzv9s0ZrrK3juAK4MA2/I92nuPKfGAnZycFAqF Wq225aRG7AIUYITi8ATy51Lr5e1LNoRSF6HZMTyR1FtkbcOQUtK/f/82bdrQbcXr2L59++nTp5lM JovFglebGllWepRKZVFREfi+oL64oDVSflCAEcTuadWq1fjx4+m24nXcvHkzNTWVx+Px+XyBQMBm s4kM023X26HRaEB64RWlF7EIKMAIYt/YixgkJiZKJBKZTEZGoXNfTEu1G3RG7CXBEdsHBRhBEGsQ ERHh5uYG6gXSCx4wmRJGt1EIQicowAhi39iLQxYdHa3VakUikZOTE88I3RYhCM2gACMIYg0yMzOl UmlhYaFarSbRQJGoqKi+ffvSbUW5YLFYUJcinfoY4uZtQQFGEMQagPQqlUocP2xOXFxcWlpadHR0 bGwsiHFGRoZCodBoNHTbVVpAd4ODg52cnMRiMQlOgt0KbwUKMIIg1gB0xSS9KMAEEDBwHyUSibOz c1FRkUAggDqKHcX3AMUF4+VyOWgwGI+hwd4WFGAEQayB/jl0G2IrkFDSoFugvrANSgwabF/t80wm k8/nkwoEvNrjyHZ6QQFGEAShBxBgodAQ8AZkTCaTEfW1ozoK1BvA6wXdhWoE3AgK8NuCAowgCEIP 4EGy2WwSmQRe7bF3nEQ3IzKMa0O9LSjADsKUKVOcnJzefBx9REZGhoaGQkYlwQhxwCSCkFZo4kfa l+9rwrS+p/1GGKURFGAH4c8//0xNTY0xAlKXlpZma/Hi+/btK5PJJBIJn88nMox5FUFwUeHKDAqw g0Bm44nFYmdn54KCAthWKpU2FbSWy+WC+rq6upLFzNlsNgqw7aMsKqQ4PB4bFQJBLA8KsIMAAgyq JpfLYRv8S7JeqU0NpyQDPkF9QYOhogBGYis07WjVRRdO7l+1fjfDNfDT0Z+1aRh0+9TORT+s2Xn8 b/j06pOk2f0b5Hl16Rfm8ShBM2nBvGreErpNRhDHAQXYQSDyBv4u+L5SqZTMJrQd95cyNrWBE0zc dKFQCBvY8kY7C77sOW/VKbK9fe2Pt6Pvvt9pUMTzT+8+TWewOReP/X7xmOHt2g3LEvI13iL81RDE MqAAOwhkHAcZTgnaBuprU+4vARSXmEf6gM0/0un0YLJSqSksVOXkKCiqiMVSQxXCeB+GV+M22dBp NHrYa3xLkT3PP3px5PMDXnwK51GrtUlJvitWXIU3Go3OeJgeNkyv5Hizt+b79cbrGrZVKpK2phrO s/ASpjpPsWgT5m/J9vON1x35si++5Dxg38CBZfk5Mv7947tVp6o3GHn94k8TPD3X+wyu7i5gUhSH y3tvyoqfxvWWu4rWpsYFNe955sCmqP3T232y5lZkinc977JcDCkFe/bsmTRpEt1WvIEmTZps3bqV MmZnyljy0G2RHYMC7CCQsYggbGTDBtWXMjOSdACbsm56euGRI084nDSBIJ3Pf8zhSNhsEYNRQQ+n 76ZN4RVzZnooczuHWqlQU1StT74Q89iGX0LCYwmC9l49Mf3L8TsWfnpyy4pDf59x9fDlBfn5u8r1 IU2Z1BqqHJ0GRUd35AvY2WJ2hpCjYzNVHCbL3oruP+D/jcfUjWdv84z/SkleciE1fPgbjsnLi4qK Kqt1VqJly5bZ2dlk3hFkZDKpgW6j7BUUYAdhzJgxXl5edFvxOn799ddr166ZplsU02B7BGwnMy/g 9b8bFNkw20mZPn2+8z/fNf9WyfO8Zg/8M/rBt8pyA3rQX6ow/M+4p7qLaiV15URkxO3D/9yf/svu Prsmj1x09Pb9JBabGxn+5PS5v39fvALqdAI2lhgViE31Gb0KpVKZmJgoEomkUikJvoECXGYwOzkI n376acOGDem24nUcPHgwJiaG5FsyENo0AYPLZXl6iiQSmbsBP4nEWSRyMmZshnGykuHVON//meSY bRjyvumtcXax4VOyx/hFptlXYJduxYoVX3/9lekk5geUOP4/O8kZyOU4HChxSlt1qJg6xouTQoVm xYqyCLBni35Dayz6fe03gevmGZtM7u/ZuWfBzPkquEmDEnhUcTeM6Yu/d7JTu7/0emajNhOaVHMv s8UsDx+2XMpxl3NdnHhCPo/PZdlb9evChQtOMplUIpFIpfAAc7kcFrO0PeLs209efwCor202XBUD BDg+Pp6EzySBROi2yI7BtEOsR2xsLEivVqslQ6BZRmC/VMpr3NgHqFu3bq1atTw8PCB7V0RYO7j0 xo3ZzZr5WvzMNFJ2FWM6b3r4eMr1q8k5uhbtWpz9c3f9Tr0+HzXi/JVwBte1Q+cWQiZzJUWFtH/3 fzPG81yC2zQIKo9gchu24letKgoJkdSsKXVxASWzu1F4Szt0aBjUsE6dOvCgenp6Orm4CASCUn5X sHFjRZpmPQoLCyMjI4uKirhGoCKCSzuXGRRgxHpAvnVzc4NilyxeBlmXbosQdp1GLeoYt7r1HWD4 Iwns2TPQ/AgXb98unTpb37JKiL00QScnJ0PmdXV1lclkdrR4og2CAoxYj6SkJChi5HI5WfTULhrc Kjl6nUKLv5K1sAsBhmxbZMR8fUmkbKAAI9ajoKAApFelUmG+tRfW77uk5srotgKxIUCASZQ9Ow1e bVOgACPWA6SX5FvMuvaCq7c/3SYgtoVpXWeSizEjlwccPo5YD/1/odscBEEQOkEBRhAEQRAaQAFG EARxfHIy09KzC0xvNSpFcnoGjfYgFAowgiCInVO0+MPQ5q1+0LyiV0dXEN2miq/Mxd3dw+NRukGD N3zzhatM6uXm6vvFfuwKohEU4MqIIiNm+LDRkVlKug1BEKTcaFWXt9++c2eXSvtyMb25b8356IQe Ixf8uXd/FbkACoBdO35judXYsOXAiZmd7CwamWOBAlwZSX58ecvmLTG5ZRPgwkWzp116kkbe6DXK OTOmHb7x1ILmIQjyFrCcfr5zYtnaJTzj6hYFmQlH//zzyLFT8Zn58DYzJeHw0bsUJX9/YAuxsztb XxRx9/ydhwXVazbzcxd6Oovptr5Sg9OQKh16vb4gL1df5spXwaP/fbsk37Nd06pdmQyGqjDnu8VL GhSGdGtQxe5C+yKIQ6DZsnD4N4cL+vdKZ6beaN+ua3hMDuxl80Th0RED6vrfT4fsrh/RtRNHKFna Qzphd6KOohJOru9ycv2Hmx9s+agG3fZXXlCAKxHZcXdH931/7630ql6ZOkpAMRkxt/75fskPB3Ye SRV7H73+oFOQ4OyWxYMm/NLqvUEzp00MDfLSqQsO/bbm+M3I0Lb9hr3fZseEViNX/6vR678f/+6S CUGLFvSePmuZVqe//tMw/i8jfj5yd3RnzMw0kJWVFR0dTbcVryM/P18qldr14lc2DMtZ4qfV3ler daM//fxmdN7ybYdOfdjjgEL5NIu5YNnGJd+MvpZT7co/e10kzi7qiDzx5zM3/Nvn6w3/G9M2ILgK 3cZXalCAKw8ZdWvWiy809BI9jKMoIa+KE6dr8+6PEoxLmmbHHrgSHfjvuvZDl+n11K5ffzh+7mrG 7cMCoZNGqzUcsHrV3p3r+8lzNRrDW51Oq9Pl5Ko15FO93rC+vUKlovH2KjMTJ06Mi4uLioqKiIh4 +vRpdnY2CfZpmmx9+/bt1yg0h8Pp2LFjKVe/ALG/cOHCS8OIgr6GhYV5enqW3C82IhAIeDwek6wq hVgMhtzNmWzlJCdSlPbLD3vAdrPxy7vWcOPUHPLXsd8eXWfUrx5sXPsibOKsWTM39Kldv14Qqi/d oABXFiK2zwT13Xs+sndz/3Xf9B299CKl1xo8EpHzR4OnfDf7AyeJpK7PKr1v35h726RFGUnZ+uzo K6Cvfaf+35qvBn7Wu8WVqC2Hd9/7eE1WkKtri/HLt3wzjsWg5kyaK5C4aEInFF75QcDGUpUeWCwW yCconExmWNIRRE6pVGqNdaOYmJi///67qKjopV9ks9lt2rSpWrVq6RXR29sbjj937lxkZGSxj0Dv r1696uPj07VrV3M5h8cMpBdsc3Jygg1cQdbiOAdVUav/Ti9U6DWGitH0VbvHvteBnR39ODarToBh TcmsrEIl1LrNvhITn02TscgLUIArCfroxxHwJ7iGD5PFlnsGUNRFKLf/3L5u6mfTt62ZfuzPrVsO b8pUqeYvm+kn4TMkPjJ36v7xDfCVsUMGuLl7entKlRE6KEpZbK5hDXgWg2X4Q7HYLMN6eAwOi4VF Kj2QZVlB2EDe3NzcQAVB6lQqVWJi4v79+8EtftUXmzdv3q5dO/hWGS5arVq1O3fu7Ny5k8i8OQkJ CXv37u3Zs2edOnVMFvL5fKgfgHlSqRQEmGVcabkM10VeCl9GfkRGtwZV/76fsv/XJWc3zL947Xbz OUcuznuHQTEpAcuU3EzK6AlLOTQZi7wABbiSwKjesBFFnZo168fJHzb+Y9dpg2rqcs7eLpq5/Ujv zcs+XrL616PRcNzJPb+9X19+/8rJq3G6CT0awp41v+zjvis6+c9t33ojmFhm2h6gZODIgrzpdDoO hyOXyzMyMkAad+/erXpFpwDI54gRI+rXr1+e68LXO3fu/OOPP969e7fYR9nZ2Vu3bu3Tp8+wYcPA JMrYyg0aDOoL5gmFQniLAmwR/jq8W+neKEDmS+n1eWrt1E3HpaFLz1+/p9GzxrXq9s30TnBMYUZa gFcV08LFmU8NdfHmtbH9mX5QgCsL/j0XDux0bMfaGQfXGt8zpWm58dO/+jhDafBgeGLnzm0bNeve cdbOX2pt/wX2BLUeNOfLte3qB+1aNXbXKkrq7r9x8UJjkcnQg8dLFSs9mTidn0ZAgMEDBj8YnMtr 165NmzYtPT39pUeC/o0ePXr48OEW0b/g4OCWLVsuX75848aNhYWF5h9BbQD84CtXrqxYsQJcYXB5 QXR5PB7IMHrAlkP189wvzuVW/+3b7pDi2QoNxZJ9NnnuZ/89aNHPW+ILRaa3Xu0/+edMo4atfa1s K1ISFODKA2f7ifDFD++m5KuDa9XIT8308/d7Gv347MUbSo6wVesOnjI+1er4hxHhF8MjPQNDWzas ymQyTl9/8u+Zo7HZ2pbtO3k6ky4k0ao1G4Oav0tOyuCIbx7aklelPQ+LU/oA6QUNTkxM/PDDD69e vfrSY0D/OnToAEoJKmjZqy9cuBCu269fv5SUlGIfJSQkvPfee6DQgwYNgusSGQZrYcOyNlRWuCO7 vffntyv7DDjH5LvVcHv5pF6PoLoe5u+ZopbtWlvFPOQNoABXIsDnCKhVN8C47SI21IilnkE93wsy P8SnaoP3qzZ48Z7JDOvYI+y/53nn/aHmXwnp+kGFmWx5HNLxgpuaPXv2smXLXtXm7OrqeuLEidDQ 0Aq6/RYtWkRFRYFvvXnz5pKffvnll7///vtff/0llUor4uqVmZ7zfzoQ6Lnm0J2Zy9YFQh0asStw 4AxSuXjp/Bm7Zs+ePb6+vosXL36p+oKv+ccff8TFxTVo0ABcT0aFIRAIwL0G/1sikZQ04/r164GB gb/99lvFp0clg8nqOWr2of07m1fByo39gQKMIPZKbGxsly5dBg4cmJCQUPJTEMXhw4dHRkbCAXy+ NXwjEPiwsLAHDx707du35Kc5OTmffPJJ//79i/UWI0ilBQUYQeyP7Ozs+fPnBwUFnTx5suREICA0 NPT48ePgcQYEBFjZNh8fn7179/78888lG5zBVPDXg4ODT58+bWWrEMQGQQFGEHsCNOzgwYMhISFz 5859qfS6urouWbLk+vXrnTt3tr55JsaOHXvz5k1wiEv2OicnJ3fs2HHKlClQjaDFNgSxEVCAEcRu SE1NbdeuXe/evV/a5sxms9u2bRsfHz958mRbGGYMDvqlS5e+/vprMhW4GD/88APIs42HsEaQCgUF GEHsAHB2Z86c6evr+88//5giPJsDH926devMmTMWn2VUHqAeAEL74MEDDw+Pkp9GRERUr1596dKl 1jcMQWwBFGAEsXUOHjwIQvXdd9+p1eqSn4LI/fTTTyBytWvXts1JVsHBwffv3x8zZkzJj+COpkyZ 0qxZs6ysLOsbhiD0ggKMILbL48ePu3fv3rt376dPn5b8FOR21KhR0dHRX3zxhVhs0yurOzs7r1y5 cv/+/SVDT4NDf+XKFahhbNq0iRbbEIQuUIARxBZRKBTg8jZo0ODo0aMvbXMODQ09fPjwr7/+6utr HzEFoboANYnIyMiePXuW9NTT09OHDx8+ZMiQVwXRRBDHAyNhITRAQjfQbYWNotFozp07N3DgwNfE c54wYcKcOXOsbJhFcHFxOXDgwPfff79o0aLc3Nxin27ZsuXMmTP79u0LCwt76dcdG3d392bNmkHd q8iIWq3WarUvrX7RiJubG5fL5XA4bDYbl3YuJyjADkJSUlJMTAzdVrwOlUpFAvFDvmWxWJhvX0pi YuKIESNOnjz50mIX0q1z587btm0DDba+bRZk2rRp4Oy+8847d+7cKfZRQkICiNCMGTNmzpxpnfgh tkOnTp1CQ0Pj4+OfPn0aFRWVkZFRWFgIFTLb0WDItiKRSCaTSaVSHo+Hq1qVExRgBwHybWZmJmRd KL+io6NhG2rQNlV9btSoEdSdQTkgA0O+xfVwSjJp0qQVK1a8Kp4zpNvdu3cDAgIcI918fHxu3LgB fnBJV16n0y1cuHDdunWXLl0KDAykwzp6IOtZkaWdXV1doaoK3vBLZ3vTBYk5CrkYLCTLStrChDf7 BQXYQQBtg5wAeZWUzlBFJVnXdgQY8qpYLIZiRSKRgGeDAmWQdyoAACAASURBVGzOiRMnxo0b9+TJ k5d+CkXeDz/88PHHH8OGlQ2rUEBgZs2a1a1bN3CFwdsr9mlycjJUK+fNmzdhwgRazLMykB0gU8BP 7OzsDNkW8khBQQFphabbtBeAkeD4QkaGEgbsBGvhR6TbKDsG085BIFmXtEyC1BUWFkLWtamFB8BC KFNAfUGDwZmDmj62QgPR0dFfffXVvn37XnXAwIEDwR2sWrWqNa2yGlCgk3AcX3zxxaZNm4rVF3Nz cydOnHjq1Klff/3V09OTLiOtBskj4FxCFpZKpSqVCtTXpnIxZaw2QeYF9xdyMZQ56AGXBxRgBwHE DGqmkHXhFbKuafiG7XjALCNgHuRbyL02K8DLly+3WqIlJCSsXLnyNYsTdO/evVmzZocOHSrnhUDe TMsWlfNUZePkyZP37t17zQHg7LZo0eLChQslP4Lbr169OrjCFW18UyM0phJZ15m4laDEOiO2k4UJ ZDln83FYdFtkx6AAOwhQZJCAfyRvkHxrUwJMBkxCjuUYIUvj0W3US4AUs2ab5w8//FDRl5DL5cOH D2c/h5aRq9u2bXvjWoS0NzVPnz49JCSEPKLwcFr/EYXLkSGKYADIsE3lXxOmmpxpdUu6LbJjUIAd BNKBBFkCsq4N1poJxfKtDWZd20y38pOUlMTj8YRGuEasrMF2kbD5+fmpqamgfKSLBLB++6opj1j5 uggtoAA7Dph1kVcRFRUFouJihDJ24+FzUpLs7Oy4uDgyBkosFhNnlG6jEEcGBRhBXmBTI04tCAiw TCbT6XRk7ia8WnPwqm02pZYkKysLBFitVpMOTvJKt1GII4MCjCAvsAudKAPR0dGurq6guyDD4Apb f2CtXSQseMDx8fHg9ZJUAmgxw/brK7bZf2SPoAA7CCtWrLDxTAuMGzfOxrOu7adh2cjIyABnLj8/ X6VS0TI/zS4StqioCJxgZ2dnpVJp/VSaOHGiNS9XNuD5Wbx4MdRRSPu8jWdn2wcF2EFo1qxZw4YN 6bbidTRt2tQ0FpeMF8OsazUUCgUUnRqNxqZis9gakD5k/h5dqbRs2TLrX/StgCyclpZGBvSR6VKY kcsDCrCDQGbZ0m3FG0hJSeHz+ZB1TUGhMetaB3DmQF1scHKaTQHJYkolm51KQC/5+fkJCQlSqdTF xYUUOJCR6TbKjkEBRqxHbGysWCyWy+XOzs5kwLbtVxocA5OWoKiUBkylV5GdnR0TE+Pm5ga1Z/CD If9CWmE1usygACPW4+nTp6Y4tyTcAQowghDsQvVzc3NBgHU6HTjBMpmssi1XZXFwLiBiPaKjoxMS Esgia7YWqrqcqNWaijy9Li83ryLPb8coCwuKlC9fPwqxOAqFIisrKz8/HzZMzfV0G2XHoAAj1iM9 PT07O7ugoIBEmXeYdtHbW6Zwua3iK0wFIs5sljoF3yp69lapUFbUlewM/YoZH7uIxEJ+wOU0jU6j PLZxzfRpX02ft/DEhQd02+aYgOiC9CqVStuMU213oAAj1gPyLRmLS3Kvab+9u8IJkfcpqkBXYWVR YX4KiA3TmEjp19bzBfyDD7Ir6mL2gybx+NRFv8mC63721djqcvaF1aPfGTFm/eY965Z+17VV7Y3h mXQb6IBAViULNNl7nrURsA8YsR5kgodpLC7d5pQXvU6bl5unopjhVw3tw3pt4flTl5q3b68sLGBy +GyGTqXWcHkCDpuZ/uhqmrhasCtfqdYJBXyoiFAMpkDAf83YFbVKqdZo2Rwel/Oin7wgJyPq4U3Y eHA/qplnFTe5rJSm7ty5s1y3agk2b95c2kP1+rz8fJFYzGQw9FpNoVItEhoWQlYpFRqtnsPjcVhM 0IGHezYWUdRve0+2ruHMZ1M1Oo+YuqjjvMmDGUlneH4dd+2+MLx+zwq8HwQpN+gBI9bDYdqcAb0y Y3igv6tc7iZ3nX3sHBUYnHFha5tOXXz9/d1d3Ty9ff18fDzc3cO69NFrVa06dK/XsKqPl5ebm7t/ gD/sd/fwPnQ59lUnP7Bhjp+Pt6enp6+f37LDt5/t1amC/f2bDP0FNqf2b+hZtUmudW7V6mQnXnV1 df3fsXDY/n3heHeP2nfzVBsmdPPx9oI08fPzPxJ+LzDAr81MwyLKfZpX9/bpkKim3Gu0nfdpo/ED GwY27A/76zSoQfNtIMibQA8YoZ+8POW1awn37ytv3NDK5RkCgYzLFTOZbJBp44xMEpzvWYi+52/1 L/0UNkwO9su+q8/KatS16+bnhxU/lVarHjCgVDb/sWLW73Hpoxes7BjE+fqzT+K4HA5LByKZkpBg +FiZmutVr0tzzonzt5N0enDUNKmZ6cYvJiYUvjdyzPEtq3eeu/puM38GeM7aZ816XB4PfL6bf67t PXIBl99o5f/1+2rMjIf/3ulCIqww2Ds3b37y6PyoKf/X4Z0ZX45tJ66g34NuhFI/lUo1b8z/Rj9d tX3VZoFP/bRdX49cfrxq64GjW/AnL9506kb60O4dvv11Kxz85cxvAv1ruhljNkfumr12T7jxHNL3 W/nTeQ8IUgpQgBH6Uam0KSkFHA4nPT2DzwcpK2SzRQxGBT2c3IyMold9ptOVdjDzg6v/eARXWz3r M9j+fd1PcXHP9jcZNOP4rBryOsN27DtSPWn3iVPTb6WQ0VnVj986tmN40A3B+N2rFwcc2n7630iN nlo/qc9nPx4g360y4IeIHZNOHNwmcA6+F3O1CufhrDEzguvUpSijqDOYbXq91ySaDQJcs9c7vXq0 KmsK2DpcieemPiHD9m9dssjreEr+oE9Hrxo9nKKqnjv8u+7abyDA7do36vlxm6qZW0fsqTN24gQf wbO2/Nqj92S/n7Jnw6KRk5dPHbX29MHxtN6H7aLXqIvUeqEAY2jQDAow8gJtXvSaTcfeGThYrnzy x5/Xewwb7idmR17e+9dd7tAR7woqeMouk8lgsRgcDpPLZXG5bBaLQ4LcGUN2GDbIOsKmVcCfvzUd YL790p2A/tGjR7Vr1zY/0rQ8Mew0CvDj0iSVUqlQKhn5ekrMoLTqF2sojZo5jcc5ChtRcenNfT0o qujyfaPr27Rn27o+O3iifOUNBpPly+FeunK3SKfv+MHY791bUBTfyYlXq2UPJpxap9aKJVXETEqp g/OqlUqK9+LCz9ruHXPRJhPMob9tnXAk9NvZSymXevMnvTttEezMlwi42TpDbUahMIwA0qrh5V5O kdoHhESv2jh3VqxLj5nj2w7+ZPTcycv1epyb9Eo+H9xp801m5qMzqMD0ggKMvCDpn03jxn+zqm6n apc2fT59+fauAwdWlfw6dtbiG1GhPbKaeZVr0v1rVvpzcRF27Vrdx8enbt26tWrV8vDwcHZ2rogQ d2DDqFH7Vq2a/KoDVCrVypWlEWBW3Tadsw+schE079+m8Og/96mqNbXGYdAanVbgHwrCm/o0VlLP G/b8+2+cQTeVcPvcoFp1D5xXgC/bWMK59OBujlJXLazL1LAu5qd2dvNQxe4bNn+1/NqsNIo6cfbP Xj2l5bxxmUzG4XD4RmDD+usBx8TEvN0XZPXqBvmeexg/YNRHVSW8Gj5yKib5+1VrT28wdIGv/XXv +z8OIwc+i8KkV51Yu3p7yg+X/xn+5NqheIrduWczy96CI+EfXCOoQIPxq2gHBRh5gU+X6U+jR/n7 eVMtlsR+ONnbTwI7v7t8YVhMQQ1PDHnzHwZ//ZOuIH/cD/sOXmY4yZz0TLbEu6pEInEWCUANjKrA kHh4CnjcG6fud5W57HOXg+Ix9CzQaBDgdh0kayIfpuap/YTFGxY+mb3y2JpTuxd/zWSxnKSSf09H qPs2k4hF5DgWR2AIps19u5+jS5cuXl5etY1ARcfNzU0stl4Psl6vHzp06Nt+a/P/fRHy/rcTvxxP Mfhz7tz4xTdk2bSJLDZbKhFn3jtEUR/dMrTct/eQGCtqTPGGx/eP+of8c2w3JO+4VQdXjHbYJvrs pPuzJ89et/OgQq0+fDW2e5hvbnrSih/mP0nhDvpsbIdavME9P/1k0/5OgUJt2vWBY1a2a+h2IdFz +y8TKJ1m/vD3gkcs9nfzfr9nI45eFxf+94z53+7bf7rAM+ze3Yu1XVARrAomN/KC6IPfhA5bfSky 6d6v0z/55WJs7CUnBuPKpq87jd918lFyCz96lke1VdhD52z6YOpaPYPF5bB0OorFYmSkp3MMjnuN 07fCXf1qspy4SQnxLLFcyB65jsFmM6ixS3b2yVCCEPdZdj3+G42L60t0lCX23JeZWVBYZJiDxNIX qnRiAS89/TOusSGa69MpNTmZL5ZY+3atjn/XyenpE7lcw/AqnsQvKzO9UKHicPlMvVqphcoMe8Kp 3bWy/GTPyzC+1DcrK1OpVFFMFs/4LcdEmd4ruM7558MYzp696xd1uPXw8TlFhhb5TZtWfLdyxc5z Jx+OnHrrr/+b1KH/nrvRsTnNrp19+tW3X9Qpuv7D1kP9Gw7XHtzxUPR4QvdA/4Ydn50o+drZu8m1 2/rSdFeVFJyGhJjQP7pxID83S8+g4jNSc1VFDGN/oyIjr0iRHx3vqHNeygODy+NDWc9ggLNq8G85 z5rNGbXqhrrJQDAZTi5uYh6byeKwmQan2MnNu3bNKrDB5IjcXJ1elf3gfOCh8nkcJpsrFvIpBlzI 1A/MEEkkrErResjgmukog8URiURQ12Fz+SLD6CFGUId+n/Vr8p80ZDB5fL4jq6+hM0OTWUSx2JzP vlsffv3GpJENF0yeXsR1OXcn+vaGsXBA2x4fTu5V5+HV42lFqVtj4gM7zd4w8UNKk7rw6307p32Y r9MP79w4Me4hg0HpdAbNprxqL//95M2bNwe38KH53iofKMDIC5Ij4uEVlCJLmUtp9STUjX9QDSjY 6DUMQRACg+d56ObJd5tUXTVjZMf+w69GxyXFZvv5hbYOCeCxDa0BQqF46Ojxqvwn7Vt1zcjTLJz/ cUi3YQNry07tGvH170+pJpOa1nJjaCkWg+nkH3ph+6Kw/Ogvh3YeMGJKYi4OW7M2KMDIC0gv4zOx LdLojENuuRIhvN6JSKDNLARBnqMuyPjnXur8DUf+WjkqI+r26SM3dYZlevWJGemHL92AAx5GptZu /25NZ+rezTs6/7AejQMolnTQl6MK8vIzmeydv47nG0t9qGDnpkZHqOtsvfv4q8Z1n4SfPHg1ieZ7 q3xgHzBiQk98XuNgXj0l4rCMWuxStZrhjwZDvyII/ShSHo8a/NHz5TiE3t51P54zYNT8nT6ubmTX rr1bP2g6dcnMEb0mbVq+eauMY8i+XXoOlo5eqnGt2r22L1SumRSHyWDE3T03bOjH5Ft8iWuAt6NG drFdUIARE8w6TVtROw6LuOxqEk+GNIMMEGKzhQYh5r3hywiCWAFJUPPsrNhdB0+o9PLufd7xkgoo akffodOOXI5s3K6L9uGpZOdGcFiPL36+2GJcWJNq5FsCr9CImHtKaXURGzKzcNfVGDXX1UXCSXva 8PDfN7huvt07dnCq6Jn+SAlQgJEXNJp4UDVez2YxA75d8+ECze+fNR21OeJJ9F8uFJV+J1JPNcGu YAShHb7Mb8iQkeZ7nIMbDA5uYNjy6VvHuIfJETZv1tD8GDf/2qZtqYsX2XCtEjqsSmjFmou8GuwD RsxhsA2jeSkGg8lmcdsMGqFXZLVr0itNp3dtVAfVF0EQxIKgACOvJLjNx5PHDJAKxX0Gz53Wqy7d 5iAIgjgU2ASNvBIGi7dk5R/f6/WGoMl0G4MgCOJgoAAjr4XBYDJQfBEEQSwPNkEjiONj5aUX7BQG 1jUR64IeMIL8h6VLl27atIluKyxJXl5esXWQrK80cMUGDRpY+aJvC4vFglRiG4Ft1GOkokEBRpAX QJl748aN+Pj4uLi4iIiIxMTEwsJClUql1+stcv64uJybN5Nho1OnIKHQSiGLw8LCpFKpTCYTi8U8 Ho8WaVm5cmVycjIkbFRUVExMTGZmZlFR0WtWqCTEGyOQCwRsFxeh+f7k5PyrVw2h2dq2DXRysswU dUgWSB+5XC6RSCCVQINRgJGKBgUYQV4AZS6UvAKBwMnJyd3dHd4qlUq1Wq3TWSYQmEKRweUaIu76 +PhJJFZaDZ1ICwgwqItQKCQabJ1Lm9sA1wUzXFxcIEnBDKjWgAC/vmZz7Nh1eA0MFDRo4G++X6fL 5nIN6wF5e/sU0+Yyw2QyRSIRpJKzszPYyeVyrZ9KSGUDBRhBXgClMJS8oL4gDFD+glqURidKj1KZ KBAYBLhmzVpyucAi53wjcFN8Ph/UBaSFuHdW7hKGegwkJogupCdl8GgF4P5qNJo3VmsEAkN0YldX 95CQkP+eMA3OARvVqtXy9rbMyoxgJKQMpBJUU6RSKaQYCjBS0aAAI8gLoBQGAQaV4nAMi9+Br6Yz YikBTk0V8PmZlEE5arq5WcZ1eyPErSd3BOJHlwcMlwbhh6uDwqnVakjSNwown38XXp2dfWrVqmW+ Pz/fic9PgY3g4OqBgTKLWEhqCfDrg510tRMglQ0UYAR5gakUJq+l8dLeCienPDbb4LG5glvnbr3Y 96B8cEdEhmnpAyZNC3BdMADkDRK2NHUaklZCoaE7wHy/TKYkH7m4QDI6W8pIUlMxgUPHS8IwQuGI cQuBAuwgDBkyBGruFjxhaRyUt+LRo0eNGjWCUpgMMbXZ0o1IBdw7SIWlHF8TQqGEzTb8TBKJ1MnJ Mm2npYEUl2T8s6kMtSakZgMGkOaEUiYsSSseT+Tk5GS+XyzONktGp5d/uax2AqaEsuCZ38hXX311 9uzZpKSkuLi4hISElJSUvLw8C44/KD+QLA0aNJBIJFDUQO6gZTi9g4EC7CBcu3YtNTU1NjY2Jibm 6dOnsK1QKErpZ7yGw4efkI0ePaqV08LGjRvLZDKpVAoOEHExbTP3EqtYRix+cii2wMuCDa4Ri5/f ljFp29t8xZBWLBanWFqBJ08+4nAcJxl9fHwgd4CvLzfi4uICAmzBEfjlB34+MlDc2dkZcjFqcPlB AXYQSO8aGWhTUFAApZJSqQQBLudpudx0suHv7//6I98IZFeoO7u6ukIpA6YapQizLoI8w3wEPmRe qP9BRrbgAMDyAxby+XzIv1A5wIHiFgEF2EEgMQSgckoZpQ6yrlqtfuM8yzciECSTjTp16pTfQihc IPeCBkPuJQ3R5TwngjgMpIMcKqk6nQ78S8gm4P5acACgRQDRhXKGzGqja065I4EC7CAQASa5AkTO UpNn+Pz7ZKN27dqvP/KNkAHGAOReMhbXZruBEcT6mCZrkRnJUJkmWdh2BJj0IHCMQGmDAlx+UIAd BFJ9pgzdY4ZWLEsN3+VwpGTDw8OjnKci5QsZXUzG4pbbOgSxKhU9hI1kCtKdZFONz+aAeaT5CtW3 /KAAOwhE3ogMW7DZCmrkZIM0bpcf5nMommYyjBgxYteuXSkpKVFRUYmJiWSci9UGmqpUgRTVBDY+ +ugjJrPQOhe1ZwbA/wsXLnTqtMR8r1rtQ1EtYWP06NEsVrZ1TIH8VaVKFfBNSaDKimi/Id3AdlE3 Rem1CCjAjgPRYMuek8l8Fq8YCh3LnpkWIInq1auXnJzs4uICjjgUprm5uSTahnW8jYwM15gYw4a/ fwCXq7TCFe2aGzcMr/AzBQUFme/PyZFFRho2fH19BQKLzQN+DaRq62QE7KnQ6dSobZUHFGCkEkGK UYFAIJPJPDw8yEBTa061ZLO5RIADAwNFIluZ32mzmAS4WrX/zIJLSOAQAfb395fJyjvSsJSAbyoW i0GAnZ2dwSSowOEgBqScoAAjlQjSxAfFKGVsDIeSlEzWslpnm1pdcPWqIRRl9erV5XLMfW9gx444 eJVKpSEh//GAWawiijJMkAsODvbystI8YHhgBEbIulI4CQcpP1gEIJULEGChUAivUICCAFs82OTr SUxMoiiDAFepUsXNjW+169otBgEGtSvmAefkpBEBDjBgpYieppDafD4fZLgM0dyio6MrxjQbApKF BOjAGB2lAQXYzoiLi3Nzcyvz1982NEdw8GKyYalBWC8FFJEUZ6bxWRUHGcNJClOtVvtWkRHLj0iU RzaMy95ZaTEGewcKdKgqme8RixVkQyp1cna2ZCjK12CKpkmiar+twAwaNCgtLS0lJSUhISEyMhIy cmZmJlnssuJstj7169d3cnIyramMjQSvBwXYzoBMm56eDlXpp0YgP5OV3SpIQiIinm107dq1Is5P ICFESIzZMhRtbwXpBoarVND5X49IlEY2pFIp3DEtNtgd8HsVq/+JRDlkQyqVVGjV8FWU4fnkcrlk ai8obmFhIWRYkUhkg6E2ygnkZVM3OZnrj37wa0ABtjOIAwcuIwkIRxmWmK3AXkyTAHt5eVXE+QlQ NsmMkLEtVlBHugoF03VJtH9abLA7Sk69Nb2lZWGJMkOCwYEMg+7Cc+7u7m7NKXDWgUwuMDbwOJM1 G+zoB7I+KMB2Bol4BXVMT09PMoyoQivR588/26hZs2ZFnJ9AlqqFm4IqhSnIe8VdDkGsD+n1gMcb sirkYhLw2cHcX8pYQIEGw22aFk1CAX4NKMD2BMnDpMEWNsAJVigUpo7MirnmPfInJCSkYs7/Ygle UrEgkywx0yKOBwlxRV7hUbfm8HurYYolAjkam6DfCAqwnWFa0pxMilCr1frnVMwFnwmwt7d3xZzf AGlXJ3UL0gSNmRZxPOA5h3xKnnCbjTRZfojoktFqmJFfDwqwnUEqmESxdEZgpxVycnmGXr8Rkl0J ZNgk5lvEIcFRwYg5KMD2BxEqK4/jJcErEARBEEuBQ10QBEEQhAZQgBEEQRCEBlCAEQRBEIQGUIAR BEEQhAZQgBEEQRCEBlCAEQRBEIQGUIARBEEQhAZwHjBSKho3Xku3CQ5Fz57b6TYBQRCaQQ8YeR1O Tjy6TUAqO0Ihh24TEKRCQA8YeR1//PH+uHFHCgsdas1wGikqUmdnGxaTd3cXsVhY/X0znp6iSZNa 0G0FglQIKMDI63BzE+7Y0Z9uKxyHgwcfz5v3N2ysW9fL21tCtzkIgtAJ1sERxHqY1pjAxSYQBEEB RhAEQRAaQAFGEARBEBpAAUYQBEEQGkABRhAEQRAaQAFGEARBEBpAAUYQBEEQGsB5wG+NXq+n2wTE XtEbMW7gg1Quniej3srJyMAJZIjlYGApUBq6dOni4+NTEXkPzmn9QgRBkDLQvXv3Xr16MZlMFovF MEK3RYh9gx5wqdBqtevXr4eMR7chCILQBhQCmZmZfCNsI6jBSHlARUEQBCkVqampcXFx6enpBQUF arUa6uV0W4TYN+gBvxlsH0YQBEhLS0tKSoICgcfjgfvL4eAyTUi5QAEuFajBCIKkpKTExsaC9Eql Uj6fLxAI6LYIsW+wCRpBEKRU5OTkZGZm5ubmKpVKtVpNb7089f7ZX1Zty9dY1Yaov/7s17ffvykq a17UgUEBRhAEKRUqlUqhUJDeX7onL+h+GfnRuM8/OnMv3ZpXvXvj/N79e6+lFlrzog4MCjCCIEip AN3VaDREfem2RZ+TZLRBZ9WrPkiPMX+rVKpoTwi7BvuAEQRBSgXdXm+pUCnyHj94otQzvAKCPJyl LONEKb1Om5+XU6hQcwVCJ4mYadypyM9+eOeBhiPwD67i4gRHqtdOGfkPu9vPnzfauu+oa/Wmfbs0 ZzMZBrFPjNi+74hG5PE0Po2iGD5Ohs7v+5un1hm6ZNnxRxO6VKf5nu0WFOAKx5Zz7KtmMVapUsXK lpSBJ0+eMMww/6hNmzZxcXF0GVZKtmzZ0qxZM8r4K5ScYp6bmxsaGkqHXW/Ha34FICgoyJaffwK5 BdiAX8He5/Xmx5ytEto9PcfQRAz34vXB/0VvG8/IetqvXqsTqUkKFUVxeD6e7/37cEvB3Y1hncZl 5RUZvsblj5ixeO34buOXblEytu5azFDoDZ71hDlnls1re+r797vM2Kt78Tu6VnHhwZ+4qEvw+uhW EoUCXFZQgC3P/fv3Z8+erdPpbLm+7Obm9tNPP7GMkHLHvOgZNmzY3LlzaTTvjcybNy87OxuM5xhh s9nmpSeo79OnT+m18I0cOHAAbsFkP/khTJ/C83P69OnAwED6DHwzzs7OcAskJAWXyzU9S6YD4C6i oqJotPCNhIeHZ2VlgeWmW7Cv8Bpy5/+MxP544EhQ389mLdM/2bt6x/nE7YeKNn/+ec/WB+KTgrp+ umhEm+8+//xW3PY7D2d9/96ErDz+t6vXRKz88rfbWbceJLLFsgCKeqzXKyj9itX/Wzjm63tPD2ZF czvP2APF2Nq9R3308aP6fZIkErsa9JfqMHHHqXo3a7ZtQs+dOwQowJYnLS1t586dkJPpNuR1+Pr6 pqSkkKkUprA+pk9tP8wemAcqC5ZLJBKxWPzSW6DRvNKQmpqamJgI6S+VSkUiEVFic7Nt/1cA4uPj IfHhJ4AfgsfjwS0Ue/Jt/BbIgwTSKxQK4YeAV9hpBxN8dbobWg38FQm5L3YqH12+EklR7uEH1l66 /YBiscdM+4qVeGLrhcQqzXvcP7aGq1VO/mq84cjEi6cz84Qy55Nr5vx9Owt2DOrVWVOQ+djwGXv5 8TujQ9NnjaFU+sLER/dBfb/cfe+TvrXhsyF9li85p5Qa8xlH4tW+t6eN/742Dg7Csjzg9dq4+lLG 4SQJCQlQV8jLy1OpVLYxruTtiI2NBQEzhSWyO/uTkpJAvZKTk3NzcxUKRbGwSvZyO+RXyMjIKCws hAcJXF7TR/ZyC+CjQ16A+hD5IcxvwWbR63UxOsMDw2CYJbKiCN7IZKm3Y9J6Dxv7b2TSqoXdMm7f h09CgruD16pRZBbl5FFUJw8JhyqiCjms83eofoOGPIzPnvRhR3IOvkg4pHVVTWFGjvEtm2kQW9fn Ms9gsannF0y7utGVyVy67V8r3bMjgh5wJQUUC8odAccMdwAAIABJREFUNzc32IbqP5PJJK2gdNv1 Fjx+/NjZ2Rl0C7wW4nsRx8Veyn2QLrAffgJIf3AiwXi4C5M/YS93Ab+Ci4sLiBa48uQW6LborXn4 8CH8EB4eHuSH4Bmh26g3YOjcMtTYGlLK9Pt30h6GX/1x2dJqvacwuVR2NvXTkUM9q7vcPreh7adz zpzYAKX848j9sfHvbJzYL61ATbWs7yoyuvgK/okrx4Ll7NNb5zVbevavU8tgH4fdX8Rjcz3rBFFU dHwuTyiDnbO7Vws5fUGccWvxnnDwsCMLqHoiqiA5PpOiblwMpz5sTG9q2C8owJUUjUYDAgyvIpFI JpNBuWMvJb6JuLg48FfAftAwiURiF46LOSkpKeB4QbK7urrCjYjFYrotKgvwK0BlDoyHXwE8YLt7 iihjTQjSH2qf5IeAZ4lui0qHoa52o4Gvr+n9LUbKovfenbjryPjuzYwNzRRPIJJU6zOsa+31x08G +AUZ9zFZCpVL4w+//3T9rLWnOzaqSb7MF7Vy8/SADY1uf5HmV67AM9CPOh2Z4Nqyx//6Syftye3b oeXzC+lIW01gr0lHdlWr1vpda92wA4ICXEkBucrOzgbpLSoqggLU7tQLyM/PB/WFQh+qEfZoP6R8 QUEBlPhEt4rdgr0oGfwKcBdKpbJkbAp7uYW8vDyhUEgibJT8IWwTJov7/fgPPpqxyt09sFXnLh3b d2zfvmmgr6+AQ/X79sn5i5d1XL6rd9UG9eq4SAWr/7w64szRi3di69QP/Kj3B7WahYCDP3nlsUET 7509f5El4PpWCwsNqeEkYB/Zvq7QpYmUy6Qo0dCJ89sx/EUUZ+LOzD53r52+dIsrcWvcoEZyYk6I kFjBf6f/QHrTwd5BAa6kQEEDJQ6Um0S97KWsNAeMN6mvPdoPxpNb0Bqxi3K/JCQoIwkOZac/BPkV yA9hN7fAYH44fSX8K/mJV1DNAUE1zXboUlMzarfq0ayDbvnnnfOK1I1CDJ4uk8Xxr1l/SM365t99 54ORpgsMmzj7+SYrqG4z+Efe1TY/N1I+UIArKVDKmGL62EeJUwJSVhLdssdb0Bmx3/QnOMBdmOpw dn0XryLz+hafxsPMdriO6N6GNmuQ/4ICXHlxmLLGYW4EQSyOrHaXWeM/uh9XCLlEJHOeNP/HUD8p 3UYhz0ABRhAEcViYAs8Fy7eU6lCdjioRkc066DUaBrsyihHOA0aQl5CTmUK3CW9NQW6ehc6kS45P wGYF+0Wfk5z7+/rCs+fUqdml/Irm+tbUTm00Vl1mUK9NS6X0lD7tQlqXwIIryRV0GV12ts0+yyjA No0qP0eNBaHVyYm8LHPxHLDhPt2GvAX3/lwmdgoOL7DAqdIeX/byq34qLtcC5yofmrTrAQEBc3eE 022InaH48zvFxrn58z7M+iAkrW9DxaM3a5v2CTztBXpLDgTU58/onD7m21eVX5rruzIGNsy7m0Qp Mo0WaF9xYLnQ3t6V/l5I7vpzFXHy8oMCbLuoMqN5EpnL4A12OTrWnhHKDDNBH0bH21Hdp0iRD0We RQKpaFSGIEhsG7h5RU56bGzszTRLefaVBp2G4no4LdstHjZEn5OaO6WPMq3oNYcbonpk5pveaiKv KCPKu5aJXqVT3U/QPT6hLVS/9ABWzfaSST8KAp2pV/gYuoIcbWF5XXJW9Q7SGT8JO4dQOrW2wHg2 jaac57QglbHZvQzodLqS69VUNByx65yZUxmNGr4s1qo+v+D/27sKuKiWLn63e5elu0tKQUJEFCxE FLu7O57Pzs/uZ3e3YqAozw5ELBBEEKS7G3bZ3v3m7oUVkPeeisqC96+/5d65c2fPmZk9/zmTAjqN LJNIMMq9fVVxWszfL6I1dbQhsaCigqNp3NbbTQnXMchy4t49DYtMyc3Tt3Yb42MMgtoZqD29cz0h q8J30BBjTZiSC1Lev4xOZajpuLk60/H8ncvWcHuO91flVvCJ7u7tSc1SDlLOpf1HP5VKy2PvQ7WH w3JLc1+FR0EkTbeOznSCLOTRo7Yd3D+9DU3M4/kO7FsY/UrNtkNxXNj7pCwXb39rfbZUzA958LhK DJnbO9qY6DaHGo2DrON45XJgz/4ekFQS9fJpxIvwXIHQsftwfw8riZB7/sQOIcW6q4+PmY5Kc0uq hCAT2nYgtXXDYqWVpy4I7kSQJnQU3DvMCQiSCWU4CzvauJVEQ1r1yY3c6xdkIjyErYYIJhhACFJR xfKpkmIr9YcB323zJCkvSqaNhAeVocpSfzO89xzV5X/wbx+pvhcsrYII7VxpE5dCBe+5l8+xuw74 hzTEVYu7CwvJBGMDSTGPPHoVrZuTJPMd5/BOUXouRs2APHghrUtbWXUR58A6QWQMRFYhuvajTxnL 3T5aAplBJZ9EyWl4v/VMbyLnzDH6Tl/BMpfqdySCJVOUmIBrN5G9/X9YcTX3/C5h3CcIRyW49qD1 G4z55T9hlIC/Cs0yz1bErwp7GjZ79CJAwLmf3u45cPBNTJaxndu8JYsEt+e6z3o+d2bXvQdPq3QY lfLsjGrzmP//xtO7x8fN2qu47T9nubfbxmaUp1Hkxd7Vt/ervXPwSDsD/pyb6nxOfq937V3G4/3v b+5wHrAYiaHnNODjswN3du4K2bnrf/IQn8n7go/N/sVlIBGW92TrPKnm19yzLUxosvdn9/nMWVxY KQABGuaOqdHBfn18FI6ER9SJsL8Uaz2h7mNnBe9bObqn09U3eUjI2tPPp7T/lUr8Gwojbw8bPjkw uUo9dJnnhP1IoMXbfN+A9VP7Opx+WiPz/U/lPa1YzSemUgIjFiXFyXISqu8+gm/pFPGHOxXbNmOM XLHcJFFIHBdvgOnM4Fw8hW3ThaRLF4TckREZOJgQ8JQu/cRYe0wTPA4MS4fs7S8K/1tSKSR07Ets ayu4s61y90FIw4GgyhUEH8ea+ZPVUqX5aZD0H02rTCCUleQJJRgML4O70Z9gFspZMlzMIRLt7ITh T7kfc8gPHvP2zuI9fk9w6SQKf8TPiCB17yWODBWVhGJUbSFusehhuNiIKs2JkfKEkoJi0D4VfarE W5qJIy8JC+bw13gKkyrxTj1l6RHVb4Mxjr40E9r36/xdQLuglReCisLHL1/EF1UJyj50aeO268SN goKsMwc2e00/m5uTAUGZew9eMDEzLn99LSRTefvoBk3ZnpIQFxUdpk0CVkB93NgZzS1RI8hO/QA+ Z+4+X5j5YdPOJRp8+fAnBuu78MSfXd1yYpKLSxMB+5IoajeCrhhCUE5MWjG3IgTezUBj1a6jPV0s 7h/f9rH8V48VJP29CbDv/048FFSXDWvPhOez8Eo9p/1ZjlO7+iJ2bl97LA5HlEnh3fNpGtsCrtrB 3XoC5N1VhwN6ORuIJNIn17dffZM/e+uFxQ7wcTcJ75Xo9MDUxGfgE4eVxL4IBReHb7+Me3ptwaSR YVf2nX5W2G/P/dKc2MG9xhprkJtZUCWEILdiWs/KdXPE5QU49xmMIc6C4P3wnhp6VElFGUSg442d hM8vQSSa6vbTzBWHyZ0ca/pPIAx1+mrGlEFNOeQIq27GXLGPJOcz2txdtN7unF0HIZq++rnbdP9e IJDg1kZang7BVfOfCFgi45ZjdB00bjxX2wEfjcq/sENcxMOQVIXhYfBXWPbASDN5D15CdFVZ+gNI IsWoGWLlhzNi1JzUAu4QzK1xprrSnEy5TjV7rJNXB9B9ekAQV/j6vjCpCtt9t+qOk1Qfd1DLMM0x AxwlYOVFVUUucrF/wJRkCFoXEB7x+Ba4Xbq0H2JvvEdNeRsEnDTBp/yvnev464ElEE0tzW+O9sgX QHtOPuzvrP/f7/xytPWeCD4Pzh+taeig0a4t4sgymBNvbpuoR6NCRaDBkwNCBLySgf7DwA96R+AJ UwbVAsQZunPt/CmH146HoKz8yn8bZvsZSH4Nn4g+aag3kaLi1L0nLGFlnJAv3no2eLCHLYVEZDBq mGnX5QeLhgy+Ev7q+gZ4595OS+6tnTbk4OnAE1s3Zrx7A4zg/iWjtn2I0+8yYteWsb9Yi3+BlANb ZzyONGLtIXAxvW9HG++V7V1srx1Zx9LUvTm3J1vX9urdM5aqyn52QjOAWktsfAhv44SBJJL8Qni9 z8tnWPvhalejGaM6SQqLISwGwstZAKdoxEgrRnUo6jFO8oPakzL4H5wWlorBEGo7iXDyLxVLZf/o AZNwBmYYKhkQJ4ahCotVBs/VkpWnQWQW43Ck+uFlmMJE+OWKbHEhiTTjsnrAS4IaTMB4Cw8slqBy 6L7alikI72IgnkhOxLQOtpIC2K5Kq4rBV9Cn9QbXolQQokHQovyDJD8RKAErL5CqQ8MTpHAHOHmg txUSTsDh46PgXscFqzdXlWUgIc0m5X9Ddm3jhLUxkO/8vdMHtW1uYRoHkaEpFnJjIp63NVWf4jcu Uwj/rvtsnksE1gkuh5Ts0moQQiBTbjx9XVpZ3Y1dXSAgmoOgvDIQNezCSziVnzKL899AZ8LEE5kO z3EtzyuSywCfToeTwaJIJRw+v2a+CV1eQ2ycO2hSYAvIUIE38zWxbW+mpyLmwXNk+v7x18eUrJhL m1M/xP5qNf4LUqmEpefOqyx6EXxWG/o0ZvoimZiIw9b0FqYmJvN+ec63AIiN1O4nsbccwBAgwYkp ZVs34Q3hCovtOIna17NyxYCSBQuJLp0gHqds2uTK7bP5Ye9qSBFC+kzSf2R9lg+uSiv5/LhY7p2H 4Fr0PBoOx/2H3ynNTKu8eLp02VoIplVbOCW2Pm3hXtHVxcXDOgi5evKXVckzduOlEaWj3DmPQhtN RyaWyHneFUvE4m0c4JThZYZ8zvpdnEPzBG8iIKYhrjm6UVACVnZwxSICzAGE8zfv3wu6BkL2HXxQ AnsG7R2Nmao6liDk9dumTln8ebixa/qQlRfAxd3rO53aOe048aC5JWoEQRsHqOtbTP9jZWYxF+ID kwA32BF/1rWPCbjMl+r76UASoWDtwjkd25o6enieewv/giuf/2FvZzvlQrCO87COBtRfLHb7cVvI BGw/e1sLE73NZ0OgagGXZkki4eeO8fdwd94emJCdEBOczW/kzc9eB6Zjv+Hgz9vAQ+OG+huaWQxb tEUJpj/XQCJvCUnF5b3YRBMHz2VbDlYAQ4yn9BkzszTvk5mDs6OtsZmVxaabStdoaF5giCyIgMcQ KATXfmrnnhGszCT52ZTJu4m2ttKXJzibZok+fsA7epEGriV3cpRkPODfvSnjCwEZy/d1xakcvMU+ fhlHaLIc8kOEMcDJxqqwtu+EBEVVc3oJ4xNBoPBjIIamCVM+BjyFW4eN1zphEf/4SkleEbHfetqU JfQxE2Rl2dwN4/iPH0H6nnh9C9b2AxhiKf/ADO6RHRIuk2BmKeODpD7PncaqwieuYmksAuxFw6v0 8AaG8hBzap+u0g+Hqq9el4mltY2PXw1l9px+dxAIcBufRSGOObP9QKf+60f3QsIzL0xSHe0GhXKB Y0xmwrvKXQ+Lks53V8rGlLSitNCjm4+FkSGFiMnLzmapKONZb+37zRmefia3sNxv8PhBo2dbGrKW Llo0akQb8Mjeb/KAPqUmxiZX47I2bd2Vk1+KJ7vO9+w1sYfBU/D70W5vZ2fs7N51yZp1dHxTRs2+ Bww954TXd3YcvVEtwQ3WUueLKBoszY8vrm/ad6lUiF/c1ScrJoaCp3l38bYwqJknjCVQRvTu4dhe XyGrY985L29rXbj9hCuUenbrNW7mn0xS8ZSJY4xYzd+v267/tAX5uk66mmtO7Tx6JbS0WjB69oLZ f6601yMFYMjnH8bgqDaj5/ed0d+uuSVVLpCHriP6CxGDgNU0Zx98BneoYSCVffckBbkyoQSrpoWl wuXLXHeLlpctw5Bw6mwZT4i4o8DLJLCbLgWGvuYxIYNLVIV5GN9+mEagtyinCKdnAlVlSyE1gi5L zXkyjkKA9HurXnyH09JqJAkDO9aKXRCBRZRPzqdOWE8ZtkBSUglRGXhVVaARrn0/9ds+kvwCCE/C gxSwGNxfQRDbUpECsd9K9a4LsAwa6VSkWEiGZ5aZeKvsuI6zao+j9iIPTpbh6JzV/cQU7WaxnygB Ky/UrTxLCvLYGtoYjO6nhJTI9zFEdUMbQ3rws6xenga+q7n64BdEMo34O4js4KWU7AuAnbA+cEJz C/Gf0LPreuhY17ohm7dtQy6oeh1u3L4hv2St37zzcwwJPCJF9Zh1+fK4X028dWDo5Lv3sG/dELqz /+Ez/nVDej18orjGENkXg+t3QmDw7n1Ggv91gtSOnjj8E4T9ZrAtOu/cCZ8coNd/jnv/OXUfDZm3 eci8ZhJL+YEnYOl1HFiMooZicFp69aNicDoGNVeMpvu89UHVJLWp800sTSJLE75iWSJDwThmTXMc r90I+8KvkChEyzb1QqhsPLVe6wBDIOMNjBS3eAun+mlgsQz4pG0MQ7NWPRLRyU2S/Kp48068vbM0 7qI4rZQ4uHnacCgBKzMwqprayBWOxnbxqDnDpL+vOvi0tVCX3xHa+/ZtHul+e8Djq1KRrHa0HgUK FD8QWDoFI9X8WamLqzHiQvHrmxCOhfccyZw+/Wd90b8CJWAUKL4LOPbq64crLPoqa98DChQtG/TV wfSfljjOupvamW4/LfmvBWo9UKD4PmA6DZzmZ9941xkKFM0IqYB35XjIgmm3/vjj7tvECiQwNuzd sFGBZdVKOmU8533y0KE30hrbelLC4wtEUn5B+rBhV59mNDap8FdBJpGUlQl+YIIoAaNAgQJFq0LK 69TthxOevysIDc2aOfLKisMfQWBFUWl6WrlEojyT3OuhspiTmlrGk6+b4+VmLFv26FMxvEBOwud1 7Xnea/LzyrzylJSywOc/69Ckr8Gtg3d69rn0A5sAKAGjQIECRasCMpl5/J6B18/5WGuT7x9/E1cl lUm/bWcNTln5x8TiJkoiruaWVn3dgQryloFccFl2eNLDh6lhsZUSmQxLIEwY6zC2nxFTE17mxyQT /z2VgoLv3BaQz+E1fmpEHdh52owaafcDB27RMWAUKFCgaIUgMajaRlRDFdKnfCFf8NnxXT/mUrKx 6Zn1bqnv4yb9GX7hxkgNPP/8sTf3XhWqabJ6D3Ts7aWLxUAn9j0/F8T5+81IzSZscb5m1p2n1ZTB NtjbL8rGTXUICfzIIVDXbfAhZaaOWPou4PFYI6JszugL+n3d/eUL5WRi4eAu59K5cD/5oYXXj7MZ T4IHRoSmdJxmhIHgvvSyT6njBj9KL5Iu2d2vtyObU1p56czbNwmVpm1N5050yHnwetTaT+Ontwk+ /8nSx16tJCc6mdN3iud4PyOxkB94OizwSQFTk9lrQNt+3gZ1505KuaV9va5J3Ew70qsrpeTpczrZ GFKryypvXo28G5qvYaw1fJSjq7VKTkJWbJoMD0lXLbhp7maZ8OJTVCp/zKreIzuofl/+oASMAgUK FK0QRyaePyK/0Ha2bKeOe1kbnlhRXVoGe6W5SVlVVeJqgWTG7NvvE6rV2MSUlJyIdwVu98ZqMPH2 2mra1nh60w4YKRCLhCkVF1Pg6/1b31DoRCGXc+x2ig+1TMITVYkhiCjMyKzGl/KgmpXqGLYWvbqC V1gipNBI6lo0iUD0IZmjmltdIoE33H1zKw5PIWL4wtUrI7oHdV4z/XJIGobFIkRHvM3GUkZh+MAJ Pn0Y3pil6HoUhMMRsNL9uyKG9ta/PO/iwXCxmjolNTk34mWh/YuJZnW3vpJB4C7vTWoIjSDgiV5+ FDy73nlujysfMBgNLVpiQlJYFPf5nT6pUbnJscBLF0a8Lb77vJgK1OEIL55O+W4CRrugUaBAgaI1 Iz8i8WxYSZ0AjLGJfH4xDj7oTcLPSYznUCxUDUjw4CYOhyEQYV7oOtXjzvneP2R3t74TOg4yglga Kk+ejLfSwycnVcH7T1NJpvLUwaW4dmYYBk84FjDs5lF4La/fFM/A8/6QgF9v3JrFCAkd04FOgAoK 455FhaRCLgOdHz8YbU3Hvz0WUSIfQta11bv0lwW4OHtz5LSe+lB5VUpiHmBfCCJIJfLTgElUlfob T0r4vDwIUtMyDA2ZMNeRDRXm7doe8QGCrEZ53b0zUk8V19HPmASJUz5Vf35HV/fek0HwOlHK9zdS UAJGgQIFilaI6cdGv3496faFzkQICrkZU/dRbnYtkWAwgpx8QLy8hOL3RfiJf3a5c3eMChnmhbDT rwcPuV3Q9CMZ1DQXzmgjhp1MqQySERnE3E8l8D6vPGFW7fElDRisho7rjB2TcVj5DtVQ73EeJJmM Lx8vzoiFt5b0G2oLtFCvsxp/ysquWLnYEpHMQg9oL4xK58qfiMrKRCNndwwOHqBW/xsJLIYR+LSE g41s4T3C5KdEYGaPs6iREAunj69DmRPG2lCxjIDQ8YE7G2z98Q1ACRgFChQoWiFCz71av+bx4uVv hfDJ0J/Xy+HJuIK4nMBb0cEPYbeYqq8nP9eCsnKDpyGuYvX8oIhcmBizCqvS04ormr7oRorBY7FG 1hShUCyRQKYkMlRUKsCTIJnk4rn3l85GlAqRwxr+DXyJFCunWDKLDGGwNjrgsoppCgt+cW9o8PXw Vzyxhpu5inxMFU/A0rQ1Abflc0RGFrCvn5leM3N5xdauNnT+xmV3z72uf4IcFgNerYrPePIk7shN kC14NhmWKehKTHxYbEmVNDI0D2kPKBokiDxECpHQBBZFx4BRoECBolUB6UP++DzlI/A/dZkTFrhO HWkdHpiFnL47oIPmuotZG9e/gaNisVKS9rQpZodOpWxY8hQE4NUYC0gw9/Sb5KzpbmnatDP6GFic /JwDDJ2Ek0gkwK20MyTceM+nWmhqQbLgo2+D5dGk9Q9jwMJbNoMQmOFwWBwGA1GJ8HAuuNXWAwJh vX1YZ5KKsRZWY9xyzoWlrIEPCCZvX9FW9AxWCo/DEsgEDOxjS9VMWSCkqAi7ZaLFytPJG5fA27Iy NBiDNRvZ6pxbXLp48Qtw0Xd2lyl92B8iMx4ef/UQefYpNbrAk87EYeUtEpkEkv7jScbfAJSAf1/g cKBm16DBo6ioKD8/Py6XW11dzeFw+Hy+WCyWfuMyhp+Nbt26EQgEPB4PFMHWP9QMPOrduzcQniuH cspvZ2dHJBIV8jcoBaDa3Llzq+UARQA+RSIRUEEmU6J1nFQqFaiAlAKiQgMtHBwcfH19ERVAQQgE AmCFla0gPDw8kILAytHc4vwAGLpaXj5NE2AI6loq6qpkpPvUxdfrjC1HjY7v+0cv54H5mSVCTSbh 4dNsQzbJcmrXvsPdMrMrCDSKqSEbK49PUWN39WzqmQyb9vQuFxMB19n0tPPgleDxmG5THLO1Sjq3 N+4WOvp9TD5DXSX5bYqBm6GNAeWyia6ZfFSYZNBm12asTSd4h2eKqsrtW0Npaiwi3vDJI1sGC24R 2I3z22yQ5WbB7rx/gG9cVlmZwMrFXIWEhYZ1vO7hYGRA4FfpdvLQN1EjUQxMF00tsfIzb6dn32W8 a3J6OZ5CNtBXlRN0Q7CtTDbOM6FrarUxYoCKfPjcyI/v0/lkRjsb1bBn2XYapLZHRk0QAdLEL17d wcb9BxxtjlGq37NyAmSRl5dXSEjIV8Z/9erV8OHDgaER10LZ7CYAnU4fMWKEkZFRmzZtzMzMVFVV GQwGsEHIU2AoS0pKMjIyMjMzk5OT8/PzFQTQvGIrAIy+ioqKhoaGubm5paWllpYWuKVQ4B8nyGog f2lpKZA/LS0tNTW1sLAQEACQX6lKgUajAfl1dHRAEYCCUFNTYzKZCgIA9aeqqipLDlAE4LOiogIh sOYVuy6QUgCZbyGHuro6qEhkcs38FlBbQNOnuLg4PT09TY6ioiJQkcAvQnkKArQYwG9BU1PTwMDA yspKX18fKYhGI3ft2tXJycnW1tbe3l5bWxvERKocihYPSdUwt0tcF8c7h1x+5deiHvCPh5ubW0xM DCAtwF7AboLPyspKYP2Vx3QCowMMB5vNBtYT0AAwo4g3XDcCIGNgSYElAiYVmEtgN5XKdwHiIbKB TyBnA/kBjYEQoCN4ClgByA+aF8pGwIoiQPzIBr4XUAeEANVAAYFoPB4PxAcErDxFANUpBcBhJBIJ VKQGtQioAOIABVksFigIcIv0RihPQQAhgXggh4GEIIe/LAgUvwWksipgNzi/2kSjBPzjAX7SwPoD 0wlsq1AoBLdcLlep3EcAhFyBTVQQWN2n4BbYU2CVkGvgHwBFkAaEMphOxLIDcwnsPlABfIJrhQpI RyiS/yDPgUkF8it8R2WQHwHIYUCuIP+BIwU44Ev2AiEgAhAe3IJoCupSHhWQVg5o3ABXHnwCjepW JEUxIW048BR4jUhLVHlUAEICwUAVArUFyAmkVfQDofiNQGAGPBolI5P/O+YPBVrVfjzATxoYfWCP EKMDftiI46I8BIw4uAiBIT23wNbXbfiDayA58AlAOOAGhL2Ux4OH5BIC2ZB8Rpz4uvID7cAjQFrg AjwF1IUYfeWx+1CtkKChAFRA7P6XnRCggAClgWiApJVwDBgpBYTAAL50H4EKSEUCF0BNpCIpYUEA IUE9ByqA4mgFBCwVch/duRkZ9UlGVe07cqydEby6Ju7NzfX7bh05fpxJ/u91q+uWz6Nad104tl+T ZRHuXruy27Q19tq0b3rtwLblRWTz/82dqEhn26plvrPWfWs6Xw+6SlNSlnJ5Ehrlmw9UbvFVTTmB NPyRxjWwPso2DIy4JgiBId1uDTxgqNYqIdZfIb9SqQBkQ/rJFZOA6kZAWhiIK490PiuV/JC8kuDl QIz+lz2fSOYrmFjZ3F+otqsfyWRkHlODSViIHw/JdQFqKlRQKi2QioS0JBotiBaHxJDzPoNqDrhd vnzB2hN/r57om5X48vqN63sOHvkaAr597XKSj5KUAAAgAElEQVSVLaHpBCwpjtr6v+1kr3nfSpwP blyMJndUEDBIZ8eGv5jdF/w8Am4CJLs74v94pZFSkWvK/DZKRQn4pwCxrYAAwE9a2XxHBAgHI3J+ OQtX0YsODCXQAvHdlcpoItIiYn85/xYhLaACsKpAfkRypZIfqu0qVxREoxGQOcZIQSgbb0F1VGi0 FKDaggCPgCKKNqhSaYEIrCiFL1cEtEQgzenN9+P9qMkj+49eM2n6sOFpUvF/njXwGXDLSb4KSCoS pGcXmhgbgIwpK8wVEVia7G+gQGFFfj4EkbBY+CgIZHb11woAlJAvRpJK0tOz1SV5RV+RjlgohHAE PA4DKttXNqSquTwKjdK0Use2G9K/t5qUTsCKBALQGsXCY8rQ12iLEvBPAWJ3WnRflsKYfukctwgo WKG5Bfl+tPQiQIA05ppbit8RTG09GxuTvjYWsaHRJRX12Lc4J+HUwUPvs6v6DJ04oJc7GYctS38/ bODgYoLZ7GWrR/V1l8fCSEX8PYuGLdj/MKusTJ+BH93doNBiUvj1o98ghPz3t2PKiIkJIUxVnxcx l+10VUCdLi9IO3f44Kukgp4Dxw/u05lOxH0KCxw0coyGg/+qNWu82lshb8skoksbJ4xac+F6wP4G 6djrqoDn6R/Dd+8/JaOwFy5fbqBO9nPRx1lM1Ci7dzYs9fqbxAFttQWc4jN7tz94l2rR3nPujMm6 7Hp7a4rzn6rrdJ2+7xgl4yPLvMv8Kf2JWCgv4fX/Nu2pFNJ7DBk1ur/XlyEEYeacRUdHDutyfN9f uSL1ywGnyznaNt391IXxRip2fbYdjz08+UUqFJtVaqvP5lWVhD66Fx6XY2Tv3LdHJxal/mlOMhT/ BdCY6ty5c3NLgQIFimaGt7f3n3/+efLkyfDw8KysrOrq6uaWqHEkPj4MbDuFzmQxGcCpb+MzUyST /X1yPoHCKKgQFEaeIhIUvgFmxb0PMkG6E1Exfkl8kFDkYqnlNHjesvHecDoMV74Y7r2Y4OfUacS0 b5KkOvVmPb4hUD7lV5fEB5JJn4dLZ5wMzn9znoj/3FaOSK/s18HUynvoiZVD5AHWSe8DGqSTWcp/ HzBV8RaeRMurKu9gWCcOzosjFvd1/LwFGIHcvVpSTzxRXiirTmPBZs4NUdYdwudWO3bcsZgvQ6pi DtaV5eTHouHgT+dlVdmP64a7zjsnLg43oX5mXIrDcmH9/GnB/gEKFChQoPgn8DiVFZVVgDmzI2/f /VCoCB87fq1QpHU5NPlD8GEIRxrQxvD0hGmRQtGu29FCXlV4yCMPE3j5Q+S1PZtPP9WxtE/LDyPh 4J6YE0HhIecPfYcka08/E4rF8SFnCSLe86jURXPW8gUqxx/E58YEAR7uaWO7fMV2Ic06LKesuqIo JCTKXh/ePzLhacCkDVcZapqppZF6TGKDdMI+5a3d/1TItn4Yn/EqYK1MwAUhOPngxsG7Hy/N9oAk zxJvr7sdVdDBs087K3MQLtK2btAtLChKqICg0XP3pqV/6qklLbi+fJb7MJFUOnHWIF0NQM1SC1Pa FyEqyLZd3cbNjX9yGlxgJeLLUJ2tvDQsIlKznSDo7bvYqZNnpVULj/79pro8Gy4RSsNRgBbcR9py IZOPgSnhwGpdNDqk9wNRtxn4k76iiVCMDv5TPshqRzSVXwukK/6HlKai9iqtylD9Umsdw7rfgb9e Fs5sR41+dqJb73l7Nm7/s1dNeKlQwPQeNKyTWfyDpxAWQyFhTyaladmPn9nHAdChc2dPOFJtnhVl Zz2ILRzjqguuj2xblARZ7Fw6/Vsl0TU2J+BwuhZt8Xgov6K8jF9Na99lUg/rooRU8D0kiiQlI7lX /yUd4V5lqHNndfidWt+QW1kZ/C5rklnDdHLL8/KTkzp0mdbd2rAI0wEHQcLqorJSqI3vuOm9LDZt gfekzE6Gz0F8HXqHpaG/ce+JaVPGkerXBaqhPROCOvXraWxk6d7JOjy06G4hfGzDyQPX7bsN3zV/ zhBPTaPseiFDu+pz4NMOoaWLVlnbqBQW9FZlk8eD++iqirwC8Lfb8NlOeoxICN5gM7OwUrvbpMm+ rpy8JBDg0cGhwTxplIB/Kby9vdu1a9fcUvwHzMzMRo0ahcwL/Rn78928efPrtxVrLjx69AgIicwe QjYqaZAJtra2PXv2bC7xvgZRUVHXr19HprsjKjTYruQ7MGTIEH39H7AD38/DhQsX4uPjkfl3ioL7 PTk4/PapA8/5b54GcyCIaQ67ZDUPZFJi4Yf3yZlRbx5AIlF4RokejhBa/C7gWaQTufz81dtD/1hc WV7oM+N/R8bau7gPmuRl1busTI2Ef/Eo6IXQ9TsI+F7QZXPI/vzOZTwx5GCsHyWTEEqTwxMzC57e EENQbFI2FsImRN97+3GYOO/D1eC381YvL85P7TBwcvDOqXYmrnN6WDk9O90gnXaGJs8MjEPDX98N ffX45FYhBFlqEaq5kIepFwYiOHT2gUKCaVQN8JZ1x54Xj+0t/Bi2aOrkLQeOaDI+9wljyPBRghHP n9pwoq5d/4TXdfSASoA7O/nPUwvG2z8OuPrHyxgPCKobMv91wga4x1m+YTUGr6GpIRNVwfd2DGFl GfjbvksvDJ4ETMODl4nCjtj8hHcRHz8F7/gTPHJ1NmyYNd/Uof974geOAXt5ef2QdH4q1q5dGxsb m5qaWlRUxOVyhUKhYg3SD0FgYOAPTO0nwdLSMjo6OiEhIScnp7Kysu5KYgTjx49vLtm+Ert27YqM jPz48WNaWlpxcTGymWgT03z69OmPEO0nAjRwQcsDcHBmZmZZWRmPx6u79qmJaCljwEnPTigsPFtd f/CcDTyZ7O6pPwgURn6F4NL0UfVmInluSn12VKN2FSwWp3ouPK6NBmHQ4s0gqSfnl4PA3a9zwPWH 0LtXg599kyT81DuK78HiCW6eewVS2d9rFzDqCuD858XV85i1tMjSNn2dku1pRPQePQOkEP9oFw4L zds4v0E6Qqns6YYlrJq3cPauK/miwnZq0MiZR8Bbr0/NAqEv01OGuZopXtQ2tcspF9SX74Nit2si lbnm5qeyqAsGarXbcRDI3f13fRlS9QGeEfbwYwmShlRYBXvunquKYgLB33V3kmUy0VI4CLpyYO7n WV80aMmV5w3yB/WAUTRESUkJMC5sNhuuH3IPuEVP5/4+gGYHyARkIyrEcaybCTIl7n2ti4yMDGQn S2QqchNnI7cUrQH10ul0NTU1pPOm6Yq3OJh3Gf3+pSUfS9E1MtXTZiNdN92GrgtrO1ODSRx+6HyP Vf97ER5v1c5NnZ8UztczaWucmzP4yYNHUhKrs29PQBm9YjJIDFXwlvfItSku443N4fP/7Dv1sv9G SUgmfkW5eRJIlFdUrGlorasCb53tu3pn1sx5T19Emdq6GBNyQwoofd1s+8xbeO/BC4qaZe/ujlgM JigiU0aGJ0hZd5ubnOCnZWCyYsISaf10vFZsyZg2M+RVDFXbspuLBQaCLt1/STOGZWw7eOkpqVNb HePLb5IP5KYkZRazdQwsjXQb7QmZsf6Ib1s9e3dvY3WgulVm8bBPHz5UiiBTcyt1FsyfDUMkpUcO a7hbqiKvYwj0/PIcEUWDTsSEv3pl3t4UhC19c9/iA2XQYE+/YUvD3sWrkArcvEY6GTTsPfrtDCuK /0ReXh5wf3V0dJBtsMAnsLw/sBOvRdhxgUCQlJQEjDiyqyWRSKy7z2KLUAEAePCAfYH7jsgP0JTU WorWiYmJoOCA44tsD9JErVsmiG3dOzUIIlDpLo7myLWarnm/fsi1pq/8D57K7tl/iCKyupZOzRUG b2pp0RRR1HW0waeWjkHdQJa6Yf/+SH+sbl9j+A9DVX/I8OGKCCrqitnLWGNzWADKP6Tj3/dzv651 e2QBFUSm64+fWLOJh5quGfj/LxK2denc18e6TgDO2sGxfpT6ITjVqdOG1n1MYukilcy5Q4cawSx7 TrSEbhze8qGU3NHJtLsfLIyJXsPTpVACRtEQpaWlOTk5wOFTVVUFPPR7nveCeMDgk8lkamhoKNtB Dl8J4AHzeDxAQurq6shQQnNL9CsAPGBQb0HbEWiN7Ajb3BKhUFZIxGJ4s5GfVUOOXzx/N/Sj/JIy f991R32VBhFQAkbREMBh4nK5wHAjW1gjYxU/MP0WYRCB4hwOB5hvxVnCLULsBqiqqqLRaKAokSMQ mkjALSUHgNag4JDRX6Xagx2F0oHa7nV0jJFVk1z8f8GdJ5ElRcU8sZTFVmPRG/Fk0HXAKBoCGGvA Okq49f+vBNAduIwK3mqhRhw0oepq8ZuUplAOwL5KePDDL4JMFPXiaVph5be+JxVxtm5eH5Zc8PWv hNw+eyHg/dfE5JWk/7Vt84ZNWzKKed8q2E8DxsbBjkb6WY4oFk/U0NE1NNBvlH0h1ANG8SUazNNr bnGaDQrSarmZ0ApU+A4gvPsbKq5AecILJ8+uwPxPXbl16tD+bW1M8V83hYNfmrd0+WqbctvYrQO/ 7g3BgYXjUrWWjxr6H6srxZw8a3WTTPggVJZZj1FG6gZfRJHGvbhbqOLkZafTyPutFKgHjAIFChSt DPBsQQKRcGz9Qmc7s/7TtgnEX9WFQ6bDi5FkHN5XN1uqKyoVm3ZAYpFI+g8tnryk8EwIM2DNbQ6v fITLl+wLXi5d5NlnpN8q8e/UZkIJGAUKFChaIfa+zs+ICTXRUQk+tsSl9xhFeMCxbfPnLwt6EQff SCU3jm7vaWbMZrOHrjyPUJ+FNnnv6rkeHj2CIzKQV1Jf35g9ffqqTbsziuSbTkCyByfW6LHZ7du0 f5yv2ISxyIHN/nPH5S8lKc5OuHXzHrigCiI2bDtcKYZWj+85ZfstEFIRd8Wr14zQGzvY6mb3ISg/ +6w6m73/wjVntm1YKvgu8cEZfgsPhZWnvt518nZm3Ktp44aNnr1bAn+l5NyujTNnzj1+7f5PysBf ALQLGgUKFChaIWRYqYGtR2JK6txBvofuBkwKWHLIh+pu6xqZA2/YtGfPlqFbHswmHR70xw0k/tsn 14RzXMFF0OrBQfKQISOnlyX+/WbHCO8lAVIpTHo7tx+Lz49+OLb91IAP4D63vBwEUjxc5d9HlhC5 vGruF4IIZnazvpoIX13YshZ8dh/YOejMQ7ynC7TI/+bWaSH3K5K7zyqvkI9YS0UVFRUfHh99Vx73 Mauyg1bVrMN/Q528vApuL1gbugBJj/J405ZpUzzNH7zPhW8P7dvTedH7Z9twLXC7M9QDbmWQvgo8 PW3q1Flzjwhb5LShpkAacuUYrPu842J5m1xYXRX19m10XFpzC/ZtkEnEXK4AXCTcPzBtxl5OaynH W6e27T/2urml+O2Ap7B3HtkKXMmPAU/29O0B2Hfj6ftJj4+DR16dbcsL4EMa/EYviQh/c2bvFmnt yeVLjv29b/JgXnZOZkFal0VXpFKtGXOma0EQT4Tnl6ZOCfjgPHBDebUo+Qm8JxSGL38Hw4jO5uxb OfELEUi77sb/Nb8rga4en1VQWl7V0YgOPD+iqSl4hpUfT+Ay4S+RoHKuK8TWNqgWipf6dwaBWpq1 Bw+LhVJ5tI5Tt4Tc2AsuCh6tA+zrP3yyv1t7cFvGI0EtkH0hlIBbGd4G/NVx4ITjJ07cun+G93Wj Pq0GoSfXeg2fevLUqaD7p4USWeD5fbYmTCc3t3a2prrOA/Krhc0t4L9A+vby1q0XwpACO7B6tKqF kwCSxd49c/TwlWpJMwv3gyC4uHXJ9aAnzS3GbwEer6zurVRehWRSblRoOgQZzxjZk0aEt3DU0mT5 rg6YPtLnyfmtzi5+z6Pj4AMEIMjQbeXaib50EgkkVCH3cSEo/9C+wzZ+Q28/u6HBg11V/7ljWRS8 QZt6G1aQqTQCrhFO0TO1tnZwAC40W1WFzaIjXCkTfv5JCiUQnggfUYjBIsfAyEMltX3b+RXyK7sL e5Z49JmaFBPJS4gB90GXj4ek5k9fsiH6xfoWutUZSsCtCg9CnpDoZm/yuNkJL1nE36twg0JCySyb t7mcrE8vqPj8xWPmluFMt504P9ffJu/dzfD08uYW8B8hE1fvHLF06ehVVSLY/BlZt3NxdQImSMyF V4O0zJZ9PcBTkWWVxcWwLjKpkMNreCgbAi6HK/2N5t/8RFSW5YPPiqIKgUBQkp85f/oS4HAOnDxQ znjUgpLShFT4cJ63kempsYnTVxxISgwzhYoPHTqFMIJlT3dgPFQYBAhKTiqqaQDee5d0es//ckJv vMyCi2/VnCXvE1Kf3JW3qGoO+ZM+u3s7Njn/n6SSSGQipIBlBCwFqkh4l5aWklAE13ly/bFQAnxE AhT+Oio1MQG+19eS2zICAQPhCCRzM0M2Qw3cdxo2K+r9u8l+Loe37xRKWmTV+b1sdMtFWsjFzn2n VMsPMHx7atnk1eclMllB+scV86dMmbY0IrlAKhWFPrj5IjxKwOEF7Fi2JzC8RdbHxpD08ITXwDk8 ue4vj/wxc8ttqUyWmxy9bN6UaTNXvk8vlklFIfduhEfH8iuqL25buu9ONATpPE5JSk9PWTh+uKeX GwSfSddM0kuFZzYtexiVfHzzom7dPM88/HBoZi+38fvEMqg8/oazq/+TZ4FYAkN+2vhTFSJu+ppr NAK1g7sPsU4aMpkk8XXwkCFDp01b8io+pwWxlEzMD9g5j4rFWulbPimBZDjcnbU+DGrn2wdWOtm6 XroXunTKuIFDJpdUi2ScOCsWfdnJoCFebv5Ttz05tdO/T5+jt1pPNf6VwMhJc1k3YzKZrK5jdPz+ G8feQ5f0brPm/DQMJr6Njpr3uPUgwo0to2d06tbO1lzf0iMVglhsBmBJEC6Qn3Jv28kGfMbm0za5 MsGvp1d7CyNzm1mLV0RxtK/Md8XEXnK0NvOduAqOH5kMPpMuLfbu7b/l3JVGRcJKcRgCloCM0xJ1 vP3axUeeMDW12PioShFH0S7T7zjYGI/dOKWbpVNX+J6GrCb7XBfsZ243Y5NeXDlgqqft3Nln56Ej YkmL7PBDJ2G1DCRH3g69c3nJhTl/DdDtPfuvEvURPpzQ8QdOVAvhH8zxo1ufPDzU1WcGEnn79t2Q BWXmABfCv6b5T0hMLCkoSO7TR93ODr5dvPhhXp7Q3l5706ZuSAR//0vgc+PGrvb2WopbNze9FSvg kZvCQu7kyfAcjt27e5mashURfHzMZs1y/R55Xt8ICfx73fUZ/+tG856+W2gq9Ui+NOVcAE+u+9FD G8NfHPLyRXQv2rFjN3SbPbNPW0NTc0hU9sewHruvvQMPOhqrfldmNBUSXvH4FVsg8F8OLmUpMfh+ PEtVcmrO84u7I8NDkwsG1I1fLal4dffyrTjcjiWjFIHH/1o0c+Eusfz66NE9t99n9Wmr8R3CDBt2 lUCgTprk2K8fvPPt7t2vnzxJ09SkHT/uj0RASmruXLfu3eHxueXLH8fGFlpaqu3Y8X0HLwo3eRuu elEEDGdiLtwDQXexiXu6FP6i2fBg8Ejfzki8x1i3nI3MHCy0bXI/+D7k7e1j8N/bwU9ciyvaqX1f Rf59Ye49/v0Lw51bdly+H+rg1WfBHwv7dYWbofYjDyTZjL4XGqXfpr0uoTgsnTzRr83D4L9TCivM HTt193ChkqDYd291rdsCnjTrMXHvRplPd0uLgcXDEqKjYlNwFBX7do4m+prY3i+dJ0ZFxiWrG1mp kcQkbRtIJlkx5wSg6S3LZjYqUmlqIpVEZNTupr72+MPuYx5lFPNMtCUng7L0maCIMZM2XDDO1SEC kqZbvEiIfvz8JYamVfouUOjey8XQaqNOtdbnZqlmTHre+3dvMgoqtQxN2znYUYktshMaJeCWAe/J a2wXXA7evWyeYY+yauGaDQM3zR5KMOmY8ORm0tFxfdbeadNhfE5G93E9LKoMZz+5tRVPIn+30RKJ JPKT62q6nkpKqnNzebq6TEWE3Fy40SoUSurelpbW7G4jkUiREJFIWjdCRYXg++TxmbfNcvXfQQfW DSE7CCFo/7GhG/p1JVt1i3lwOXzXiBHb7pu3n5Cd0X2EtwW+3dI751YRSHAHVt67Wx5+E9MKSvX7 zw87uUWV0sxV/UVcxsGZXVMwGBLwBjq44DEQXp49+m5DJeKRu3uT/3wAZVYI9ZmyCS6TIajOTvri otPrD+B1jP83SGvNoXCJRMBifufpAvn5HBxOwuXWeBoVFXxQNHVXXSIlxavtIi4p4YEQVdXv3Ayc kxWz8kWRz9yzt3aOKo08pes2GeLXdEX0/WMH7+3J8ALW/aBjf9rYhQXcFa4fDoEmBsvmyMYBM+Zs XXUhqBfnmvvUk8mpZe3UNL9PgN8WWDyprYfv2du+Zxs8wODMHDvNcqypXS7yz0Hjp9WNYuvkUpMI UW3O8sXItWkbZ/C/bjqm9s7gf90XD0e+2YhV0/8HwzNkzWXveQIFTZJZ6j38a45e6Na7Jo6d10i7 2vh6pnZjTeV3Q/ohD5fXPx+BwmS7e/dyb/TLWg7QLuiWATzDevJs/7T45/3GrpNC2mN7mHMqBd28 ulrqqhLkjUo8jqBraKBOhISyUioV1PPWU7J4pu3o8T3iIu6NnLkdgnRGOrGqOcK+vr3MtNl4uZpY LEHPUJ9NALqXw8c3wd1c4hETJ6cVkPZeepIZuMuQ3czn4XRZfsujjeHhG6/unoM9O1lWrqIbWSTG YHF4gtwuYeDZJzKcBMLW6TEXl+ckVAj5eekrD0b0Gj7rYXiypwmzke9QPnArK8Cnx4AuJDwwzPWO ozn8vznaakyIpObUxsq/OwgI5MjbcxMX7+zpbAeUt3Pv4uDtA0LeJWU3h+wovhmqhpYW+mr/9BRP pGprNjwLCAXqAbcYDB4z5I/9QXGZkNvmeyZsKjDg2Tllufk59yJiwdPCCp46BW57iqVNnW1ka6vp 6NjG3Lzmt3TiRD8Gg1H3RNWIiKl14ze41dFh/HuE78CYiQNWn36YwIU8dgerkElA97T0wty8rCfv P4GnZdVC5DRvkaSi5gVxXm5asbajtzQvfOO6UAyFNX7KdD2VZqNhAg7+oTHYGpCkkqIKiTJevot8 F5YkX0NJbGSUs+52QniGhiFwRiGty4/uttMQ37pwuIo7bkAXuy/f+k+EhExgMj+T95o1XuB/3QgN SurIkT7f8S0K0FXgbv/V02Z0Prs++dFVOKi2XUgg4LQojIq8/HIJ3qGTH/QouKoKniFEZtGpLDKE kUR8LBns3dYAFO7HRAhyaooYKFAoLVqPn9Tqoe86YKqhGp6pGTSvK4ZkPGCs99s7e/V09HcFpYCn Z0KjIZlIwIUohFbYzDT2HD1Wn01UN3k4ryOGbNFncMfQgC16uoaH7sJrfE+9TgG6C6shGrFWdzyD QqXkfwzbsGn7nr17Nq9dcTa8uVYDy/fsUdzhmKNmD+JxX7o7O2+6GiOrnVgiqTOAhcNSkVmlyKAv RNKbt30em1wwvKuTtb3rkv2nsrI5v0z6poCm53Br41Bc8j2vDu0nrzwIQgTxWXg83AIA+lkQKVBp aZUI0mnrAELyOCIivHcElkyiYzCY+KQSiKqhrQOll3zVRv8o6kEmzUkvLuU0Ptv8396TiENDktKL v2G0KD0+Jya+4j8iyWQi+apIqVCQllz0ITo/IamUL67X9Kyu5MbG5ienlSPLJwWV3Pj4gugP+WlZ la14b0rUA25BoO2JS5yTJ9CUe7rbzzyZ82dYeGqlWxev7AcXVbq0hWTciiKapotXc8v5M8A49DFh abEUGY08eDVsYdTzqEyee5fOqbdP63Qwg6RlnFKaAbtjbXyV6PzqZhO2DnBUzYfHduv06aIIGbY2 oMPQN7HppaaG1BOX3nXQh3cbmHQwkjFZrAfvT4Df8yyLI6EDkhq1J8J+iVCDAI1buHvE7PWREdEQ ldnOzoZMbCk/W6z/8iv8WYXhsYnaZnZqRAHE0KKIB/vmS9UpOEdvbVZQJZ0AaXlNGNivyNFjXOxH D13LNhRBDovFamOhAkGqE6fMZniMbG4tWh7KkzP6jXgIYTAjF7hP6mvFpBO+chEAr7j8jz+f6gzu HLTU+uteEe+aG1xkZHbxeLd/iXRmT/Ch4KqQh8OvTL60N65m+a+KrsrN60MQ0SrTUgYOeVzbd0e+ /WTkte3PztzNQe51u9lc3exBwraCFXkN0VJ+yShgkGmqduafbw0dPAxh5wHSHzZJHkD/u7AQIpCb RbafDSpTo02doU9Tx86m8kkZumOQ+c86j4oKMUqoO4bQffK8+kFYI1t3I1v4aoe9NxLEMHCcVLtB PYVeO+uJquFQW9xEMqNDp05QCwSepenuUWcWFUG9jQn813XC4dJxEBYLLLHF9Zvw0LiaTRv5C3pF RcUY+AE0fe2+5hC5FUDOVTLZxZ0vrx4I7zas/YY5Dl/zGhluAkJVpdWyr12ALqwW/nc/qlQsRfxa grxmL1zbOe5ezN+vykaOfRB4yQcHcaaOeQbY12WwnV5u6s2X1SnZ1UVVXIjGOHjQM2DTg2eP444+ MpnTU++rJGpRQAm4VYFEoTa3CM2G31n3lgmEZL/lAYpvwdjdg9pzs9duDr935nV2TuXpLTUNuKd3 Ij6mCx07W3g4aACSfn4n8t6j/BK+zKajxewh2iCCoQ458NSLl7HcwVM6uFuzQEjux8RrD3LpGsze fWy14bkUsrfBb07dKqKSpHFcyFierKQ8c9i40JEzuw/00WogSbv2RjNNKKRaUnfsaDG8l8EntwvF 5SUSKXRqxaNkvqTbJM+tM9pAMvd5HAGdQb6HkUEUUltbfYcDg3v4Xi6qUOad7L4fKAGjQIECRSsE jU316NQ2qIPhwjn3Xj+K3//UanoH4txRgW8zYTI7fTq237wefbAfFuwqQOKncLDT+6iDi7gLyElJ 0JtkwdNb/p9uhEzekoBsdHHyXNL1Oyp7iNYAAAhnSURBVEMid95dfS1HMTJLMZSvSseIC3O4edxG hn5CgmIeFTImDrJAbs/uf8nNzE+FIFtHSzxWdP9dMc1Yb9kEy7ysosys8rIygYxGF4mldDou6kVC 4JX3PBFkrv6da+GUHCgBo0CBAkWrBZnF3rq2fZchzyKCUwKCEgH79prgNsZGNGpRpJohI/MhPH9q 8NQOfR1pCeV4Se0RLl1GuZqVZ5+8X5lXVj5hUwIEYafOsgs88KGoXFheUrbqWo6GleG5I93zQyLG r/mATBfEsUwfvZyAJ365DliSlVGNoTIU9/dvxSMXODJGWJiWUyr16cWYM+xsfI5i1hjG2ADPyaqa Pb8Ag8W4elkO6NTQq24dQLt6UKBAgaJVQVL/IBYCDV6lJ66qeBrKhyDiomltWfJ9afQMGL5Le7cx pNw4+nrcjBCIQZXJZ+WTVLTWz22nRiVCYmFpCTIjWnr0wAeZNmPGei8tAUyTPWd3VKfjLZ3rjO7L xBEvUnOKvuwrlskEEKbO0vaDV0bcutjL1ZzyISjqZWIeeEGVKioR4E1sNEb60yE6pOXlqE/F6LXT Pbjb69b9cQd3eDG+dhpZCwNKwChQoEDRqlBaDG9Lh5FipFKZSCje91cUuLXqaS3frA4jFkl41TCt pqdzJRDz8IXh9270VIXEe/96g5GP0hr0tKbiIDI861iYXFzjle4DrHltsLWsLKUUDrmwObSMJ8pK rLMASVi8anHIpeDG1/vJ6qwlIpHxXL6YSpRAGJmERANfU0nWDwwacWRLp4tBHIgDzR9lBgJVNJiu nSx12cRGE2wdQLugUaBAgaJ1Qb7E9tjMS9cYRCFfWF4p0rLRWzLAMKpIZdbx8sF9L4jkp3M+O/3s xdLiLAKOScOXQxAb3sIVfhHZVNbKFu40Ti3C+DGg4Cpo2ZTrkEjC4Un6rfaf7o4//CqnT89zEgHc +ywqkh+oQNTo4afTzvbLTddlktquZeTvlP7nkJ3g7Aa279q+nZlWdOD+5w/PvBRWw8/dJ3t1bce+ A7Xexb91gBIwChQoULQqmLiZrV0quBYQF5vGVddnTBznPKCfNRGLcZ06cKdh3Kv3RepGmho4/qdy 4ohFTvcep+WWC/UsdLt3tyCxsevXdLLqCC8UM+tkOci3oks7dZcH47yfpiSmlmPJJEtbvY4u2rg+ Y80fJCaklbG01JhEKVNfF/5WDG7p2r6NiUOY8r8u+VJ4abvfQs+q+7kEKlVbR8XcUrWNGbxzzsEj fS9f+fApo4qppdK9Z5vOztrA9x43u7OQ1jK2XG0KUAJGgQIFilYFPJXiN7g9+N8gHIPFd+nt0KX2 8APklIOp9sZ14/j2tUEuCEzVZet9kGuvnjZedSNh8V696of8K+w6WiFbp6pamM20MGvwVFVfc+af 3RsEOrk3jNYqgY4Bo0CBAgUKFM0AlIBRoECBAgWKZgBKwCgaAovF4vF4HA4HLuouHvitABQnEAiK TGih+UCQ43crSqAyWoFRtAigY8C/FOfPn4+Ojs7Pz8/Ozs7KysrNzeVwOEKhUCqV/vfLvwTAYNnZ 2amoqDAYDDKZDGzZD7di3bt3j4qKysnJAfmQnp5eUFAAMkEkEilPJgD06tWLzWYzmUz4cGUi8ctM WLRo0fPnz4EWmZmZ4LOsrIzP50skkn9K8NcDyKylpcViseh0OolEQgipiWmqqak9ePAAFFxGRgbQ uqqqCtRepdLa3NxcVVUVFByNRvtRWqNA8ZOAEvAvhY6ODiA2CoUCTAPgNmDclZCAgXgqcgDxgCfx w+0XSNbY2BjkALgA9hHQA5fLVTYCBqUDcgDwDRAPEDDIhwYEbGRkBIoSKUfQUgEELBAIgAoypTk7 DRQcICHARoCDQZkizYimJAhyABQcRQ6QIeCzsrJSqWovAKhRoFzU1dUBByOlgzrBKJQWKAH/UgBb ACwXsOnAQABLDS6A2wS4R3msNgCgE8RwAwYC119yTxMBaACYRWAlxWIxUBwYSpAJyPUP/JYmAthx kAlASA0NDYSD62YCUo6AgYCXDPw/YOhBG0LZqAgICYoPqWygKBF3sIkJAq1BtoB2CSgsoD6PxwMF p1Rag9oFBAOVChQcwsFN1BoFip8HlIB/KZCRRWATgZkAxhFYRmC/gAVXHu5BjCzgG+CeAlMLhPzh 9gvJBMBtCIdpamoi7q/yZAIkt+MkOUBhgXwAGVI3H5BcApkDmikgDqA3hfurPFoohARFCbQAWf2j CBipvUB3pM2hPCpDciFBYYFCAXIq+t6bWygUKBoHSsC/GsAcIO4UICFgI5TNakNyCQGAeMB4IV3Q P9YDVhAD8i2KJohSZQJWDkROpAu6QQTE0Ct0ASooIRUhKoByRFRo+mgCKDKQGtKHAXhdCQsOaA2E rKs12gWNQmmBEvCvBmK4EQMhq0VzC1UPmFr8vHmkiAVHMgHpwFS2TIBqCQwAcaEa5AOiAtKcAgQM KasKiBZAzh8ylxtpOCIFh8y9Uk6tkXr7o7RGgeInASXgXw2FTWxuQZoTiHFsbimaCkQLxI9vbll+ ERR89ltprQDSIEMZHcWPAkrAX4WlS5fu3bu3oKCgsLAQfFZVVSEdp80tFwoUKH4RgN9vZmZGpVKR oRmUhlE0HSgBfxU6depkaWmZkZGRmZmZlZVVVlambMsfUaBA8VMBSJcth2Jl2m/ej4Wi6UAJ+KuA w+HIZDKLxdLUhA+gBhfKtm4VBQoUPxXICmPw2wccTKFQkD1qmlsoFC0bKAH/N5CJJ1QqVUNDA7R8 wS+Qx+NJ5Whu0VCgQPGLgMwARxZ/M5lM0CJHCRhFE4FRwkmMSgjAtUKhUFALZPUFSsAoUPw+QJac gbY4spMdXg50JBhFU/B/fw4BNbQT7KYAAAAASUVORK5CYII= --Apple-Mail-18--951548461 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-18--951548461 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-18--951548461-- From lisp-bounces@ietf.org Sun Jan 25 13:06:25 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E9228C1AD; Sun, 25 Jan 2009 13:06:25 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64C228C1BC; Sun, 25 Jan 2009 13:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 zL78ioNyMKdI; Sun, 25 Jan 2009 13:06:23 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 7AA6328C1AD; Sun, 25 Jan 2009 13:06:23 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1519133qwe.31 for ; Sun, 25 Jan 2009 13:06:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.214.147.10 with SMTP id u10mr1198095qad.88.1232917564713; Sun, 25 Jan 2009 13:06:04 -0800 (PST) Date: Sun, 25 Jan 2009 15:06:04 -0600 Message-ID: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> From: Benson Schliesser To: lisp@ietf.org, routing-discussion@ietf.org, rrg@irtf.org Subject: [lisp] Economic issues of long-path / stretched routing 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org (This is a good place to segue, so pardon the borrowed thread...) I have a concern about the economic aspects of stretch, specifically related to peering in routing systems where topology follows address assignment more closely than today's Internet. If this has already been discussed I missed it and would appreciate a pointer. (I've heard discussion of the performance issues, but not economic.) My concern is not specific to LISP but is expressed nicely by LISP-ALT so I would like to use that as an example here. Referring to the graphic Dino sent, which can also be found at http://www.lisp4.net/, one can see that ALT traffic between Savvis and Level(3) has several organizational AS-hops to traverse. This isn't the case under today's BGP4 routing because the Savvis and Level(3) networks have direct peering. However, connectivity via the ASP-ARIN-RIPE path doesn't use these peering interconnects. (FYI, it seems to traverse networks such as NTT and Sprint, in case you were wondering.) In the Savvis-Level(3) case I believe the interconnects mentioned above are all settlement-free, so the economic impact is primarily the cost of usage-driven infrastructure items like router ports and interconnects. But networks farther from the default-free zone are likely to have more significant costs associated with transit connectivity "upstream". Some of these networks (i.e. "tier-2" providers) will have an existing set of settlement-free peers that exists in order to reduce transit costs. But when these providers and their downstream customers implement LISP-ALT there may very well be an increase in traffic via their transit providers. It seems to me that the driver behind this shift in traffic is the network location of address assignment "authorities" and their ALT routers. For instance, if ARIN's ALT router was only on-net behind a single service provider network then all of the ARIN-served region would need connectivity to that network. The trade/economic issues should be obvious. Therefore I'm struck that any potential longer-path solution to the address/topology scaling problem that moves beyond the scope of the RRG (i.e. to the IETF) should provide input to the addressing authorities on how to mitigate the resulting economic issues. This might include, for instance, suggestions on where ALT routers need to reside and what sort of peering/interconnectivty should be in place. Further, potential solutions should be considered for their ability to reduce long-path traffic. Again using LISP as an example it is important to consider how much traffic may follow the ALT path before it switches to the direct LISP-encapsulated path. Quantifying this may be difficult since it's in-part dependent on the latency of the ALT path. But a relative view could be given.* Has this issue already been discussed or addressed? I think that the IETF is the right place to discuss the more concrete details of any given solution (i.e. IETF LISP WG). But I would also like to see the RRG consider these issues in abstract. Cheers, -Benson * - For each new flow, given the flow's rate and size versus the long-path latency and knowledge of how long it takes for a flow to switch from the long- to short-path, as well as an estimate of the number of "unique" flows (unique within the solution's context), a relative view of traffic could be given. Comparison could then be based on historical data gleaned from end-sites such as users and datacenters to determine what the real impact may be. On Jan 25, 2009 12:02 PM, "Dino Farinacci" wrote: > Just a simple question: Is the ALT GRE-tunnel hierarchy a tree ? It is not required, but it should follow the address allocation delegation. What we have deployed on the pilot is in the enclosed diagram and the EID-prefix assignments follow a registry allocation hierarchy. This topology supports both IPv4 and IPv6. Once the apnic box is up, the container with ntt, dscott, and iij will connect to it. 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 lisp-bounces@ietf.org Sun Jan 25 13:26:28 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4B928C1E3; Sun, 25 Jan 2009 13:26:28 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D3D3A6834; Sun, 25 Jan 2009 13:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 exVljrsm1LIC; Sun, 25 Jan 2009 13:26:26 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id DFCB23A680F; Sun, 25 Jan 2009 13:26:25 -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 n0PLQ8ob012862; Sun, 25 Jan 2009 13:26:08 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0PLQ8uJ012861; Sun, 25 Jan 2009 13:26:08 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sun, 25 Jan 2009 13:26:08 -0800 From: David Meyer To: Benson Schliesser Message-ID: <20090125212608.GA12742@1-4-5.net> References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> MIME-Version: 1.0 In-Reply-To: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@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@irtf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , Content-Type: multipart/mixed; boundary="===============1792469449==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1792469449== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Referring to the graphic Dino sent, which can also be found at > http://www.lisp4.net/, one can see that ALT traffic between Savvis and > Level(3) has several organizational AS-hops to traverse.=20 This is just an artifact of the way I built it. You could put up a ALT tunnel betwen Savvis and L3 if that was of interest (and Savvis & L3 wouldn't have to further advertise those routes to the rest of the ALT). Also, its a somewhat artifcial observation because the L3 box is in London, so I thought it made sense to home it to RIPE. If L3 had ALT routers in the US, the situation would be likely different. BTW, the current configuration of the ALT is a first cut. There may be better ways to do it, but I did want to get something running so we could gain some experience. Or am I answering the wrong question? Dave =09 =09 --T4sUOijqQbZv57TR 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) iEYEARECAAYFAkl82PAACgkQORgD1qCZ2Kc6PgCfbyr8MkXCj51s2RCWAXhwsoG7 2FsAnR0BHfqV/uhuyknUiD1ccR4R8ZhO =ORNP -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- --===============1792469449== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1792469449==-- From lisp-bounces@ietf.org Sun Jan 25 13:50:12 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D13C28C1F6; Sun, 25 Jan 2009 13:50:12 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEAB528C1FE; Sun, 25 Jan 2009 13:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 GOhTbmBU-45D; Sun, 25 Jan 2009 13:50:11 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 6D7CB28C1F6; Sun, 25 Jan 2009 13:50:11 -0800 (PST) Received: by qyk4 with SMTP id 4so6183621qyk.13 for ; Sun, 25 Jan 2009 13:49:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.214.46.9 with SMTP id t9mr3105231qat.223.1232920190668; Sun, 25 Jan 2009 13:49:50 -0800 (PST) In-Reply-To: <20090125212608.GA12742@1-4-5.net> References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> Date: Sun, 25 Jan 2009 15:49:50 -0600 Message-ID: <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> From: Benson Schliesser To: David Meyer Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dave- On Sun, Jan 25, 2009 at 3:26 PM, David Meyer wrote: > This is just an artifact of the way I built it. You could > put up a ALT tunnel betwen Savvis and L3 if that was of > interest (and Savvis & L3 wouldn't have to further > advertise those routes to the rest of the ALT). Also, > ... > Or am I answering the wrong question? I think you're answering the right question from the LISP-ALT perspective. It theoretically exists for other solutions in the same class, too, i.e. solutions that create a stretched path in order to follow address-assignment topology instead of underlying forwarding topology. In the LISP-ALT case, however, I'd like to explore your answer a bit further. Does this suggest that the answer is for my ALT AS to peer with all of my existing Internet peers, if I want to avoid suboptimal forwarding? If I did so, how would my ALT routing table size compare to my current routing table size? I'm imagining them the same size (i.e. comprised of supernets learned by my peers as well as less-specifics learned when my peers' customers multihome) but I might be missing something. Cheers, -Benson _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sun Jan 25 14:23:11 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D155A3A6892; Sun, 25 Jan 2009 14:23:11 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72AA3A6892; Sun, 25 Jan 2009 14:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPPkHgCcxK4H; Sun, 25 Jan 2009 14:23:09 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C3C1C3A6808; Sun, 25 Jan 2009 14:23:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,323,1231113600"; d="scan'208";a="60932015" Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2009 22:22:52 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id n0PMMqJ7032602; Sun, 25 Jan 2009 14:22:52 -0800 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 n0PMMqfl001065; Sun, 25 Jan 2009 22:22:52 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 14:22:51 -0800 Received: from [10.0.1.4] ([10.21.64.235]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 14:22:33 -0800 In-Reply-To: <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: John Zwiebel Date: Sun, 25 Jan 2009 12:22:35 -1000 To: Benson Schliesser X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 25 Jan 2009 22:22:33.0425 (UTC) FILETIME=[6B267410:01C97F3B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1943; t=1232922172; x=1233786172; c=relaxed/simple; s=sjdkim7002; 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]=20Economic=20issues=20of=20long- path=20/=20stretched=20routing |Sender:=20; bh=1OoWw6gyVFKcUTrRqtjBVOMEXPkX2V/fwQ1tRSt371c=; b=Qs4pmJk3/IYttalKpQS9hHeSjXV8ZaVtAa4i3gPWT5ZfIeJuwdFXUrJox3 BZsGe/wPAlX+OwXw8fs859im5fsG+eCntPdZ0T9cQjrFSuCEfSoRQSE8+G6O o76WuayY/e; Authentication-Results: sj-dkim-7; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org FWIW: The sub-optimal routing will only be for the LISP map-request. The reply and all encapsulated data traffic is between RLOCs The ALT is merely there to provide the correct mapping. Also, since a map-reply from any ETR for a given site will provide you with all the RLOCs for that site, there is no need to advertise any sub-prefix into the ALT. Rather you would advertise the most highly aggregated route you have for your EID-site. So the ALT table should be considerably smaller. On Jan 25, 2009, at 11:49 AM, Benson Schliesser wrote: > Dave- > > On Sun, Jan 25, 2009 at 3:26 PM, David Meyer wrote: >> This is just an artifact of the way I built it. You could >> put up a ALT tunnel betwen Savvis and L3 if that was of >> interest (and Savvis & L3 wouldn't have to further >> advertise those routes to the rest of the ALT). Also, >> ... >> Or am I answering the wrong question? > > I think you're answering the right question from the LISP-ALT > perspective. It theoretically exists for other solutions in the same > class, too, i.e. solutions that create a stretched path in order to > follow address-assignment topology instead of underlying forwarding > topology. > > In the LISP-ALT case, however, I'd like to explore your answer a bit > further. Does this suggest that the answer is for my ALT AS to peer > with all of my existing Internet peers, if I want to avoid suboptimal > forwarding? If I did so, how would my ALT routing table size compare > to my current routing table size? I'm imagining them the same size > (i.e. comprised of supernets learned by my peers as well as > less-specifics learned when my peers' customers multihome) but I might > be missing something. > > Cheers, > -Benson > _______________________________________________ > 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 lisp-bounces@ietf.org Sun Jan 25 15:54:10 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97AAD3A68EB; Sun, 25 Jan 2009 15:54:10 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916193A67A8; Sun, 25 Jan 2009 15:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 sI84aMK7w5pT; Sun, 25 Jan 2009 15:54:08 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 3412D3A6809; Sun, 25 Jan 2009 15:54:08 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1531868qwe.31 for ; Sun, 25 Jan 2009 15:53:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.215.41.6 with SMTP id t6mr1947198qaj.338.1232927629486; Sun, 25 Jan 2009 15:53:49 -0800 (PST) In-Reply-To: References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> Date: Sun, 25 Jan 2009 17:53:49 -0600 Message-ID: <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> From: Benson Schliesser To: John Zwiebel Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , Content-Type: multipart/mixed; boundary="===============1313080856==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1313080856== Content-Type: multipart/alternative; boundary=0015175ce17263aa600461575581 --0015175ce17263aa600461575581 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit John- I agree, in LISP the volume of ALT traffic is very small versus the volume of encapsulated data traffic. This is one of the primary reasons I like LISP-ALT as a near-term solution, to be honest. The ALT peering, though, isn't 100% clear to me yet. Sorry if I'm just slow today or have forgotten something that's already been discussed. (The recent holiday seems to have effectively cleared my mind.) My single-homed xTR (savvis) has one ALT peer right now (asp) and he announces an aggregate net that covers my EID prefix. That's great from a routing scale perspective. However if I were to multihome to another net (dmm, for example) wouldn't I have to announce my EID into the ALT via that path if I wanted to continue serving that EID during an outage of my primary (asp) connectivity? At the very least it has to be announced such that my primary upstream sees it and can divert map-requests to my secondary path. So do all of my xTRs need to have ALT tunnels to all of my EID allocators in order to avoid de-aggregation in the ALT tables while maintaining fault tolerant connectivity? What happens if an AS-wide fault takes down all of my allocator's ALT routers? I understand that my RLOCs are still aggregated by the underlying network's routing regardless. It would be good to discuss what all of this looks like for network engineering purposes. For instance from the perspective of ALT traffic engineering, an end-site xTR with end users surfing the web will probably have a moderate collection of EID mappings that stay refreshed (Google, Twitter, corp intranet, etc) and a small collection of mappings that get used and expire (my blog, which nobody reads twice). This is different from an xTR in front of a public website, which will basically build a huge collection of mappings and have to worry more about the database size than anything else. Cheers, -Benson PS - I hate to say this, but I will volunteer to edit a draft covering this topic if one or more LISP researchers will help write it. On Jan 25, 2009 4:22 PM, "John Zwiebel" wrote: FWIW: The sub-optimal routing will only be for the LISP map-request. The reply and all encapsulated data traffic is between RLOCs The ALT is merely there to provide the correct mapping. Also, since a map-reply from any ETR for a given site will provide you with all the RLOCs for that site, there is no need to advertise any sub-prefix into the ALT. Rather you would advertise the most highly aggregated route you have for your EID-site. So the ALT table should be considerably smaller. On Jan 25, 2009, at 11:49 AM, Benson Schliesser wrote: > > Dave- > > On Sun, Jan 25, 2009 at 3:26 PM, David Meyer > wrote: >> >> This is ... > > > _______________________________________________ > lisp mailing list > > lisp@ietf.org > https://www.... > --0015175ce17263aa600461575581 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

John-

I agree, in LISP the volume of ALT traffic is very small versus the volu= me of encapsulated data traffic. This is one of the primary reasons I like = LISP-ALT as a near-term solution, to be honest.

The ALT peering, though, isn't 100% clear to me yet. Sorry if I'= m just slow today or have forgotten something that's already been discu= ssed. (The recent holiday seems to have effectively cleared my mind.)

My single-homed xTR (savvis) has one ALT peer right now (asp) and he ann= ounces an aggregate net that covers my EID prefix. That's great from a = routing scale perspective. However if I were to multihome to another net (d= mm, for example) wouldn't I have to announce my EID into the ALT via th= at path if I wanted to continue serving that EID during an outage of my pri= mary (asp) connectivity?

At the very least it has to be announced such that my primary upstream s= ees it and can divert map-requests to my secondary path. So do all of my xT= Rs need to have ALT tunnels to all of my EID allocators in order to avoid d= e-aggregation in the ALT tables while maintaining fault tolerant connectivi= ty? What happens if an AS-wide fault takes down all of my allocator's A= LT routers? I understand that my RLOCs are still aggregated by the underlyi= ng network's routing regardless.

It would be good to discuss what all of this looks like for network engi= neering purposes. For instance from the perspective of ALT traffic engineer= ing, an end-site xTR with end users surfing the web will probably have a mo= derate collection of EID mappings that stay refreshed (Google, Twitter, cor= p intranet, etc) and a small collection of mappings that get used and expir= e (my blog, which nobody reads twice). This is different from an xTR in fro= nt of a public website, which will basically build a huge collection of map= pings and have to worry more about the database size than anything else.

Cheers,
-Benson

PS - I hate to say this, but I will volunteer to edit a draft covering t= his topic if one or more LISP researchers will help write it.

On Jan 25, 2009 4:22 PM, "John Zwiebel" <jzwiebel@cisco.com> wrote:

FW= IW:
The sub-optimal routing will only be for the LISP map-request.
The reply and all encapsulated data traffic is between RLOCs
The ALT is merely there to provide the correct mapping.

Also, since a map-reply from any ETR for a given site will
provide you with all the RLOCs for that site, there is no
need to advertise any sub-prefix into the ALT.  Rather you
would advertise the most highly aggregated route you have
for your EID-site.  So the ALT table should be considerably smaller. On Jan 25, 2009, at 11:49 AM, Benson Schliesser wrote:

> D= ave- > > On Sun, Jan 25, 2009 at 3:26 PM, David Meyer <dmm@1-4-5.net> wrote: >> >>       This is ...

> _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www....


--0015175ce17263aa600461575581-- --===============1313080856== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1313080856==-- From lisp-bounces@ietf.org Sun Jan 25 17:03:00 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423F83A6828; Sun, 25 Jan 2009 17:03:00 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598703A6828; Sun, 25 Jan 2009 17:02:59 -0800 (PST) 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.060, 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 zcxz9v9xOetb; Sun, 25 Jan 2009 17:02:58 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7FE713A67A8; Sun, 25 Jan 2009 17:02:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,323,1231113600"; d="scan'208,217";a="236462066" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2009 01:02:41 +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 n0Q12f0Y014282; Sun, 25 Jan 2009 17:02:41 -0800 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 n0Q12f5A016521; Mon, 26 Jan 2009 01:02:41 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 17:02:41 -0800 Received: from [10.0.1.4] ([10.21.64.235]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 17:02:40 -0800 In-Reply-To: <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: John Zwiebel Date: Sun, 25 Jan 2009 15:02:37 -1000 To: Benson Schliesser X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 26 Jan 2009 01:02:40.0680 (UTC) FILETIME=[C9853A80:01C97F51] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7209; t=1232931761; x=1233795761; 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]=20Economic=20issues=20of=20long- path=20/=20stretched=20routing |Sender:=20; bh=Un/S8mbEK+rN2/n+sp4S1iu+2gUyibLAT5sQLv1I2kk=; b=rcx4+peKNQL+w4gZoo0X30PlN96ICaqW98L0G9ZhyaAEDEswhYz3tOlJqg HGuHX39xdCKbTqR7AbBsOCcD/NXiAcuWUytwxVD7/FLjG+P63pA0EyQcCcE3 dpIDQj6nlV; Authentication-Results: sj-dkim-2; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , Content-Type: multipart/mixed; boundary="===============2002984182==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============2002984182== Content-Type: multipart/alternative; boundary=Apple-Mail-59--925996064 --Apple-Mail-59--925996064 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jan 25, 2009, at 1:53 PM, Benson Schliesser wrote: > My single-homed xTR (savvis) has one ALT peer right now (asp) and > he announces an aggregate net that covers my EID prefix. That's > great from a routing scale perspective. However if I were to > multihome to another net (dmm, for example) wouldn't I have to > announce my EID into the ALT via that path if I wanted to continue > serving that EID during an outage of my primary (asp) connectivity? > Yes you should, but that doesn't add another route to the ALT routing table. > At the very least it has to be announced such that my primary > upstream sees it and can divert map-requests to my secondary path. > If your primary router goes down, yes. > So do all of my xTRs need to have ALT tunnels to all of my EID > allocators in order to avoid de-aggregation in the ALT tables while > maintaining fault tolerant connectivity? > All of your xTRs need to connect to the ALT to get mapping information. (ie to send map requests over the ALT and receive map-replies natively). Each xTR would advertise the same EID-prefix. So no matter how many xTRs you have, only the single EID-prefix is advertised. The ALT only carries EID-prefix routes (and next-hop information for the ALT). It need not carry the RLOC routes at all. Those are in the DFZ. > What happens if an AS-wide fault takes down all of my allocator's > ALT routers? I understand that my RLOCs are still aggregated by the > underlying network's routing regardless. > Hopefully you'd have RLOCs from two different allocators. When one goes down, the other one is still available for map-requests. > Hope this helps --Apple-Mail-59--925996064 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Jan 25, 2009, at 1:53 PM, Benson Schliesser = wrote:

My = single-homed xTR (savvis) has one ALT peer right now (asp) and he = announces an aggregate net that covers my EID prefix. That's great from = a routing scale perspective. However if I were to multihome to another = net (dmm, for example) wouldn't I have to announce my EID into the ALT = via that path if I wanted to continue serving that EID during an outage = of my primary (asp) = connectivity?


Yes you = should, but that doesn't add another route to the ALT routing = table.

At the very least it has to be = announced such that my primary upstream sees it and can divert = map-requests to my secondary path.

If your = primary router goes down, yes.

So do all of my xTRs need to = have ALT tunnels to all of my EID allocators in order to avoid = de-aggregation in the ALT tables while maintaining fault tolerant = connectivity?

All of your xTRs need to = connect to the ALT to get mapping information. (ie to = send=A0
map requests over the ALT and receive map-replies = natively). =A0Each xTR would
advertise the same EID-prefix. = =A0So no matter how many xTRs you have, only the
single = EID-prefix is advertised. The ALT only carries EID-prefix routes (and = next-hop=A0
information for the ALT). =A0It need not carry the = RLOC routes at all. =A0Those are in the DFZ.

What happens if an AS-wide = fault takes down all of my allocator's ALT routers? I understand that my = RLOCs are still aggregated by the underlying network's routing = regardless.

Hopefully you'd have RLOCs from two = different allocators. =A0When one goes down, the
other one is = still available for map-requests. =A0
X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002133A6972; Sun, 25 Jan 2009 20:11:08 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D673A691D; Sun, 25 Jan 2009 20:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.586 X-Spam-Level: X-Spam-Status: No, score=-5.586 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_20=-0.74, 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 nd8evq8E8ldE; Sun, 25 Jan 2009 20:11:05 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id DB2CE3A68BC; Sun, 25 Jan 2009 20:11:05 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1761F6BE5F0; Sun, 25 Jan 2009 23:10:44 -0500 (EST) To: lisp@ietf.org, routing-discussion@ietf.org, rrg@irtf.org Message-Id: <20090126041045.1761F6BE5F0@mercury.lcs.mit.edu> Date: Sun, 25 Jan 2009 23:10:44 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Can we _PLEASE_ stop cross-posting things to three lists at once? Thanks. Noel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 26 01:53:35 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C16828C1BD; Mon, 26 Jan 2009 01:53:35 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA24828C1BD for ; Mon, 26 Jan 2009 01:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ojskKyY8dQFN for ; Mon, 26 Jan 2009 01:53:32 -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 76E2A3A6914 for ; Mon, 26 Jan 2009 01:53:32 -0800 (PST) Received: from [130.149.220.21] (kea.net.t-labs.tu-berlin.de [130.149.220.21]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 2B5AF700D6F2; Mon, 26 Jan 2009 10:53:14 +0100 (CET) Message-ID: <497D8809.4060406@net.t-labs.tu-berlin.de> Date: Mon, 26 Jan 2009 10:53:13 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Dino Farinacci References: <49778EE1.8050407@uclouvain.be> <45A96B82-9301-4935-A251-7B4DB8E8BD22@cisco.com> <4978DDA8.5080505@uclouvain.be> <4979F9DB.9030601@net.t-labs.tu-berlin.de> <7E1EA1E9-C52B-4B62-95A3-C45D2AEA2D79@cisco.com> In-Reply-To: <7E1EA1E9-C52B-4B62-95A3-C45D2AEA2D79@cisco.com> X-Enigmail-Version: 0.95.0 Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] The case for Map-Updates 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dino, comments inline Dino Farinacci wrote: >> Dino, >> >> Dino Farinacci wrote: >>>> SMR allows to sollicit a new map request, it does not allow an xTR to >>>> update the mapping on the other mapping servers that are >>>> responsible for >>>> the same EID. >>> >>> The point of soliciting a map-request is so you can return a map-reply >>> with updated information. The way it works is like this: >>> >>> o I am an ETR with a mapping change. >>> o I solicit at the rate I want to receive requests by setting the >>> SMR-bit for the active sites >>> I am talking to. Because those sites will need the new information >>> sooner than the ones not >>> talking to me. >> This implies that you have bidirectional traffic. What happens in the >> case of unidirectional traffic? (at leats from that ETR perspective) > > Well the SMR-bit is in both a data packet and a Map-Request. So if > there is unidirectional traffic from a site that needs to be updated, > the site that has the mapping change sends a Map-Request to one or > more of the remote xTRs. > Ok, Map-Request, can be used to announce an update. With a Map-Update message you will just save a Map-Reply message. The question that comes to my mind now is how the ETR can understand that the the ITR has an old mapping hence a Map-Request needs to be sent? A simple solution would be to send a Map-Request+SMR to all ITRs you are receiving unidirectional traffic from. >>> o You are a site that is talking to me so I ask you to send me a >>> Map-Request. >>> o You then send me a Map-Request and I return a Map-Reply. >>> o I remember I sent you the updated mapping data so the loc-reach-bits >>> I send you reflect the >>> new mapping. >>> >> So the ETR has to remember the ITR talking to him that have already been >> updated? > > Right. But look at the failure cases, and let's see how bad it is. If > you mis-set the loc-reach-bits you are basically saying that some > xTRs, which are up, you are erroneously reporting them as down. That, > in and of itself is not that bad, because the ITRs at the remote sites > can just choose another RLOC in the locator-set. This would only occur > for a short period of time (i.e. the rate-limit time and propagation > delay). And in the case where the xTR is reporting an RLOC up when in > fact it is down suffers packet loss for that short period of time. > Yes. But what if the source of the packet with the mis-set loc-reach-bits is an attacker? What if this attacker continously sends packets with wrong loc-reach-bits? My point here is that loc-reach-bits should not be trusted, but used as an hint and confirmed by Map-Request/Map-Reply exchange. Only if the updated mapping confirms the change in reachability, then the traffic is shifted to different rlocs. > Remember, an ITR can switch to another RLOC in the locator-set > anytime, as long as it's within the set of high-priority RLOCs so it > can adhere to the policy of the destination site. An ITR can switch > when it sees no packets from an alleged down RLOC. > > I realize that in unidirectional traffic this might not be the case. > But there are few cases where a site has absolutely no return traffic > of any kind from any host at the site. You are right on the fact that host-to-host unidirectional traffic is rare, but unidirectional flows are more common. There are several protocols, typically for monitoring, that are "fire-and-forget". In the inter-domain case it is not so uncommon to have asymmetric paths, which means unidirectional flows. [snip] > >>>>>> - load-balanced xTR are overloaded and their weight needs to be >>>>>> updated >>>>> >>>>> SMRs do this too. Or you can source-quench the source by advertising >>>>> the >>>>> RLOC as unreachable for a short period of time. There are already >>>>> simple >>>>> mechanisms in place that seem to work well. >>>> >>>> SMRs allow to sollicit a new Map-request, but this Map-Request will be >>>> received by any of the mapping servers (e.g. xTR) that serve the site. >>>> These mapping servers need to be coherent and advertise the same >>>> EID-to-RLOC mappings. >>> >>> Right, but the xTR that is old will have loc-reach-bits relative to >>> the locator-set it is sending. >>> >> Does this old mapping match with the new one on the ETR? > > Umm, I don't quite understand the references. Can you restate? Sorry for that, I agree I was unclear ;-) I was just stating that if it is an xTR with an old mapping that is replying to the Map-Request, it will probably have a different set for the loc-reach-bits. With this different setting for the loc-rech-bit you can experience traffic disruption, at least for short periods. However, this is more an issue related to the mapping system that needs to guarantee as much as possible the coherence of mappings on the xTRs. Thanks Luigi > > Dino > >> >> >> Luigi >> >>> 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 lisp-bounces@ietf.org Mon Jan 26 02:00:25 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674E03A6914; Mon, 26 Jan 2009 02:00:25 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB863A6914 for ; Mon, 26 Jan 2009 02:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 r66xptK5IUuV for ; Mon, 26 Jan 2009 02:00:23 -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 E72D23A68F7 for ; Mon, 26 Jan 2009 02:00:22 -0800 (PST) Received: from [130.149.220.21] (kea.net.t-labs.tu-berlin.de [130.149.220.21]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 148C0700D6F2; Mon, 26 Jan 2009 11:00:05 +0100 (CET) Message-ID: <497D89A4.6000109@net.t-labs.tu-berlin.de> Date: Mon, 26 Jan 2009 11:00:04 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Dino Farinacci References: <49730E98.1030101@uclouvain.be> <4976453C.4020306@uclouvain.be> <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> <4979FB09.4020104@net.t-labs.tu-berlin.de> <9F11BFA9-BD8A-4198-AD1A-F0722CAB01CF@cisco.com> In-Reply-To: <9F11BFA9-BD8A-4198-AD1A-F0722CAB01CF@cisco.com> X-Enigmail-Version: 0.95.0 Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Locator liveness problem 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Dino Farinacci wrote: >> True. But I still think that will be impossible to maintain this >> ordering coherent among all xTRs when scale to the size of the Internet >> and mapping changes happen. > > First off, the number of xTRs at a site are going to be a small > number. So they can stay in sync and get into sync over a shorter > period of time. > Agreed. My point was more on the fact that even if you have a limited number of xTRs, your site can be contacted by a very large number of other sites, with which you have to maintain coherence. > Second, an xTR at a site knows who it is talking to and knows what it > sent it last, so a 32-bit value per mapping entry tells you what the > loc-reach-bits setting should be for a given site you are talking to. Wait. You are saying that to each entry in your cache you add a 32-bit value that tells the loc-reach-bit you sent to that site the last time you sent a packet toward it? Is this what you meant? Thanks Luigi > > > Dino > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 26 08:05:28 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8CDA28C248; Mon, 26 Jan 2009 08:05:28 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D974E28C158; Sun, 25 Jan 2009 09:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, 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 MUijuU-de38x; Sun, 25 Jan 2009 09:20:45 -0800 (PST) Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by core3.amsl.com (Postfix) with ESMTP id 39DC03A6B55; Sun, 25 Jan 2009 09:20:45 -0800 (PST) Received: from HeinerHummel@aol.com by imo-d04.mx.aol.com (mail_out_v39.1.) id c.cea.4cba28ba (65097); Sun, 25 Jan 2009 12:19:52 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Sun, 25 Jan 2009 12:19:52 EST To: dino@cisco.com, rw@firstpr.com.au MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5021 X-Mailman-Approved-At: Mon, 26 Jan 2009 08:05:28 -0800 Cc: rrg@irtf.org, int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] [rrg] [Int-area] Please respond: Questions from the IESG as to whether a ... 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: , Content-Type: multipart/mixed; boundary="===============0275465738==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0275465738== Content-Type: multipart/alternative; boundary="-----------------------------1232903992" -------------------------------1232903992 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Dino, Just a simple question: Is the ALT GRE-tunnel hierarchy a tree ? =20 Heiner =20 =20 In einer eMail vom 24.01.2009 20:51:53 Westeurop=E4ische Normalzeit schreibt= =20 dino@cisco.com: > LISP has too many fundamental problems to be considered a > potentially practical solution. Some of these problems require LISP is not perfect and still evolving but let me point out that every =20 design has fundamental problems. At this scale, it's very hard to be =20 perfect Robin. And as Noel has stated so many times, the hard =20 decisions must be made to incrementally deploy this. So things might =20 not look pretty on the surface, but jeez, you got to do what you got =20 to do. Else, this will all be academic. We really want to solve this problem, sincerely. This is not lip =20 service, we are not just writing papers, we want to rev the Internet, =20 this is serious. I want to address each of your 7 points below. I have cc'ed the=20 lisp@ietf.org=20 mailing list so the folks who want to focus on details of LISP can =20 see this thread. > 1 - Delays in delivering initial packets in a flow. This is either > due to sending the packets along the ALT network (which takes > time and involves sending substantial volumes of data packets > over the ALT network, rather than just mapping requests) or to > sending mapping requests only, and waiting for the ITR to get a > response before it attempts to send traffic packets. We have a memory/bandwidth tradeoff. So we have to make a hard design =20 call. I'd rather have mappings cached and timed out so they can be =20 updated when they need to then to hold all the possible mappings for =20 the Internet in an ITR. There is no such thing of a free lunch. You either store all possible =20 mappings or you fetch them when you need them. > According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10 > & 11 the experimental LISP ALT network's ITRs drop initial > packets and send brief map request messages. Even if we think > this delay doesn't matter, I am sure enough potential adopters > would - and therefore make it difficult or impossible for LISP or > any other such solution to be widely enough adopted to solve the > routing scaling problem. Then why was/is ARP deployed in a 10^4 host-based bridged network with =20 basically the same properties. First packet loss is not persistent =20 when you look at all the traffic that originates from a source site to =20 another destination site. The host vendors are probably thinking, if we do LISP in the host, you =20 could wait to send your TCP SYN before the mapping is available. Guess =20 what, you don't send that TCP SYN before you get the DNS Reply. ;-) I =20 wonder why? Well I'll spell it out. If a host needs an address to make =20 the connection, we can say it also needs a locator to make a connection. The design choice of LISP *is to just change software in CPE devices* =20 to get the feature of decoupling rather than changing all the hosts at =20 a site. That's a huge deployment advantage. So these CPE devices get =20 packets before they have mappings. We don't even want to consider a =20 host to CPE router signaling protocol and all it's complexities to =20 solve this and to keep the architecture pure, we don't want to snoop =20 on DNS, SIP, or any other protocol that can give us a hint on where =20 the host is about to send a packet. So the cost is *either* first packet loss or sending the packet on the =20 ALT using it as a request for a mapping. > 2 - LISP-ALT's long-path problem > http://psg.com/lists/rrg/2008/msg01676.html > http://www.antd.nist.gov/~ksriram/strong_aggregation.png > > [Fix? Another fundamental problem in the architecture. Could > be partially solved by more meshiness, but that would greatly > increase the complexity of the network and so raise more > scaling problems.] Well this I believe is a duplicate of 1 above. So it's not really =20 *another* problem. > 3 - Problems creating a highly aggregated ALT network in order to > speed the flow of packets up and down the hierarchy, while also > making the network robust against the failure of its routers and > tunnels. This has not been discussed much on the RRG, but it is > an obvious problem. If we can do this with BGP, which we have decades of existence proof =20 why can't we do this with a tunnel topology 1) where a tunnel can be =20 rehomed much quicker and easily than physical links and boxes we have =20 to do with today, allowing aggregation to occur at the edges of the =20 ALT network, and 2) these tunnels stay up because there is robust =20 connectivity below the tunnel level to keep them up, hence there will =20 be less route-flaps for EID-prefixes. I think it's the complete opposite of what you claim. I think BGP will =20 be more stable and scalable then the underlying BGP. Plus, what we =20 propose for the use-case of BGP uses quite a few features of it. =20 Recall this is eBGP over GRE. We have an infrastructure where we can 1) ping to see liveness of =20 nodes on the ALT. We have traceroute to determine the path a Map- =20 Request takes on the ALT. We can ping/traceroute "underneath" so we =20 can see the diameter of the tunnel. Not only do we have a solution but =20 we use existing rudimentary tools for management. And the address allocation hierarchy can map this logical ALT =20 topology. And if the Registries are involved in managing part of this =20 ALT network (which we hope and think they will), we can keep this =20 consistent relationship. Do you realize the goodness of this? It's huge Robin. There's more too, you then throw SIDR in the mix and we have secured =20 the ALT, we have secured mappings, we created a PKI for routing use. =20 In fact, the first SIDR deployment could happen on the ALT to be =20 verified/experimented before it goes on the underlying BGP. And note, that the infrastructure will/does carry exactly 2 address-=20 families. So we can do 6-to-6-over-4 with this approach. That means we =20 can get two site to be *IPv6-only* and be able to talk to each other. If you are a IPv6-only site now or a dual-stack site, you could talk =20 to the new IPv6 Google services. I think this is a pretty huge feature. This is clean and architecturally pure, no double NATs, no CGNS, and =20 no applications breaking. > 4 - LISP-ALT's Aggregation implies provider dependence. > This is Christian Vogt's critique: > http://psg.com/lists/rrg/2008/msg00259.html Not true. Aggregation here is for the EID-prefix. Service providers do =20 not carry EID-prefixes in their cores so you don't depend on them. The =20 decoupling of the address creates this. The dependence is now on the =20 ALT. And if your site resides in a specific region of the world, you =20 get your EID-prefixes from that registry. So readdressing your domain =20 would only occur if you moved it from one region to another (let's =20 leave mobile ASes out of this for now). > 5 - Path MTU Discovery problems. Despite Fred Templin, myself and > others discussing the inherent PMTUD problems in any map-encap > proposal, there has been nothing from the LISP team to indicate > they have a solution. They seem to think there is no problem. In section 5.4 of draft-farinacci-lisp-11.txt we describe two proposed =20 solutions, one is stateless, and the other is stateful. The stateful =20 creates no new table data structures but requires storing an addition =20 2-bytes of effective-MTU state per mapping. > 6 - Lack of business case for LISP's Proxy Tunnel Routers: > http://psg.com/lists/rrg/2008/msg02021.html You cannot fault a technical design for a business case. A PTR is =20 solving a technical problem. And if we want to *truly* keep lots of PI =20 type routes out of the core *and* avoid NAT solutions which are just =20 way too high in opex, the PTR is the only solution we have to turn to. And on the contrary, I do believe service providers, interconnect =20 providers, registries, third-parties and even governments will provide =20 PTR services. Will they make a ton of money out of it, well that =20 remains to be seen. > 7 - The scaling problems of potentially thousands of ITRs each > probing reachability to one ETR, and likewise, one ITR probing > reachability to many ETRs - this is one view of the "Locator Path > Liveness Problem" of draft-meyer-loc-id-implications-00. > http://www.irtf.org/pipermail/rrg/2009-January/000809.html That is not in the LISP design. Everyone just thinks it is. ;-) Dave and Darrel's draft is providing a warning about how bad probing =20 can be. They do not take a position whether it should go into any =20 proposal. They are just saying, beware of the Frankenstein that may =20 result and can be an interpretation to not do probing at all. Like I mentioned in a previous RRG email message, one has to ask the =20 question if an ITR *should* switch from one RLOC to another when there =20 *may* be a path failure *somewhere in the middle of the network*. =20 Please note my very fine qualifications. If we want to solve this problem, we could do this today by having a =20 host switch it's TCP connection to another A record. This doesn't =20 happen today because people deal with packet loss, since it doesn't =20 last long *and* rerouting actually works quite well. Van Jacobson always made this comment and I'll never forget it, "The =20 fact that the Internet drops packets is it's greatest feature". What else can either an xTR or TCP host do when sending ICMP =20 Unreachables are off by default in most modern routers, or they are =20 filtered by firewalls, and route aggregation hides failures close to =20 packet sources. >> Unless these concerns are adequately addressed, claiming that LISP >> is an appropriate solution to the problems discussed at the IAB's >> October 2006 Routing and Addressing Workshop is nothing more than >> a proof by an emphatic assertion. > > I agree entirely. > > I believe the LISP team could have made much better use of the RRG - > by participating fully in the debates resulting from these critiques. We were asked to do research in RRG. That was a reasonable request. So =20 the research stuff in LISP has been and will continue to be presented =20 in RRG. As for the engineering issues, the real details and bits and bytes, we =20 want a forum to discuss and work out issues in an open forum. I've =20 been going to IETF for 20 years now, that forum is called a working =20 group. The working group doesn't have to standardize what it is working on. =20 And the charter and the numerous requests we have made requests *for =20 an experimental working group*. > Experiments won't help solve most of these problems. I am not > against experimentation and I think it is great that there is a LISP > experimental network. > > However, I would never have taken a proposal to the point of writing > code, running a network and inviting others to write compatible > implementations when the proposal had so many fundamental problems. There is constant implementation feedback back into the design. =20 Experienced engineers know how this cycle works. You start with =20 something you think can hold together, you try things out, you refine, =20 you revisit design, you go forward with implementation. That's the =20 process of *detailed* engineering. For the old timers, that was the difference between TCP/IP and OSI. Sorry for the long email, Dino _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg -------------------------------1232903992 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Dino,
Just a simple question: Is the ALT GRE-tunnel hierarchy a tree ?
 
Heiner
 
 
In einer eMail vom 24.01.2009 20:51:53 Westeurop=E4ische Normalzeit sch= reibt=20 dino@cisco.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>>   LISP has too many fundamental problems to be=20 considered a
>   potentially practical solution.  Som= e of=20 these problems require

LISP is not perfect and still evolving but l= et=20 me point out that every 
design has fundamental problems. At this= =20 scale, it's very hard to be 
perfect Robin. And as Noel has state= d so=20 many times, the hard 
decisions must be made to incrementally dep= loy=20 this. So things might 
not look pretty on the surface, but jeez,=20= you=20 got to do what you got 
to do. Else, this will all be=20 academic.

We really want to solve this problem, sincerely. This is=20= not=20 lip 
service, we are not just writing papers, we want to rev the=20 Internet, 
this is serious.

I want to address each of your= 7=20 points below. I have cc'ed the lisp@ietf.org
  mailing list so th= e=20 folks who want to focus on details of LISP can 
see this=20 thread.

> 1 - Delays in delivering initial packets in a flow.&nb= sp;=20 This is either
>    due to sending the packets along the A= LT=20 network (which takes
>    time and involves sending=20 substantial volumes of data packets
>    over the ALT netw= ork,=20 rather than just mapping requests) or to
>    sending mapp= ing=20 requests only, and waiting for the ITR to get a
>    respo= nse=20 before it attempts to send traffic packets.

We have a memory/bandwi= dth=20 tradeoff. So we have to make a hard design 
call. I'd rather have= =20 mappings cached and timed out so they can be 
updated when they n= eed=20 to then to hold all the possible mappings for 
the Internet in an= =20 ITR.

There is no such thing of a free lunch. You either store all=20 possible 
mappings or you fetch them when you need=20 them.

>    According to:=20 http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10
>    &am= p;=20 11 the experimental LISP ALT network's ITRs drop initial
>  &nb= sp;=20 packets and send brief map request messages.   Even if we=20 think
>    this delay doesn't matter, I am sure enough=20 potential adopters
>    would - and therefore make it=20 difficult or impossible for LISP or
>    any other such=20 solution to be widely enough adopted to solve the
>    rou= ting=20 scaling problem.

Then why was/is ARP deployed in a 10^4 host-based=20 bridged network with 
basically the same properties. First packet= =20 loss is not persistent 
when you look at all the traffic that=20 originates from a source site to 
another destination=20 site.

The host vendors are probably thinking, if we do LISP in the=20 host, you 
could wait to send your TCP SYN before the mapping is=20 available. Guess 
what, you don't send that TCP SYN before you ge= t=20 the DNS Reply. ;-) I 
wonder why? Well I'll spell it out. If a ho= st=20 needs an address to make 
the connection, we can say it also need= s a=20 locator to make a connection.

The design choice of LISP *is to just= =20 change software in CPE devices* 
to get the feature of decoupling= =20 rather than changing all the hosts at 
a site. That's a huge=20 deployment advantage. So these CPE devices get 
packets before th= ey=20 have mappings. We don't even want to consider a 
host to CPE rout= er=20 signaling protocol and all it's complexities to 
solve this and t= o=20 keep the architecture pure, we don't want to snoop 
on DNS, SIP,=20= or=20 any other protocol that can give us a hint on where 
the host is=20 about to send a packet.

So the cost is *either* first packet loss o= r=20 sending the packet on the 
ALT using it as a request for a=20 mapping.

> 2 - LISP-ALT's long-path problem
>   = =20   http://psg.com/lists/rrg/2008/msg01676.html
>    &n= bsp;=20 http://www.antd.nist.gov/~ksriram/strong_aggregation.png
>
>&n= bsp;=20     [Fix? Another fundamental problem in the architecture. = =20 Could
>       be partially solved by more meshin= ess,=20 but that would greatly
>       increase the=20 complexity of the network and so raise more
>     &nb= sp;=20 scaling problems.]

Well this I believe is a duplicate of 1 above. S= o=20 it's not really 
*another* problem.

> 3 - Problems crea= ting=20 a highly aggregated ALT network in order to
>    speed the= =20 flow of packets up and down the hierarchy, while also
>   = =20 making the network robust against the failure of its routers and
>&n= bsp;=20   tunnels.  This has not been discussed much on the RRG, but it=20 is
>    an obvious problem.

If we can do this with=20= BGP,=20 which we have decades of existence proof 
why can't we do this wi= th a=20 tunnel topology 1) where a tunnel can be 
rehomed much quicker an= d=20 easily than physical links and boxes we have 
to do with today,=20 allowing aggregation to occur at the edges of the 
ALT network, a= nd=20 2) these tunnels stay up because there is robust 
connectivity be= low=20 the tunnel level to keep them up, hence there will 
be less=20 route-flaps for EID-prefixes.

I think it's the complete opposite of= =20 what you claim. I think BGP will 
be more stable and scalable the= n=20 the underlying BGP. Plus, what we 
propose for the use-case of BG= P=20 uses quite a few features of it. 
Recall this is eBGP over=20 GRE.

We have an infrastructure where we can 1) ping to see liveness= =20 of 
nodes on the ALT. We have traceroute to determine the path a=20= Map-=20
Request takes on the ALT. We can ping/traceroute "underneath" so we&nb= sp;=20
can see the diameter of the tunnel. Not only do we have a solution=20 but 
we use existing rudimentary tools for management.

And= the=20 address allocation hierarchy can map this logical ALT 
topology.=20= And=20 if the Registries are involved in managing part of this 
ALT netw= ork=20 (which we hope and think they will), we can keep this 
consistent= =20 relationship.

Do you realize the goodness of this? It's huge=20 Robin.

There's more too, you then throw SIDR in the mix and we have= =20 secured 
the ALT, we have secured mappings, we created a PKI for=20 routing use. 
In fact, the first SIDR deployment could happen on=20= the=20 ALT to be 
verified/experimented before it goes on the underlying= =20 BGP.

And note, that the infrastructure will/does carry exactly 2=20 address-
families. So we can do 6-to-6-over-4 with this approach. That= =20 means we 
can get two site to be *IPv6-only* and be able to talk=20= to=20 each other.

If you are a IPv6-only site now or a dual-stack site, y= ou=20 could talk 
to the new IPv6 Google services. I think this is a pr= etty=20 huge feature.

This is clean and architecturally pure, no double NAT= s,=20 no CGNS, and 
no applications breaking.

> 4 - LISP-ALT'= s=20 Aggregation implies provider dependence.
>    This is=20 Christian Vogt's critique:
>   =20 http://psg.com/lists/rrg/2008/msg00259.html

Not true. Aggregation h= ere=20 is for the EID-prefix. Service providers do 
not carry EID-prefix= es=20 in their cores so you don't depend on them. The 
decoupling of th= e=20 address creates this. The dependence is now on the 
ALT. And if y= our=20 site resides in a specific region of the world, you 
get your=20 EID-prefixes from that registry. So readdressing your domain 
wou= ld=20 only occur if you moved it from one region to another (let's 
lea= ve=20 mobile ASes out of this for now).

> 5 - Path MTU Discovery=20 problems.  Despite Fred Templin, myself and
>    othe= rs=20 discussing the inherent PMTUD problems in any map-encap
>  &nbs= p;=20 proposal, there has been nothing from the LISP team to indicate
>&nb= sp;=20   they have a solution.  They seem to think there is no=20 problem.

In section 5.4 of draft-farinacci-lisp-11.txt we describe=20= two=20 proposed 
solutions, one is stateless, and the other is stateful.= The=20 stateful 
creates no new table data structures but requires stori= ng=20 an addition 
2-bytes of effective-MTU state per mapping.

&= gt;=20 6 - Lack of business case for LISP's Proxy Tunnel Routers:
> =20   http://psg.com/lists/rrg/2008/msg02021.html

You cannot fault= a=20 technical design for a business case. A PTR is 
solving a technic= al=20 problem. And if we want to *truly* keep lots of PI 
type routes o= ut=20 of the core *and* avoid NAT solutions which are just 
way too hig= h in=20 opex, the PTR is the only solution we have to turn to.

And on the=20 contrary, I do believe service providers, interconnect 
providers= ,=20 registries, third-parties and even governments will provide 
PTR=20 services. Will they make a ton of money out of it, well that 
rem= ains=20 to be seen.

> 7 - The scaling problems of potentially thousands=20= of=20 ITRs each
>    probing reachability to one ETR, and likewi= se,=20 one ITR probing
>    reachability to many ETRs - this is o= ne=20 view of the "Locator Path
>    Liveness Problem" of=20 draft-meyer-loc-id-implications-00.
>   =20 http://www.irtf.org/pipermail/rrg/2009-January/000809.html

That is=20= not=20 in the LISP design. Everyone just thinks it is.  ;-)

Dave and=20 Darrel's draft is providing a warning about how bad probing 
can=20= be.=20 They do not take a position whether it should go into any 
propos= al.=20 They are just saying, beware of the Frankenstein that may 
result= and=20 can be an interpretation to not do probing at all.

Like I mentioned= in=20 a previous RRG email message, one has to ask the 
question if an=20= ITR=20 *should* switch from one RLOC to another when there 
*may* be a p= ath=20 failure *somewhere in the middle of the network*. 
Please note my= =20 very fine qualifications.

If we want to solve this problem, we coul= d do=20 this today by having a 
host switch it's TCP connection to anothe= r A=20 record. This doesn't 
happen today because people deal with packe= t=20 loss, since it doesn't 
last long *and* rerouting actually works=20 quite well.

Van Jacobson always made this comment and I'll never fo= rget=20 it, "The 
fact that the Internet drops packets is it's greatest=20 feature".

What else can either an xTR or TCP host do when sending=20 ICMP 
Unreachables are off by default in most modern routers, or=20= they=20 are 
filtered by firewalls, and route aggregation hides failures=20 close to 
packet sources.

>> Unless these concerns a= re=20 adequately addressed, claiming that LISP
>> is an appropriate=20 solution to the problems discussed at the IAB's
>> October 2006=20 Routing and Addressing Workshop is nothing more than
>> a proof b= y an=20 emphatic assertion.
>
> I agree entirely.
>
> I=20 believe the LISP team could have made much better use of the RRG -
>= by=20 participating fully in the debates resulting from these critiques.

= We=20 were asked to do research in RRG. That was a reasonable request. So =20
the research stuff in LISP has been and will continue to be=20 presented 
in RRG.

As for the engineering issues, the real= =20 details and bits and bytes, we 
want a forum to discuss and work=20= out=20 issues in an open forum. I've 
been going to IETF for 20 years no= w,=20 that forum is called a working 
group.

The working group=20 doesn't have to standardize what it is working on. 
And the chart= er=20 and the numerous requests we have made requests *for 
an experime= ntal=20 working group*.

> Experiments won't help solve most of these=20 problems.  I am not
> against experimentation and I think it is= =20 great that there is a LISP
> experimental network.
>
>=20 However, I would never have taken a proposal to the point of writing
&g= t;=20 code, running a network and inviting others to write compatible
>=20 implementations when the proposal had so many fundamental=20 problems.

There is constant implementation feedback back into the=20 design. 
Experienced engineers know how this cycle works. You sta= rt=20 with 
something you think can hold together, you try things out,=20= you=20 refine, 
you revisit design, you go forward with implementation.=20 That's the 
process of *detailed* engineering.

For the old= =20 timers, that was the difference between TCP/IP and OSI.

Sorry for t= he=20 long=20 email,
Dino

_______________________________________________
r= rg=20 mailing=20 list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
 
 -------------------------------1232903992-- --===============0275465738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0275465738==-- From lisp-bounces@ietf.org Mon Jan 26 08:05:28 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC4128C256; Mon, 26 Jan 2009 08:05:28 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BEC93A6A64; Mon, 26 Jan 2009 01:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.138 X-Spam-Level: X-Spam-Status: No, score=-0.138 tagged_above=-999 required=5 tests=[AWL=-0.425, 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 7FBBGtbdIRHV; Mon, 26 Jan 2009 01:11:41 -0800 (PST) Received: from imo-m11.mail.aol.com (imo-m11.mx.aol.com [64.12.143.99]) by core3.amsl.com (Postfix) with ESMTP id 5F4F13A6A60; Mon, 26 Jan 2009 01:11:41 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m11.mx.aol.com (mail_out_v39.1.) id m.be9.46c7f8e2 (29678); Mon, 26 Jan 2009 04:11:16 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Mon, 26 Jan 2009 04:11:16 EST To: bensons@queuefull.net, lisp@ietf.org, routing-discussion@ietf.org, rrg@irtf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5021 X-Mailman-Approved-At: Mon, 26 Jan 2009 08:05:28 -0800 Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , Content-Type: multipart/mixed; boundary="===============0955776087==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0955776087== Content-Type: multipart/alternative; boundary="-----------------------------1232961075" -------------------------------1232961075 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 26.01.2009 04:07:23 Westeurop=E4ische Normalzeit schreibt= =20 bensons@queuefull.net: I have a concern about the economic aspects of stretch, specifically related to peering in routing systems where topology follows address assignment more closely than today's Internet. This is one of the main differences with TARA: There a topological view is=20 constructed such that stretch becomes 1 and not like here where stretch is= =20 that what will turn out to be by chance. =20 Heiner =20 -------------------------------1232961075 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 26.01.2009 04:07:23 Westeurop=E4ische Normalzeit sch= reibt=20 bensons@queuefull.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>I have a=20 concern about the economic aspects of stretch, specifically
related to=20 peering in routing systems where topology follows address
assignment mo= re=20 closely than today's Internet.
This is one of the main differences with TARA: There a topological= =20 view is constructed such that stretch becomes 1 and  not like here= =20 where stretch is that what will turn out to be by chance.
 
Heiner
 
-------------------------------1232961075-- --===============0955776087== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0955776087==-- From lisp-bounces@ietf.org Mon Jan 26 08:05:28 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC66328C25D; Mon, 26 Jan 2009 08:05:28 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366A828C1BD; Mon, 26 Jan 2009 01:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, 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 RdrNYnROCUTp; Mon, 26 Jan 2009 01:46:40 -0800 (PST) Received: from imo-m22.mail.aol.com (imo-m22.mx.aol.com [64.12.137.3]) by core3.amsl.com (Postfix) with ESMTP id 6019728C1B1; Mon, 26 Jan 2009 01:46:39 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m22.mx.aol.com (mail_out_v39.1.) id 9.c07.530a414a (29678); Mon, 26 Jan 2009 04:46:16 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Mon, 26 Jan 2009 04:46:16 EST To: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5021 X-Mailman-Approved-At: Mon, 26 Jan 2009 08:05:28 -0800 Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , Content-Type: multipart/mixed; boundary="===============1125278178==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1125278178== Content-Type: multipart/alternative; boundary="-----------------------------1232963176" -------------------------------1232963176 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 26.01.2009 04:07:41 Westeurop=E4ische Normalzeit schreibt= =20 jzwiebel@cisco.com: The sub-optimal routing will only be for the LISP map-request. The reply and all encapsulated data traffic is between RLOCs The ALT is merely there to provide the correct mapping. Prior arguing with long-path, stretch etc. I have another informative =20 question (maybe I missed something too during the discussion): Why LISP 1.5=20= ? Why=20 not LISP 2 ? or directly: Why doesn't the ITR intercept and enhance the DNS lookup as to also request=20= =20 the eRLOC address in addition to the dest IP address? It can also intercept=20 the respective response and store (EID, eRLOC). =20 I also ask this because wrt my TARA solution I would do the alike: The =20 difference is only that the eRLOC information, to be retrieved from DNS, ar= e just=20 the geographical coordinates of the ETR (as by experimental RFC 1712). So far I cannot see why there is a (compelling ?) reason fro the ALT =20 hierarchy at all. =20 =20 Thanks for answers to my question, Heiner =20 =20 -------------------------------1232963176 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 26.01.2009 04:07:41 Westeurop=E4ische Normalzeit sch= reibt=20 jzwiebel@cisco.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>The=20 sub-optimal routing will only be for the LISP map-request.
The reply an= d=20 all encapsulated data traffic is between RLOCs
The ALT is merely there=20= to=20 provide the correct mapping.

 
Prior arguing with long-path, stretch etc. I have another informative=20 question (maybe I missed something too during the discussion): Why LISP 1.5=20= ?=20 Why not LISP 2 ? or directly:
Why doesn't the ITR intercept and enhance the DNS lookup as to also req= uest=20 the eRLOC address in addition to the dest IP address? It can also intercept=20= the=20 respective response and store (EID, eRLOC).
 
I also ask this because wrt my TARA solution I would do the alike: The=20 difference is only that the eRLOC information, to be retrieved from=20 DNS, are just the geographical coordinates of the ETR (as by experiment= al=20 RFC 1712).
So far I cannot see why there is a  (compelling ?) reason fro the=20= ALT=20 hierarchy at all.  
 
Thanks for answers to my question,
Heiner
 
 
-------------------------------1232963176-- --===============1125278178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1125278178==-- From lisp-bounces@ietf.org Mon Jan 26 08:24:58 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30B93A6A79; Mon, 26 Jan 2009 08:24:58 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4471928C187; Mon, 26 Jan 2009 08:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 6YgiX9ZL6DHU; Mon, 26 Jan 2009 08:24:57 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 821293A6A18; Mon, 26 Jan 2009 08:24:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,326,1231113600"; d="scan'208";a="236808136" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2009 16:24: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 n0QGOaOA016788; Mon, 26 Jan 2009 08:24:36 -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 n0QGOaCa005266; Mon, 26 Jan 2009 16:24:36 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); Mon, 26 Jan 2009 08:24:36 -0800 Received: from dino-macbook.dhcp.nanog.merit.net ([10.21.121.201]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 08:24:36 -0800 Message-Id: <5F9CF4DF-64C8-4D1A-9FF5-DE4CA17B12C4@cisco.com> From: Dino Farinacci To: HeinerHummel@aol.com In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 26 Jan 2009 08:24:36 -0800 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Jan 2009 16:24:36.0301 (UTC) FILETIME=[943327D0:01C97FD2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=671; t=1232987077; x=1233851077; 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]=20Economic=20issues=20of=20long- path=20/=20stretched=20routing |Sender:=20; bh=kmB7erxMlm7jtD4oabY5dE23ZdnPNQ7lRlKH+3QIWEM=; b=KGcAd3dGqbI6O0pdSsfnKrpe4L7rZCFbgzH88zAJwa/XOFLVomIfhmdZzK DP3Kg2YEjFJeBTzA2GNXqb0TvRU6u+fduwNJzTBwKsqI/lZTMZlpgUgMbqvl IkX6fHS5vg; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > Prior arguing with long-path, stretch etc. I have another > informative question (maybe I missed something too during the > discussion): Why LISP 1.5 ? Why not LISP 2 ? or directly: > Why doesn't the ITR intercept and enhance the DNS lookup as to also > request the eRLOC address in addition to the dest IP address? It can > also intercept the respective response and store (EID, eRLOC). 1) Because not all communication uses DNS. 2) Because DNS queries go out one xTR and replies can come in through another xTR. 3) Because you don't want a architectural circular dependency between directory and routing. Do you want more reasons? Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 26 08:34:37 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C4C28C229; Mon, 26 Jan 2009 08:34:37 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA86628C230; Mon, 26 Jan 2009 08:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 Zbmtaa0DAVPu; Mon, 26 Jan 2009 08:34:34 -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 805B73A6A45; Mon, 26 Jan 2009 08:34:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,326,1231113600"; d="scan'208";a="133552594" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Jan 2009 16:34:17 +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 n0QGYHxH014143; Mon, 26 Jan 2009 08:34:17 -0800 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 n0QGYHCJ006632; Mon, 26 Jan 2009 16:34:17 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, 26 Jan 2009 08:34:16 -0800 Received: from dino-macbook.dhcp.nanog.merit.net ([10.21.121.201]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 08:34:16 -0800 Message-Id: <59EA5644-C135-48AD-897A-5F0ED7156E17@cisco.com> From: Dino Farinacci To: Benson Schliesser In-Reply-To: <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 26 Jan 2009 08:34:15 -0800 References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Jan 2009 16:34:16.0428 (UTC) FILETIME=[EDFB82C0:01C97FD3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2759; t=1232987657; x=1233851657; 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]=20Economic=20issues=20of=20long- path=20/=20stretched=20routing |Sender:=20; bh=67umW8rbUIs2R2FNxLS17YT9OrSLMReNhzF+BxdQK5s=; b=ZvtM3tx/y9ucaubO1pEGuVntRZqBBcJWmowUgEGJYANsgzm7oV5l97AdHZ ttXk2mSTNIzn6T0eWXRH/6rD6JldD5lW77wN4V0BSKstObT3ryD+WxxDG75G OJNup9n2N/; 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, routing-discussion@ietf.org Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > My single-homed xTR (savvis) has one ALT peer right now (asp) and he > announces an aggregate net that covers my EID prefix. That's great > from a routing scale perspective. However if I were to multihome to > another net (dmm, for example) wouldn't I have to announce my EID > into the ALT via that path if I wanted to continue serving that EID > during an outage of my primary (asp) connectivity? > Yes, you would. And you would peer at the level before the aggregation level router. So in the real world, you would peer with sub-parts of your region's registry. > At the very least it has to be announced such that my primary > upstream sees it and can divert map-requests to my secondary path. > So do all of my xTRs need to have ALT tunnels to all of my EID > Not divert, but you want the shortest path to your site for Map- Requests. So each of your xTRs will have GRE tunnels where their "tunnel source " configuration will have be the locator address from each attached upstream. > allocators in order to avoid de-aggregation in the ALT tables while > maintaining fault tolerant connectivity? What happens if an AS-wide > fault takes down all of my allocator's ALT routers? I understand > that my RLOCs are still aggregated by the underlying network's > routing regardless. > Right, no deaggregation anywhere. You don't have to TE with more specific injection on the ALT, you use your tunnel locators for this. Also, we want you to have a low opex xTRs, so when *you do not run BGP on your xTRs*, it will be your upstreams will "redistribute static tag ". And they won't need to deaggregate as well because you will be *within* their aggregation level. > It would be good to discuss what all of this looks like for network > engineering purposes. For instance from the perspective of ALT > traffic engineering, an end-site xTR with end users surfing the web > will probably have a moderate collection of EID mappings that stay > refreshed (Google, Twitter, corp intranet, etc) and a small > collection of mappings that get used and expire (my blog, which > nobody reads twice). This is different from an xTR in front of a > public website, which will basically build a huge collection of > mappings and have to worry more about the database size than > anything else. > Mappings get refreshed locally in the xTR based on data flow. So you don't need to continually Map-Request the site. Plus, you can use the old ARP trick. That is, give yourself enough time before the entry times out, to request to see if the mapping is still current. And only do that when there is data flow against the entry. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 26 11:04:34 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329113A68B8; Mon, 26 Jan 2009 11:04:34 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C563A6996 for ; Mon, 26 Jan 2009 11:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 yKrBrpudseRb for ; Mon, 26 Jan 2009 11:04:33 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 222B43A68B8 for ; Mon, 26 Jan 2009 11:04:33 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 616566BE571; Mon, 26 Jan 2009 14:04:15 -0500 (EST) To: lisp@ietf.org Message-Id: <20090126190415.616566BE571@mercury.lcs.mit.edu> Date: Mon, 26 Jan 2009 14:04:15 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [rrg] Economic issues of long-path / stretched routing 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > From: HeinerHummel@aol.com > Why LISP 1.5=20? Why not LISP 2 ? or directly: > Why doesn't the ITR intercept and enhance the DNS lookup as to also request > the eRLOC address in addition to the dest IP address? It can also > intercept the respective response and store (EID, eRLOC). I don't know what the thinking of other people working on LISP is, but I can give you my thoughts on this point. Simply put, I don't like designs which _invisibly, outside the host_ tie into the DNS because it takes two separate subsystems (DNS resolution, and basic packet forwarding), and tangles them together, which is bad engineering for a number of reasons (makes it harder to make further changes, creates more mutual dependencies, increases overall fragility/brittleness, etc). Some NAT variants do this too, and I especially didn't like them either! :-) Noel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 26 14:33:42 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6856B3A6817; Mon, 26 Jan 2009 14:33:42 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD3928C181 for ; Mon, 26 Jan 2009 14:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 4bmbzcb8zTkQ for ; Mon, 26 Jan 2009 14:33:40 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 51DEA3A67FB for ; Mon, 26 Jan 2009 14:33:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,327,1231113600"; d="scan'208";a="237016949" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2009 22:33:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0QMXNNp015000; Mon, 26 Jan 2009 14:33:23 -0800 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 n0QMXNnu028828; Mon, 26 Jan 2009 22:33:23 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); Mon, 26 Jan 2009 14:33:22 -0800 Received: from [70.151.3.229] ([10.21.88.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 14:33:20 -0800 Message-Id: <8EF34447-551C-4BE0-8C8A-EC245C9B0151@cisco.com> From: Dino Farinacci To: Luigi Iannone In-Reply-To: <497D89A4.6000109@net.t-labs.tu-berlin.de> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 26 Jan 2009 12:00:11 -0800 References: <49730E98.1030101@uclouvain.be> <4976453C.4020306@uclouvain.be> <35D285E6-E674-4B34-9881-B040890E9669@cisco.com> <4979FB09.4020104@net.t-labs.tu-berlin.de> <9F11BFA9-BD8A-4198-AD1A-F0722CAB01CF@cisco.com> <497D89A4.6000109@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Jan 2009 22:33:20.0726 (UTC) FILETIME=[17627F60:01C98006] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=254; t=1233009203; x=1233873203; 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]=20Locator=20liveness=20problem |Sender:=20; bh=a3raniXzaH3664iLGSEGHo+NRfp3IwW0L+K0Om8brTY=; b=zyx9bfbNfR1O1Ol73lU+AfZ7VtYLpin8Nnr0KZo0z3KRfOxoQwBHMS9nBp CFOFZc1YC70kRzYhGxzKY/LqbvlU/pkVCo1SVcrWQRVCXfr+56bA7cLYoILd rB3RnAbqvL; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] Locator liveness problem 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > You are saying that to each entry in your cache you add a 32-bit value > that tells the loc-reach-bit you sent to that site the last time you > sent a packet toward it? > Is this what you meant? Yes, but I haven't implemented this yet. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 26 14:33:42 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7780F28C1A4; Mon, 26 Jan 2009 14:33:42 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73EA23A67FB for ; Mon, 26 Jan 2009 14:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 A3xfGIYTRPxx for ; Mon, 26 Jan 2009 14:33:40 -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 BD0F93A6817 for ; Mon, 26 Jan 2009 14:33:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,327,1231113600"; d="scan'208";a="133719290" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 26 Jan 2009 22:33:23 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n0QMXNi1032683; Mon, 26 Jan 2009 14:33:23 -0800 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 n0QMXNae028685; Mon, 26 Jan 2009 22:33:23 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); Mon, 26 Jan 2009 14:33:23 -0800 Received: from [70.151.3.229] ([10.21.88.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 14:33:21 -0800 Message-Id: <3401C02F-C942-46A3-B44F-80FED37C8A57@cisco.com> From: Dino Farinacci To: Luigi Iannone In-Reply-To: <497D8809.4060406@net.t-labs.tu-berlin.de> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 26 Jan 2009 12:02:34 -0800 References: <49778EE1.8050407@uclouvain.be> <45A96B82-9301-4935-A251-7B4DB8E8BD22@cisco.com> <4978DDA8.5080505@uclouvain.be> <4979F9DB.9030601@net.t-labs.tu-berlin.de> <7E1EA1E9-C52B-4B62-95A3-C45D2AEA2D79@cisco.com> <497D8809.4060406@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Jan 2009 22:33:21.0632 (UTC) FILETIME=[17ECBE00:01C98006] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=292; t=1233009203; x=1233873203; c=relaxed/simple; s=sjdkim4002; 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]=20The=20case=20for=20Map-Updates |Sender:=20; bh=AzxEu8LcGsulDAn5X9BQmByKst2CtF64GuQdjLEHAfo=; b=qEx44VK+8KyzeAxwUpZrqFKpQFnhW4/3rVfJYASLvUff0hJGojD8wjE0BN gGvbMm+8IU5AqLc+xqgAGC1fryObBceAX1bQEwSR+0XLiYWCwwisG8aEzUX0 q8BiQCJECv; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] The case for Map-Updates 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > My point here is that loc-reach-bits should not be trusted, but used > as > an hint and confirmed by Map-Request/Map-Reply exchange. > Only if the updated mapping confirms the change in reachability, then > the traffic is shifted to different rlocs. Yes, they are a hint. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 26 14:33:43 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C958228C229; Mon, 26 Jan 2009 14:33:43 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36B93A67FB; Mon, 26 Jan 2009 14:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 ko9XOvcrShLN; Mon, 26 Jan 2009 14:33:41 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F2EC33A6A16; Mon, 26 Jan 2009 14:33:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,327,1231113600"; d="scan'208";a="125845465" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2009 22:33:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0QMXNpa015012; Mon, 26 Jan 2009 14:33:23 -0800 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 n0QMXNvK028836; Mon, 26 Jan 2009 22:33:23 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); Mon, 26 Jan 2009 14:33:23 -0800 Received: from [70.151.3.229] ([10.21.88.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 14:33:22 -0800 Message-Id: From: Dino Farinacci To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1057A286E@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 26 Jan 2009 12:12:29 -0800 References: <20090120190744.GA9467@1-4-5.net><49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net><75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com><497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1057A286E@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Jan 2009 22:33:22.0773 (UTC) FILETIME=[189AD850:01C98006] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3961; t=1233009203; x=1233873203; 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[Int-area]=20[rrg]=20Please=20respond=3 A=20Questions=20from=20the=20IESG=20as=20towhether=20a=20WG= 20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=KeKXl1dmmwsr2GHwWnjFctw6IJ8mIDd52A1mzCbshAs=; b=RTxmhBD72ZxZi5jzOhYs1jHbDbGnqptza1YVy0tVOnNZsYbvGr0D0me9vt CeAWNWM32JBybyudfPmIe2pFmlD/o7CNrs3NrgZ86Y4CCoXdAXvi1XL4pKG8 BOPRKFN94N; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rrg RG , int-area@ietf.org, routing-discussion@ietf.org, lisp@ietf.org Subject: Re: [lisp] [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > In the "stateless" case, having the LISP ITR return > packet-too-bigs with degenerate MTUs (i.e., MTUs less > than 1500) is going to leave source hosts with an > unsatisfactory experience that they would not incur > without an ITR/ETR in the middle. Ah, then that motivates to upgrade MTUs. > In the stateful case, LISP relies on a brittle mechanism > that has known vulnerabilities (e.g., [RFC2923]) and can > easily be spoofed by off-path attackers. Are you saying MTU Discovery is flawed? > RANGER/SEAL fixes both of these problems and much more. With a lot more machinery and state. Let's not start this conversation again. > Fine qualifications noted (I think). About the LISP > locator reachability bits, that seems like a lot of > overhead to carry on each and every packet, and it 4 bytes per packet? Sorry, I don't think so. > also seems to assume symmetric paths. RANGER assumes > unidirectional tunnels and path asymmetry, i.e., if > Site 1's packets use ITR A and go through ETR B at > Site 2, the return traffic could actually come through > Site 2's ITR C. In the LISP locator reachability case, > how does C know anything about the reachability of A? It can send a Map-Request. But active-active on ingress and egress will be the norm. > Although RANGER could send locator reachability bits > in control messages as an optimization, its primary > mechanism is through having the ITR probe the forward > path to the ITR. Probing is by setting an "ack request" > bit on every Nth data packet (+/- some delta if > randomization is desired) and then observing whether > a steady stream of ACKs comes back. This doesn't work because if you are going to claim liveness through a protocol, you have to send control packets all the time from M ITRs to N ETRs. If you claim liveness, you have to do this before you send packets. So putting the probe in data packets is not sufficient. And if you send probes all the time from M ITRs to N ETRs, you have a huge scaling problem. > LISP also doesn't seem to take into account that a multi- > homed site can partition, such that locator reachability > does not necessarily imply end system reachability via > specific locators. Nor does it provide a means for an ETR > (A) to inform the ITR of a better ETR (B) when paths get > stretched. RANGER has a means to accommodate this. Can you state some disadvantages of RANGER? There is no such thing as a free lunch, so your design has to make tradeoffs, but you seem to never state them. >> If we want to solve this problem, we could do this today by having a >> host switch it's TCP connection to another A record. This doesn't >> happen today because people deal with packet loss, since it doesn't >> last long *and* rerouting actually works quite well. >> >> Van Jacobson always made this comment and I'll never forget it, "The >> fact that the Internet drops packets is it's greatest feature". >> >> What else can either an xTR or TCP host do when sending ICMP >> Unreachables are off by default in most modern routers, or they are >> filtered by firewalls, and route aggregation hides failures close to >> packet sources. > > RANGER can listen for ICMP unreachables coming from network > middleboxes that it can verify as on-path by checking the Non-starter, you will not get ICMP unreachables, period. So if you solely depend on it, the solution is a non-starter. > SEAL_ID. In a RANGER world, network middleboxes would be > encouraged to turn the ICMPs back on because site border > xTRs will have a means to detect spoofing (i.e., the SEAL_ID). > But, this is an optimization only; nothing in RANGER depends > on getting the ICMPs from middleboxes. You have to turn it on in all transit routers. You will get objection to this. It will never happen and if you think it could possibly happen, it will take forever. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 26 14:52:05 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243743A6AD6; Mon, 26 Jan 2009 14:52:05 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B942328C14D for ; Mon, 26 Jan 2009 14:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 aV2Gi11LEFo4 for ; Mon, 26 Jan 2009 14:52:03 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 8CFCB3A6A59 for ; Mon, 26 Jan 2009 14:52:03 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CC9C957EAFD; Mon, 26 Jan 2009 17:51:45 -0500 (EST) To: lisp@ietf.org Message-Id: <20090126225145.CC9C957EAFD@mercury.lcs.mit.edu> Date: Mon, 26 Jan 2009 17:51:45 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > From: Dino Farinacci > if you are going to claim liveness through a protocol, you have to send > control packets all the time from M ITRs to N ETRs. I find this terminology somewhat non-intuitive, and wonder if it's too late to change it. To me, "liveness" would imply as to whether something is live or dead, i.e. up or down. (Such state detection can obviously be performed on ITR I1's behalf by I2, and the result communicated locally from I2 to I1.) The issue of whether packets from ITR Im can reach ETR En (which is where you run into the need for M*N) I would describe as "reachability". (So if there's a routing problem, or an access control setting, that prevents I1 from getting to E7 even through I1 can get to E8 and I2 can get to E7, that would be a reachability problem on the {I1, E7} pairing.) I seem to recall this term being used in at least one routing protocol, although I can't now recall which one. Noel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Jan 26 23:15:55 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5C43A69BF; Mon, 26 Jan 2009 23:15:55 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B41D3A689A; Mon, 26 Jan 2009 23:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[AWL=-1.652, BAYES_00=-2.599, FB_INCREASE_VOL=3.629, 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 RKzvyx2PaOnd; Mon, 26 Jan 2009 23:15:50 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id B622F3A69BF; Mon, 26 Jan 2009 23:15:47 -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 C6E13175723; Tue, 27 Jan 2009 18:15:26 +1100 (EST) Message-ID: <497EB510.8060100@firstpr.com.au> Date: Tue, 27 Jan 2009 18:17:36 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: RRG References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> In-Reply-To: <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> Cc: routing-discussion@ietf.org, int-area@ietf.org, lisp@ietf.org Subject: Re: [lisp] [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Short version: Responding to Dino's reply to my critiques of LISP. The LISP team should do detailed critiques of APT and Ivip as part of convincing IETF folks of the merits of LISP-ALT. Will it be possible to do firmware upgrades so all DFZ routers ca. 2014 will handle packets with modified IPv4 and IPv6 headers, to forward the packets the ISP network of the ETR, without encapsulation, its overheads and PMTUD problems? If so, then maybe we could go straight to this approach and forget about encapsulation and all its complexities. Hi Dino, Thanks for your reply: > Sorry for the long email, We are attempting to re-engineer one of humanity's most excellent and important communication networks. Long detailed messages are often appropriate. >> LISP has too many fundamental problems to be considered a >> potentially practical solution. Some of these problems require > > LISP is not perfect and still evolving but let me point out that > every design has fundamental problems. At this scale, it's very > hard to be perfect Robin. And as Noel has stated so many times, the > hard decisions must be made to incrementally deploy this. So things > might not look pretty on the surface, but jeez, you got to do what > you got to do. Else, this will all be academic. I wasn't suggesting a proposal should be perfect. I pointed out problems which I consider to be fundamental - not "on the surface". Some can be fixed by adding new design elements, but I think the others are only fixable by radically altering the current design. I stand corrected about LISP's approach to PMTUD - the latest draft does include an outline of a workable solution. > We really want to solve this problem, sincerely. This is not lip > service, we are not just writing papers, we want to rev the > Internet, this is serious. I have always known you and the other LISP folks really care for the Net and are working hard to devise the best possible improvements. Despite it only having had broad-based commercial, political and inter-personal impact in the last 15 years, the Internet is a momentous development in human relations. We all want to see changes which will enable it to remain technically viable - and hopefully elegant - for the long-term future. However, I think you jumped straight into some seemingly attractive approaches which turn out to have problems I consider to be serious. It seems that you and the APT folks thought for a few moments about a real-time mapping system and figured it was out of the question. I think it is not at all out of the question - and when you have real-time mapping distribution, you can do some elegant and valuable things: 1 - Separate out reachability testing and ETR choice mechanisms and let (actually require) the end-user networks to do it themselves - or pay someone else to do it for them. 2 - Enable the end-user networks to do real-time incoming TE control. 3 - Send the mapping update stream to local query servers, so there is reliable and very fast responses to mapping requests - and therefore no need to delay or drop initial packets. 4 - Charge a small fee per update to pay for most of the mapping distribution system. 5 - Provide much better support for the TTR approach to mobility: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf I think the ALT system is a lot niftier than CONS, but still, you are delaying initial packets (APT and Ivip are not), forcing every ITR to do its own reachability testing and monolithically integrating those testing and ETR choice mechanisms into the core-edge separation scheme itself. I don't think we should be rushed into thinking we can't possibly have local full-database query servers in ISPs and larger end-user networks, or that it is impossible to push the mapping to them in a few seconds (real-time). One advantage of the real-time approach over LISP-ALT, APT's approach or the TRRP DNS-like global query server approach is that it is streamlined and includes multiple mapping changes (dozens or perhaps a hundred IPv4 mapping changes) in a single packet. > I want to address each of your 7 points below. I have cc'ed the > lisp@ietf.org mailing list so the folks who want to focus on details of > LISP can see this thread. OK, we are also transmitting to routing-discussion@ietf.org and int-area@ietf.org . >> 1 - Delays in delivering initial packets in a flow. This is either >> due to sending the packets along the ALT network (which takes >> time and involves sending substantial volumes of data packets >> over the ALT network, rather than just mapping requests) or to >> sending mapping requests only, and waiting for the ITR to get a >> response before it attempts to send traffic packets. > > We have a memory/bandwidth tradeoff. So we have to make a hard design > call. I'd rather have mappings cached and timed out so they can be > updated when they need to then to hold all the possible mappings for the > Internet in an ITR. > > There is no such thing of a free lunch. You either store all possible > mappings or you fetch them when you need them. That is the dichotomy between LISP-CONS/ALT and LISP-NERD. However there is another approach (APT and Ivip): full push to local query servers. RAM and hard drive space is very cheap. The query servers don't need to be Cisco-style routers. They can be COTS or high-reliability rack-mount PCs - with gigabytes of RAM and terabytes of hard disk storage. In Ivip, IPv4 mapping consists of 12 bytes: Start of the micronet (32 bits) Length of the micronet (32 bits, but typically 16 or less) ETR address (32 bits) So if you have a COTS server with 16GB of RAM (this will no-doubt be the common amount of RAM in PCs by the time a core-edge separation scheme is deployed) then you can easily dedicate 12GB for mapping information. That is a billion micronets (more or less, depending on the storage format), which will do the trick for many years to come. (IPv6 mapping is more bloated, but there is a longer time-frame for implementing millions or billions of IPv6 micronets - time for RAM to get cheaper still). I think you - and the designers of APT and TRRP - have been somewhat captive to established ways of thinking about how to solve a "routing" problem: with more "routing" style structures. This means more routers, more messages and replies zipping around the world etc. It doesn't have to be like this. I need to do more work on the fast-push system of Ivip - but you are welcome to critique it in its current form: http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00 If your design choice with LISP is optimal, or the only one you think is available, then you should be able to point out why it is impractical or undesirable to use an approach such as Ivip's: real-time fast push on a global basis to local query servers, with local pull from there to ITRs, followed by pushed updates from the query server to the ITRs if a micronet's mapping changes within the caching time of the mapping reply. Likewise, you presumably have a critique about the practicality or desirability of APT: slow push to local query servers (Default Mappers) in each ISP, local pull from ITRs querying the Default Mappers, local push of mapping updates from DMs to those ITRs which need it (I think) and (again, my recollection) the Default Mappers, rather than the ITRs, doing reachability testing and choosing which ITR address an ITR uses. The Net will soon be delivering gigabytes of video data to homes, in near-real-time, for a few dollars. Generally, a packet can be sent from any host to any other host in 0.2 seconds or less. In this scenario, why do you think global push to local query servers - including high-speed, real-time push - is impractical or undesirable? >> According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10 >> & 11 the experimental LISP ALT network's ITRs drop initial >> packets and send brief map request messages. Even if we think >> this delay doesn't matter, I am sure enough potential adopters >> would - and therefore make it difficult or impossible for LISP or >> any other such solution to be widely enough adopted to solve the >> routing scaling problem. > > Then why was/is ARP deployed in a 10^4 host-based bridged network with > basically the same properties. First packet loss is not persistent when > you look at all the traffic that originates from a source site to > another destination site. This doesn't apply to small end-user networks. If there are to be hundreds of millions of these sites, meaning hundreds of millions of EIDs or (Ivip) micronets - then these are mainly going to be small "sites", such as home offices, or more likely mobile devices. The initial packet delay will directly impact usability, since there may only be one human user at each such "site". If many small "sites" use a common ITRs in a large ISP, there will be less trouble with this, since it will be more common for one site to generate a packet to some EID/micronet which the ITR has mapping from, due to another "site" sending a packet there too. However, the frequent delay of initial packets (actually, it seems you are planning to drop all initial packets) will still be a problem. If LISP is not meant to scale to a hundred million or a billion or whatever "sites", then by whatever same smaller target number of EIDs, micronets or whatever, this would make alternative approaches such as Ivip or APT even more immune from whatever scalability critiques you might make of them. > The host vendors are probably thinking, if we do LISP in the host, you > could wait to send your TCP SYN before the mapping is available. On IPv4, with most human-used hosts behind NAT, you can't put a LISP ITR in the sending host, because the map reply won't come back to the host. In a scenario in which LISP is widely - ubiquitously - deployed, many DNS servers are going to be on EID space. This means the ITR will often need to do a mapping lookup before it can send a DNS request. The sending host will be on EID space and so the DNS server's ITR will need to do a mapping lookup too before it can send the return packet. This will suck to a high degree in the current arrangement where the DNS server sends a single packet. The ITR of the DNS server will drop that packet and send a mapping request for the original sending host's EID. Then, after a while, the sending host will realise it got no DNS response. If it sends the same request to the same DNS server, it will get a response back quickly, since now, the DNS server's ITR has the sending host's mapping in its cache. But what if the sending hosts does it it might reasonably do: send the request to a different DNS server? Then the same pattern as above occurs again. > Guess > what, you don't send that TCP SYN before you get the DNS Reply. ;-) I > wonder why? Well I'll spell it out. If a host needs an address to make > the connection, we can say it also needs a locator to make a connection. So you are proposing that every DNS reply also include full LISP mapping for every one or more EIDs of the one or more IP addresses returned? I doubt if that will always fit in one packet. > The design choice of LISP *is to just change software in CPE devices* to > get the feature of decoupling rather than changing all the hosts at a > site. OK . . . LISP mutates again! I have been following LISP intently since about March 2007 and I don't recall any mention of changes to hosts or to CPE - by which I guess you mean DSL, cable and fibre router/firewalls. Do you propose putting the ITR function in the DSL modem-router-firewall? That is not such a bad idea, since it has (presumably) a public IP address and so can receive the map reply message from the globally distant query server (in the case of LISP, the mapping queries are typically answered by the destination end-user network's ETR). Ivip has the option for putting ITR functions in a sending host which has a public address, or in a device such as a DSL-modem-router-firewall. It would not be out of the question to put an ITR function in the sending host behind NAT, but then the sending host would need to build a persistent tunnel through NAT to the one or more local query servers - in order to receive mapping updates from those query servers. That is possible, but not part of the current plan. > That's a huge deployment advantage. I don't see any advantage in terms of deployment, since it involves changes to more and more equipment, including customer equipment. Ivip's ITFH (ITR Function in Host) is optional - if it is cheap and convenient to do this for servers or devices like DSL-routers, then by all means do so. It only makes sense when the device is well-connected. It would be a bad idea to put an ITR function in a host or router at the edge of the network connected by a slow, expensive or unreliable link such as a wireless link. > So these CPE devices get packets before they have mappings. OK - for instance, the ITR function is in a DSL-modem-router-firewall device. > We don't even want to consider a host > to CPE router signaling protocol and all it's complexities to solve this > and to keep the architecture pure, we don't want to snoop on DNS, SIP, > or any other protocol that can give us a hint on where the host is about > to send a packet. I agree. > So the cost is *either* first packet loss or sending the packet on the > ALT using it as a request for a mapping. These are not the only choices. Another choice is to using a different architecture with local query servers - as does APT and Ivip. I think you have approached this without thinking widely enough about the alternative ways of doing things which are different from traditional approaches like routers and DNS. If you send the packet on the ALT network (for the purposes of delivering it to the ETR ASAP, as well as to elicit a mapping reply from that ETR) then you are going to greatly increase the volume of traffic on the ALT network. Many of these packets will be short - but what if someone sends a 1500 or 9000 byte packet? If you don't send the packet via the ALT network, then you either drop it, or delay it until the mapping arrives. But that could be longer than 0.5 or 1.0 seconds, considering how many ALT routers the mapping request packet needs to go through to get to the ETR, how these ALT routers could be all over the world, and how the ETR could be on the other side of the world anyway. This is a lot slower than the current system which usually takes 0.2 seconds or less to delivers packet anywhere in the world. (The round trip from Melbourne Australia to Latvia is about 400ms.) >> 2 - LISP-ALT's long-path problem >> http://psg.com/lists/rrg/2008/msg01676.html >> http://www.antd.nist.gov/~ksriram/strong_aggregation.png >> >> [Fix? Another fundamental problem in the architecture. Could >> be partially solved by more meshiness, but that would greatly >> increase the complexity of the network and so raise more >> scaling problems.] > > Well this I believe is a duplicate of 1 above. So it's not really > *another* problem. In terms of delaying packets, I agree. Do you agree the long-path critique is valid? The long path involves more than delay. It involves traffic flowing (often) all around the world due to the fact that the highly aggregated structure of the ALT network will frequently result in different levels of the ALT hierarchy of routers being distributed all around the globe, since the physical location of organisations who are responsible for various parts of the address space does not correlate very strongly with geography or the topology of the Net. This is a traffic burden, particularly if you are sending initial packets on the ALT network for ASAP delivery to the ETR, rather than just map requests. (However, Ivip involves pumping mapping information around the globe anyway, and if your ALT network only handles requests, not traffic packets, the actual volume of traffic should not be too much of a problem.) Each operator of each ALT router needs to have a commercial relationship with those other ALT routers they connect with. Otherwise, why would they accept the traffic? I haven't seen any business plan for the commercial relationships which pay for the ALT routers and their traffic. Ivip's fast push system involves a charge per update, which will finance the construction and running costs of most of the fast-push system, which will be run collectively by the various RUAS (Root Update Authorisation System) companies, each of which generates the real-time mapping changes for multiple MABs (Mapped Address Blocks - BGP-advertised prefixes encompassing thousands, or hundreds of thousands of micronets). >> 3 - Problems creating a highly aggregated ALT network in order to >> speed the flow of packets up and down the hierarchy, while also >> making the network robust against the failure of its routers and >> tunnels. This has not been discussed much on the RRG, but it is >> an obvious problem. > > If we can do this with BGP, which we have decades of existence proof why > can't we do this with a tunnel topology 1) where a tunnel can be rehomed > much quicker and easily than physical links and boxes we have to do with > today, allowing aggregation to occur at the edges of the ALT network, > and 2) these tunnels stay up because there is robust connectivity below > the tunnel level to keep them up, hence there will be less route-flaps > for EID-prefixes. I don't recall any prior mention of rapidly reconstructing tunnels to maintain the ALT topology. I agree with your point 2 that the tunnels will be reasonably robust due to relying on existing connectivity which is generally ensured by BGP. But what happens when two ALT routers loose their connection for a moment? Do they try to set up one or more tunnels with the same role in the ALT topology as the one which just died? This is your point 1. It could get messy, but I guess it could be done, by using other interfaces which, for some reason (I guess) have connectivity while the interfaces used for the first tunnel don't. But that is the sort of situation which I think BGP would naturally resolve, generally in a few seconds or less. My concern is more about what happens if an ALT router dies. In your highly aggregated hierarchy, a mid-level ALT router is a single point of failure for sending mapping requests to all the ETRs in the branch below this router and from all the ITRs in that branch to ETRs outside the branch. When a mid-level router dies, you can't just re-establish tunnels - it is dead. The routers below need to establish tunnels to another ALT router which can take the dead one's place. How is this going to work? Say one lower-level router finds it can't reach the mid-level router in question, it is going to assume the mid-level router is dead. So the lower-level router tries to set up a tunnel to the one or more backups. If it does so, either this won't work at all, or the next level up will have to adapt to the original mid-level router having routes for most of its patch of the ALT address space, but with the backup having the router for the smaller patch of space handled by the lower-level router which just made a tunnel to the backup mid-level router. > I think it's the complete opposite of what you claim. I think BGP will > be more stable and scalable then the underlying BGP. I assume you mean that the BGP of the ALT network, operating over tunnels, will be more stable than the BGP of the Internet. This is your point 2, and I largely agree. But what if an ALT router dies? > Plus, what we > propose for the use-case of BGP uses quite a few features of it. Recall > this is eBGP over GRE. > > We have an infrastructure where we can 1) ping to see liveness of nodes > on the ALT. We have traceroute to determine the path a Map-Request takes > on the ALT. We can ping/traceroute "underneath" so we can see the > diameter of the tunnel. I don't understand "diameter" in this context. > Not only do we have a solution but we use > existing rudimentary tools for management. > > And the address allocation hierarchy can map this logical ALT topology. > And if the Registries are involved in managing part of this ALT network > (which we hope and think they will), we can keep this consistent > relationship. > > Do you realize the goodness of this? It's huge Robin. I am sure you can make the ALT network reasonably robust, at a cost of complexity and with a loss of the original attractive design goal: a very high degree of aggregation. I imagine you can reduce the excessively long paths by collapsing the network as much as possible to reduce the number of levels a packet typically has to ascend and descend. This will reduce the "long-path" problem significantly. But then, each participating mid-level ALT router (there are fewer of them) covers a larger part of the address space, and my concerns above become more acute, when such a router fails or becomes really unreachable. I imagine you can reduce the geographical scatter component of the long-path problem by centralizing the ALT routers geographically. However, that privileges some operators and creates costs and difficulties for others. I still think it is fundamentally wrong to have a global query server network for any system like this, where waiting for mapping replies involves delaying or dropping traffic packets. I think a much better solution is to push the mapping to local query servers in each ISP (APT and Ivip) - and into any larger end-user networks which want to run their own local query servers (Ivip) so their ITRs can get marginally faster, more reliable, responses than by using the query servers of their ISPs. > There's more too, you then throw SIDR in the mix and we have secured the > ALT, we have secured mappings, we created a PKI for routing use. In > fact, the first SIDR deployment could happen on the ALT to be > verified/experimented before it goes on the underlying BGP. PKI is a great idea, but I think most people believe it is highly desirable to find solutions which do not require it. > And note, that the infrastructure will/does carry exactly 2 > address-families. So we can do 6-to-6-over-4 with this approach. That > means we can get two site to be *IPv6-only* and be able to talk to each > other. > > If you are a IPv6-only site now or a dual-stack site, you could talk to > the new IPv6 Google services. I think this is a pretty huge feature. > > This is clean and architecturally pure, no double NATs, no CGNS, and no > applications breaking. Are you discussing just the mapping queries going over the ALT network? Or are you discussing the use of LISP to enable, for instance, two IPv6 sites to communicate via the IPv4 Internet, while one or both sites has no native IPv6 connectivity? A concrete example would help. >> 4 - LISP-ALT's Aggregation implies provider dependence. >> This is Christian Vogt's critique: >> http://psg.com/lists/rrg/2008/msg00259.html > > Not true. Aggregation here is for the EID-prefix. Service providers do > not carry EID-prefixes in their cores so you don't depend on them. The > decoupling of the address creates this. Christian's critique is not that an end-user network which has (permanently, by some arrangement) a slice of EID space is bound to its current ISP (the one it uses for connectivity). The critique is on this potentially erroneous basis: that the end-user network is bound to maintaining connectivity (via a tunnel) to the ALT router which handles this part of the EID space. It needs to do this so mapping queries for its EID space will get to its ETR. The potentially faulty aspect of this is the assumption that the end-user network runs its own ETR. But if its one or more ISPs run the ETR this end-user network uses, then the end-user network still depends on those ETRs having tunnels to potentially distant ALT router for its section of the EID space. I don't know if anyone has considered the scaling problems of a busy ETR maintaining tunnels to about as many ALT routers as the end-user networks it handles packets for. The ALT router for this section of the EID space will, I assume, be located at some ISP somewhere, or some other commercial organisation which rents out the EID space to this end-user network. Maybe that organisation is an RIR. But when this scales to tens or hundreds of millions of end-user networks (I assume this is a goal of LISP - it is of Ivip) I doubt if RIRs will want to be dealing with a hundred million end-user networks directly, either for address assignment or for tunnels to receive mapping requests to their ETRs from the ALT network. For these large scaling arrangements, there will need to be potentially multiple levels of address splitting. Ivip allows for this, and for multiple levels of companies providing interfaces to accept mapping changes from end-user networks (or more likely from reachability testing companies they hire) and funnelling them to the limited number of RUAS organisations which run the fast-push mapping distribution system. Any way you do this core-edge separation business - LISP, APT, Ivip or TRRP - if the end-user network gets a patch of stable address space to call their own, year after year, then that network is going to depend on some company or other organisation for that space. The end-user network will need to pay for this, and depend on the organisation to handle mapping. In the case of LISP-ALT, the organisation needs to run (or have someone else run) an ALT router (plus backups) which has a tunnel to the ETRs in the ISPs which the end-user network is currently using for access. If that organisation's ALT routers go down, it is not the fault of the access ISPs - it is up to the end-user network to ensure it obtains its EID address from an organisation which provides a reliable ALT router service. Also - assuming the space is covered by a PTR in order to provide 100% multihomed service for packets sent from hosts in non-upgraded networks - this organisation has to run PTRs which covers this end-user's EID space. For this to be scalable (not to bloat the DFZ routing table excessively, as we go to millions of end-user networks with EID/micronet space), the PTRs needs to advertise a prefix which covers the EID space of thousands or hundreds of thousands of separate end-user networks. Since the sending hosts (in non-upgraded networks) could be anywhere in the world and since the ISPs used by all these end-user networks (covered by the one BGP advertised route) could be anywhere in the world, in order to ensure reasonably direct path for traffic packets, there needs to be a largish number of PTRs physically all over the Net. Then the organisation which runs this PTR system needs to recover costs from individual end-user networks according to the traffic the PTRs carry. (This is the Ivip business model for OITRDs. I am stating this as an imperative for LISP, because I can't imagine any other business model for PTRs.) In the case of Ivip, the equivalent organisation needs to do the same as just stated for OITRDs and provide the real-time mapping distribution service, with a small charge per update. Either way, the end-user network has a long-term technical and commercial dependency on whichever organisation supplies its EID (LISP) or micronet (Ivip) address space. This is why my message continued to state that a problem such as this is common to all core-edge separation schemes: [Fix? Seems to be a fundamental problem, but every core-edge separation scheme involves supplying stable EID, micronet etc. address space to end-user networks, so there must be some kind of dependence on some organisation - though not necessarily an ISP.] {Experiments? There's no need for experiment - problems such as this can be clearly foreseen.} So while I could take this off the list of "unresolved" problems for LISP, since other schemes have comparable problems - I think LISP could be improved by more clearly stating the types of commercial and technical relationships each participating end-user network will rely upon. Also, the physical distance to the ALT router from wherever the end-user network's ETRs are directly affects the delay experienced at the start of sessions. I think that is part of Christian Vogt's concern. I think I have done a better job of explaining all this with Ivip's business model for OITRDs: http://psg.com/lists/rrg/2008/msg01158.html > The dependence is now on the > ALT. And if your site resides in a specific region of the world, you get > your EID-prefixes from that registry. So readdressing your domain would > only occur if you moved it from one region to another (let's leave > mobile ASes out of this for now). I think a good core-edge separation scheme should make the EID (micronet) space entirely portable, with little or no compromise in performance or costs regarding mapping no matter where the end-user network chooses to connect its EID space (or some part of it) to the Net. This is easier for Ivip, since the mapping change command only involves a few dozen bytes and is made quite infrequently. For LISP-ALT, the mapping connection is an incoming stream of requests or initial packets which also function as requests. It is time-sensitive, since only when a response arrives at the ITR can communications without delay begin. So the physical proximity (delay and reliability) between the ALT router for this section of the EID address space and the the ETRs of the ISPs currently used by the end-user network is really important. I don't mean San Jose to LA distances - I mean Australia to the USA, Germany to China etc. These do seem to be a fundamental difference between LISP-ALT and Ivip. However, both systems will only work well with a widespread set of PTRs/OITRDs. >> 5 - Path MTU Discovery problems. Despite Fred Templin, myself and >> others discussing the inherent PMTUD problems in any map-encap >> proposal, there has been nothing from the LISP team to indicate >> they have a solution. They seem to think there is no problem. > > In section 5.4 of draft-farinacci-lisp-11.txt we describe two proposed > solutions, one is stateless, and the other is stateful. The stateful > creates no new table data structures but requires storing an addition > 2-bytes of effective-MTU state per mapping. OK - I apologise for stating that you thought there was no problem. I haven't considered MTU problems of sending traffic packets along the ALT network, in its GRE tunnels (which impose their own encapsulation overhead) - but I understand the current LISP test network doesn't send traffic packets over ALT. It is my impression that your long-term plans are to use the ALT network only for short map request messages, not go get initial traffic packets to the ETR ASAP. Version 08 (2008-07-10) introduced a stateless technique and version 11 (2008-12-19) adds a stateful approach, derived from the OpenLISP project, who regarded the stateless approach as inadequate. My assessment of both approaches is in a separate message: LISP PMTU - 2 methods in draft-farinacci-lisp-11 http://www.irtf.org/pipermail/rrg/2009-January/000885.html I think the stateless section is poorly written and ill-conceived. The stateless approach for IPv4 DF=1 packets and IPv6 packets (that is, virtually all traffic) would limit traffic packets to 1464 bytes (IPv4) or 1444 bytes (IPv6). Only once there was jumboframe links between every ITR and ETR could L be globally adjusted upwards from 1500 bytes to ~9000 bytes or whatever - but this would not be possible for a decade or two. Fred Templin expressed the same concerns in a recent RRG message. The Stateful approach, which I understand is derived from OpenLISP, is similar to Ivip's approach: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ I need to write this up as an I-D, but it is a more detailed spec than your LISP approach, with mechanisms for occasionally testing for MTUs longer than the assumed limit and for strictly minimising the number of traffic packets which are used to probe the PMTU. Every packet whose length, once encapsulated, is in the "zone of uncertainty" for this ETR is either delivered or rejected with a PTB. The former raises the lower limit to the zone and the latter reduces the upper limit. >> 6 - Lack of business case for LISP's Proxy Tunnel Routers: >> http://psg.com/lists/rrg/2008/msg02021.html > > You cannot fault a technical design for a business case. A complete solution to the routing scaling problem involves much more than a technical design. All the technical stuff (sometimes split into "architecture" vs. "engineering") needs to facilitate someone wanting to build and run each part of it - which generally means they (or someone not too far removed from them) needs to be able to make money from it. > A PTR is > solving a technical problem. And if we want to *truly* keep lots of PI > type routes out of the core *and* avoid NAT solutions which are just way > too high in opex, the PTR is the only solution we have to turn to. > > And on the contrary, I do believe service providers, interconnect > providers, registries, third-parties and even governments will provide > PTR services. Will they make a ton of money out of it, well that remains > to be seen. I think my critique is valid - you seem to have no business case for LISP's Proxy Tunnel Routers. You are welcome to adopt the Ivip approach for address management and OITRDs: http://psg.com/lists/rrg/2008/msg01158.html This is directly applicable to LISP and PTRs, as long as you have a concept of a Mapped Address Block, containing many EIDs. For that to be the case, you need to develop business arrangements concerning who really "owns" the MAB and how they rent this space out as EID space for thousands of end-user networks. >> 7 - The scaling problems of potentially thousands of ITRs each >> probing reachability to one ETR, and likewise, one ITR probing >> reachability to many ETRs - this is one view of the "Locator Path >> Liveness Problem" of draft-meyer-loc-id-implications-00. >> http://www.irtf.org/pipermail/rrg/2009-January/000809.html > > That is not in the LISP design. Everyone just thinks it is. ;-) > > Dave and Darrel's draft is providing a warning about how bad probing can > be. They do not take a position whether it should go into any proposal. > They are just saying, beware of the Frankenstein that may result and can > be an interpretation to not do probing at all. The scaling problem of thousands of ITRs continually test reachability for one ETR (or to every ETR on the LISP mapping list for a given EID), plus reachability through each ETR to a given destination network, or of each ITR having to test reachability to thousands or tens of thousands of ETRs have been obvious from the start: early 2007. This is true of LISP, TRRP and to a somewhat lesser extent APT. (I haven't read RANGER yet.) Only Ivip avoids these scaling problems by making the end-user network responsible for their reachability testing and for deciding which ETR the packets for each micronet should be tunneled to. > Like I mentioned in a previous RRG email message, one has to ask the > question if an ITR *should* switch from one RLOC to another when there > *may* be a path failure *somewhere in the middle of the network*. Please > note my very fine qualifications. > > If we want to solve this problem, we could do this today by having a > host switch it's TCP connection to another A record. This doesn't happen > today because people deal with packet loss, since it doesn't last long > *and* rerouting actually works quite well. > > Van Jacobson always made this comment and I'll never forget it, "The > fact that the Internet drops packets is it's greatest feature". > > What else can either an xTR or TCP host do when sending ICMP > Unreachables are off by default in most modern routers, or they are > filtered by firewalls, and route aggregation hides failures close to > packet sources. The alternative has been available to you and anyone else since July 2007: Ivip. A fast-push mapping system to local query servers means the ITRs don't need to test reachability or make any decisions about which ETR to use. The mapping has a single ETR address. What is wrong with this approach? >>> Unless these concerns are adequately addressed, claiming that LISP >>> is an appropriate solution to the problems discussed at the IAB's >>> October 2006 Routing and Addressing Workshop is nothing more than >>> a proof by an emphatic assertion. >> >> I agree entirely. >> >> I believe the LISP team could have made much better use of the RRG - >> by participating fully in the debates resulting from these critiques. > > We were asked to do research in RRG. That was a reasonable request. So > the research stuff in LISP has been and will continue to be presented in > RRG. OK. > As for the engineering issues, the real details and bits and bytes, we > want a forum to discuss and work out issues in an open forum. I've been > going to IETF for 20 years now, that forum is called a working group. > > The working group doesn't have to standardize what it is working on. And > the charter and the numerous requests we have made requests *for an > experimental working group*. I think this is fine. However, I think there are sufficient fundamental, well known problems with LISP-ALT that if this was my proposal, I would fix them before asking people in general to join an IETF WG and help me with it - or drop the proposal. >> Experiments won't help solve most of these problems. I am not >> against experimentation and I think it is great that there is a LISP >> experimental network. >> >> However, I would never have taken a proposal to the point of writing >> code, running a network and inviting others to write compatible >> implementations when the proposal had so many fundamental problems. > > There is constant implementation feedback back into the design. > Experienced engineers know how this cycle works. You start with > something you think can hold together, you try things out, you refine, > you revisit design, you go forward with implementation. That's the > process of *detailed* engineering. > > For the old timers, that was the difference between TCP/IP and OSI. I am all for detailed engineering, running tests etc. However, the worst problems I perceive with LISP-ALT will not be illuminated by any amount of testing, as I explained in the message you are responding to. Do you think Ivip is so overblown and over-complex that it warrant's no serious consideration? Just because I write stuff in detail doesn't mean the system itself is over-complex. Ivip ITRs and ETRs are much simpler than LISP ITRs and ETRs. I have been giving your work the honour of detailed critiques for 18 months. I would appreciate you and your colleagues returning the favour by reading: http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00 Ivip business models: fast push & OITRDs http://psg.com/lists/rrg/2008/msg01158.html and telling me - and the RRG - what you think. Also, I am keen to know from you, your Cisco colleagues and from the folks at Juniper how practical it would be to create firmware upgrades for all the DFZ routers in use ca. 2014 or whatever - whenever the routing scaling solution is to be implemented. I think it is practical and highly desirable to encode the ETR address in the IPv4 header (actually 30 bits, which is fine) or a 20 bit prefix label in the IPv6 header. Then, in the longer term, we don't need encapsulation, its complexity, its overhead and its damn PMTUD problems. As far as I know, both these proposals could be implemented as firmware upgrades, or built-in optional features, in the DFZ routers which are likely to be in use in 5 years time, but only you guys can say this is so or not: ETR Address Forwarding (EAF) - for IPv4 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01 Prefix Label Forwarding (PLF) - for IPv6 http://www.firstpr.com.au/ip/ivip/ivip6/ Maybe we can do that in time for the introduction of the routing scaling solution - and thereby completely avoid encapsulation and its PMTUD complexities. On mobility - what is your objection to this arrangement? ETR-like Translating Tunnel Routers with two-way encrypted tunnels to mobile nodes. Mapping only changes to a new TTR when one is really needed 0 which is typically only when the MN moves 1000km or more. So mapping changes are not at all frequent and in particular are not needed every time the MN gets a new CoA: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf If I was proposing to the IETF that a WG be formed for my project, I would first want to establish for myself - and for IETF people in general - that my project was either the best in its class, or one of the very few with the most promise. I don't see how you can do that when you fail to read - or at least fail to discuss in public - alternative schemes to LISP. Ivip and APT are broadly comparable to LISP - they are all core-edge elimination schemes for both IPv4 and IPv6. They are both well enough documented to be suitable for serious critiques from anyone who believes LISP's approach is superior. Just because you have more people - with more experience and resources - working on LISP and have running code, doesn't mean your LISP-ALT design is better than APT or Ivip. - Robin _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 27 04:31:35 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2703A6A9E; Tue, 27 Jan 2009 04:31:35 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C953D3A6A9E for ; Tue, 27 Jan 2009 04:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 AgxC5rWcZf54 for ; Tue, 27 Jan 2009 04:31:33 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 7BF7C3A67A5 for ; Tue, 27 Jan 2009 04:31:33 -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 n0RCV74T021583; Tue, 27 Jan 2009 04:31:07 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0RCV7qV021582; Tue, 27 Jan 2009 04:31:07 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 27 Jan 2009 04:31:07 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090127123107.GA21545@1-4-5.net> References: <497E9BB2.5040101@firstpr.com.au> MIME-Version: 1.0 In-Reply-To: <497E9BB2.5040101@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) Subject: Re: [lisp] [lisp-interest] LISP PMTU - 2 methods in draft-farinacci-lisp-11 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: , Content-Type: multipart/mixed; boundary="===============0238584786==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0238584786== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Forwarding on behalf of Robin. Robin, the lisp list is at lisp@ietf.org these days. Thanks, Dave On Tue, Jan 27, 2009 at 04:29:22PM +1100, Robin Whittle wrote: > Short version: Stateless approach is a really bad idea in the future > when ~9000 byte MTU ITR to ETR paths become common. >=20 > Stateful approach somewhat resembles Ivip's approach > - which is documented in greater detail and limits > the number of traffic packets for which state must > be stored in case a PTB is received. >=20 > Here my thoughts on the two techniques (Stateless and Stateful) for > LISP Path MTU Discovery management in the latest (19 December) draft. >=20 > My understanding of the whole problem (for Ivip's map-encap modes or > for any other map-encap scheme, such as LISP or APT), together with > my solution for Ivip, is here: >=20 > http://www.firstpr.com.au/ip/ivip/pmtud-frag/ >=20 >=20 > Here is my critique of the Stateless approach, assuming L =3D 1500, as > is recommended at the end of: >=20 > http://tools.ietf.org/html/draft-farinacci-lisp-11#section-5.4.1 >=20 > The stateless approach was rejected by the OpenLISP team: >=20 > http://tools.ietf.org/html/draft-iannone-openlisp-implementation-01#secti= on-6.8.1 >=20 >=20 > Stateless IPv4 DF=3D0 > ------------------- >=20 > L is chosen for the entire global LISP system to be a minimum > value of MTU which can be expected of any ITR->ETR tunnel. Here > I assume 1500 bytes, as is recommended in the last line of section > 5.4.1. Perhaps it would need to be less, such as 1470 or less. > Google servers regularly send 1470 byte DF=3D0 packets: >=20 > http://www.firstpr.com.au/ip/ivip/ipv4-bits/actual-packets.html#google-no= -pmtud >=20 >=20 > IPv4 DF=3D0 packets longer than some size S will be fragmented > into two fragments, each of which will be encapsulated. The > ETR decapsulates them separately and sends the two fragments > to the destination network. >=20 > S is set globally to a value is L minus the encapsulation > overhead =3D 36 bytes. (IPv4, UDP and LISP headers, in section > 5.1). So S =3D 1464 bytes. >=20 > This will not work when the packet length is more than about > twice S (since fragmentation produces two packets whose > combined length is marginally longer than the original packet). >=20 > The statement: >=20 > "This will ensure that the new, encapsulated packets are of > size (S/2 + H), which is always below the effective tunnel MTU." >=20 > will not apply when the incoming packets are more than about > twice S in length. >=20 > Still, with a bit of tightening of the spec, I see no major > problems with this approach to IPv4 fragmentable packets compared > to what I propose for Ivip. I don't think a core-edge separation > scheme should be required to support DF=3D0 packets longer than > something like 1470 bytes into the indefinite future. >=20 > RFC 1191 PMTUD has been around since the early 1990s and I think > it is time that hosts stopped expecting the network to fragment > packets. The IPv6 designers evidently thought the same in 1996. >=20 >=20 >=20 > Stateless IPv4 DF=3D1 and IPv6 > ---------------------------- >=20 > This approach makes no sense for the long-term future since it > forces all traffic to be in packets no longer than 1464 (IPv4) > bytes: >=20 > the ITR will drop the packet when the size is greater than L, > and sends an ICMP Too Big message to the source with a value of > S, where S is (L - H). >=20 > Replacing the variables with constants for IPv4, this means: >=20 > the ITR will drop the packet when the size is greater than 1500 > bytes, and sends an ICMP Too Big message to the source with a > value of 1464 bytes. >=20 > For IPv6, the limiting size is set by the 56 byte overhead, to 1444 > bytes. >=20 > A proper solution should keep working well when the DFZ includes > MTUs of 9000 bytes between ITR and ETR - and should allow the > sending host to generate packets of nearly this size, so that once > encapsulated they still fit within whatever the MTU is for the > path to this ETR. >=20 > Fred Templin raised similar concerns: >=20 > http://www.irtf.org/pipermail/rrg/2009-January/000884.html >=20 > (My guess is that the non-DF=3D0 part of this approach was written > with an assumption that L would be individually determined by the > ITR for each ETR - but that is not the way the I-D is written: L is > fixed at 1500 bytes, and any such method would be stateful.) >=20 >=20 > Stateful approach for all packets > --------------------------------- >=20 > I am reading the LISP version - I have not looked in detail at the > OpenLISP source of this approach. >=20 > This makes no reference to IPv4 DF=3D0 packets. So this approach of > the ITR sending a PTB packet to the sending host when a DF=3D0 packet > exceeds some length is not going to result in any action on the part > of the sending host. Such a DF=3D0 packet will be dropped by the ITR. > That may be OK - Ivip will do much the same - but it needs to be > specified clearly. >=20 > This approach of determining the MTU to each ITR by receiving ICMP > messages from an intermediate router needs to be done securely. >=20 > It requires the ITR to cache significant amounts of information for > every packet it sends which might trigger such a PTB. >=20 > The intermediate router would need to send back sufficient of the > original packet to ITR to include the LISP nonce. Otherwise, PTBs > spoofed by off-path attackers would be accepted and the whole system > could easily be DoSed. >=20 > The ITR needs to store an initial fragment of each incoming traffic > packet for some time, so it can generate a PTB message for the > sending host. It can't rely on enough of the original packet coming > back in the PTB from the intermediate router. The ITR needs to cache > this for a second or two at least - while it waits for a possible > PTB. This is an onerous requirement in a high-volume ITR. >=20 > Ivip map-encap ITRs need to perform a stateful PMTU determination > process which is somewhat similar to this. However, the Ivip > approach quickly narrows the zone of uncertainty so that the number > of packets involved in testing PMTU is very limited. >=20 > The Ivip approach is specified in greater detail, including > occasionally sending longer packets (if and when the current or some > other sending host generates them) to see if the MTU has grown > since the last PTB set a limit on it, as far as the ITR was concerned. >=20 > - Robin >=20 >=20 >=20 >=20 >=20 --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) iEYEARECAAYFAkl+/osACgkQORgD1qCZ2KepNQCgjnCo4QPFXk+gmEXrdbJ/UKOz idsAn2PSkuNQ6TrcIAbyt66oEhL+7yMr =YHIq -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- --===============0238584786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0238584786==-- From lisp-bounces@ietf.org Tue Jan 27 04:38:51 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B423A6A8B; Tue, 27 Jan 2009 04:38:51 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B303A6A8B for ; Tue, 27 Jan 2009 04:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.033, 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 mbyxIJbsYrmQ for ; Tue, 27 Jan 2009 04:38:49 -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 0B4823A67A5 for ; Tue, 27 Jan 2009 04:38:49 -0800 (PST) Received: from [130.149.220.21] (kea.net.t-labs.tu-berlin.de [130.149.220.21]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 29E3770015D8 for ; Tue, 27 Jan 2009 13:38:31 +0100 (CET) Message-ID: <497F0031.8020401@net.t-labs.tu-berlin.de> Date: Tue, 27 Jan 2009 13:38:09 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: lisp@ietf.org X-Enigmail-Version: 0.95.0 Subject: [lisp] [Fwd: Re: [rrg] LISP PMTU - 2 methods in draft-farinacci-lisp-11] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Forwarding on my behalf ;-) Luigi -------- Original Message -------- Subject: Re: [rrg] LISP PMTU - 2 methods in draft-farinacci-lisp-11 Date: Tue, 27 Jan 2009 10:39:55 +0100 From: Luigi Iannone To: Robin Whittle CC: RRG , lisp-interest@lists.civil-tongue.net References: <497E9BB2.5040101@firstpr.com.au> Hi Robin, See few comments inline Robin Whittle wrote: > Short version: Stateless approach is a really bad idea in the future > when ~9000 byte MTU ITR to ETR paths become common. > > Stateful approach somewhat resembles Ivip's approach > - which is documented in greater detail and limits > the number of traffic packets for which state must > be stored in case a PTB is received. > > Here my thoughts on the two techniques (Stateless and Stateful) for > LISP Path MTU Discovery management in the latest (19 December) draft. > > My understanding of the whole problem (for Ivip's map-encap modes or > for any other map-encap scheme, such as LISP or APT), together with > my solution for Ivip, is here: > > http://www.firstpr.com.au/ip/ivip/pmtud-frag/ > > > Here is my critique of the Stateless approach, assuming L = 1500, as > is recommended at the end of: > > http://tools.ietf.org/html/draft-farinacci-lisp-11#section-5.4.1 > > The stateless approach was rejected by the OpenLISP team: > As a member of the OpenLISP team, let me say that we do not *accept* or *reject* anything. AFAICT, that is left to the community and to the (future) LISP WG. What we proposed is just an alternative approach that takes advantage of ICMP messages (if they are present). > http://tools.ietf.org/html/draft-iannone-openlisp-implementation-01#section-6.8.1 > > > [snip] > Stateful approach for all packets > --------------------------------- > > I am reading the LISP version - I have not looked in detail at the > OpenLISP source of this approach. > > This makes no reference to IPv4 DF=0 packets. So this approach of > the ITR sending a PTB packet to the sending host when a DF=0 packet > exceeds some length is not going to result in any action on the part > of the sending host. Such a DF=0 packet will be dropped by the ITR. > That may be OK - Ivip will do much the same - but it needs to be > specified clearly. > The text that we provided is just a first cut. I agree that there are several points to clarify. > This approach of determining the MTU to each ITR by receiving ICMP > messages from an intermediate router needs to be done securely. > Am I wrong if I say that this means to change the ICMP protocol? Our goal was not to introduce new mechanisms in the core, but rather to take advantage of what exists. > It requires the ITR to cache significant amounts of information for > every packet it sends which might trigger such a PTB. > Why should the ITR cache information? > The intermediate router would need to send back sufficient of the > original packet to ITR to include the LISP nonce. Otherwise, PTBs > spoofed by off-path attackers would be accepted and the whole system > could easily be DoSed. > Probably there is a DoS risk, but IMO is from on-path attackers. How can an off-path attacker know that a specific ITR is sending packets to a specific ETR and sen a fake ICMP message to shrink the MTU toward that specific ETR? > The ITR needs to store an initial fragment of each incoming traffic > packet for some time, so it can generate a PTB message for the > sending host. It can't rely on enough of the original packet coming > back in the PTB from the intermediate router. The ITR needs to cache > this for a second or two at least - while it waits for a possible > PTB. This is an onerous requirement in a high-volume ITR. > > No. This is not the case. Assume the following topology: H1-----------ITR1---------------ETR2-----------H2 where host H1 send packets to host H2. If a first packets triggers a ICMP PTB in the DFZ, this is sent back to ITR1, which sjust stores the fact that to reach ETR2 a smaller MTU must be used. Nothing is sent back to H1. H1 sends a second packet. On the ITR1 there will be a check on the MTU triggering a second ICMP PTB to be sent back to H1. So, you need to big packets in order to make the feedback reach the original sender, but the ITR does not need to store packets. Hope this clearer now. Cheers Luigi _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 27 05:23:17 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628393A6810; Tue, 27 Jan 2009 05:23:17 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0D43A6810 for ; Tue, 27 Jan 2009 05:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.524 X-Spam-Level: X-Spam-Status: No, score=-1.524 tagged_above=-999 required=5 tests=[AWL=0.371, 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 t3gF2m3LG+t8 for ; Tue, 27 Jan 2009 05:23:14 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 247053A67A5 for ; Tue, 27 Jan 2009 05:23:13 -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 0D6F8175716; Wed, 28 Jan 2009 00:22:54 +1100 (EST) Message-ID: <497F0B30.1010404@firstpr.com.au> Date: Wed, 28 Jan 2009 00:25:04 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: RRG References: <497E9BB2.5040101@firstpr.com.au> <497ED66B.8000505@net.t-labs.tu-berlin.de> In-Reply-To: <497ED66B.8000505@net.t-labs.tu-berlin.de> Cc: lisp@ietf.org Subject: Re: [lisp] [rrg] LISP PMTU - 2 methods in draft-farinacci-lisp-11 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Short version: Luigi suggests a method by which the ITR can perform PMTUD to an ETR without having to cache the original packet. This requires three things to be done to achieve the goals without the most obvious DoS vulnerabilities: 1 - The intermediate router sends back at least 16 bytes of original packet in the PTB - 8 bytes more than RFC 1191 requires. 2 - It is acceptable for the system not to deliver the first "too long" packet. 3 - The sending host sends a second "too long" packet after the ITR has received and processed the PTB from the intermediate router. If the system is supposed to work without the PTB check requiring the LISP nonce in the PTB's original packet fragment, then I think the ITR still needs to store some details of recently sent packets, to force the attacker to set some other parts of the PTB's original packet fragment to hard-to-guess actual values of packets sent. I modify my critique of LISP accordingly - this looks like a reasonable way to do PMTUD without the ITR maintaining a lot of state. However the smallest amount of state would be the LISP nonce of recently sent packets and this requires all intermediate routers which might have an MTU problem to send back more than the RFC 1191 minimum of 8 bytes. The process of checking PTBs in a busy ITR could become so expensive (due to the large number of LISP nonces or other details to be checked, of recently sent packets) that it could become a DoS vulnerability in itself. How I think an off-path attacker could find the addresses of some, many or most ITRs which are tunneling packets to some ETR the attacker wants to DoS. An ITR occasionally needs to allow longer packets to the ETR than its current MTU setting allows - otherwise it has no way of adapting to an increased actual path MTU. Hi Luigi, Thanks for your reply, in which you wrote: > As a member of the OpenLISP team, let me say that we do not > *accept* or *reject* anything. AFAICT, that is left to the > community and to the (future) LISP WG. OK - "rejected" was my way of stating that you didn't find the stateless approach suitable for OpenLISP: http://tools.ietf.org/html/draft-iannone-openlisp-implementation-01#section-6.8.1 6.8.1. OpenLISP local MTU Management During preliminary tests, we observed that the MTU issue is at the origin of many problems. OpenLISP does not (and will not) implement the fragmentation mechanism proposed in Sec. 5.4 of [I-D.farinacci-lisp]. The reason is because the proposed method sounds very primitive and does not appear to be efficient. The original LISP specification is based on an architectural constant used by the xTR to limit the MTU of LISP encapsulated packets. OpenLISP uses a more advanced solution, based on the real MTU of the local RLOCs present on the xTR, as described below. > What we proposed is just an alternative approach that takes advantage of > ICMP messages (if they are present). OK - your approach makes sense. I am reading it now. >> Stateful approach for all packets >> --------------------------------- >> >> I am reading the LISP version - I have not looked in detail at the >> OpenLISP source of this approach. >> >> This makes no reference to IPv4 DF=0 packets. So this approach of >> the ITR sending a PTB packet to the sending host when a DF=0 packet >> exceeds some length is not going to result in any action on the part >> of the sending host. Such a DF=0 packet will be dropped by the ITR. >> That may be OK - Ivip will do much the same - but it needs to be >> specified clearly. > > The text that we provided is just a first cut. I agree that there are > several points to clarify. OK. >> This approach of determining the MTU to each ITR by receiving ICMP >> messages from an intermediate router needs to be done securely. > > Am I wrong if I say that this means to change the ICMP protocol? I meant securely enough to prevent spoofing by an off-path attacker intent on DoS. (Full description below.) The LISP nonce should do the trick - but that requires the intermediate router to send back to the ITR, in the PTB message, the 8 byte LISP header after the UDP header. RFC 1191 only requires it to send back the outer IP header and the next 8 bytes - which in a LISP packet is the UDP header. This was a pretty short-sighted requirement, I think. I don't know how DFZ routers behave, but I recall someone (Bill Herrin?) stating some months ago that it was common to send back more bytes than the bare minimum of 8. If LISP or something similar was implemented in 5 years time, I guess it wouldn't be too much to ask the router manufacturers to create firmware updates if their routers don't already send back a decent number of bytes such as 32 or whatever. Without this, the ITR can't "securely" respond to ICMP PTB messages. > Our goal was not to introduce new mechanisms in the core, but rather to > take advantage of what exists. OK. >> It requires the ITR to cache significant amounts of information for >> every packet it sends which might trigger such a PTB. > > Why should the ITR cache information? Skip the following if you like: My understanding of what ITRs would have to do, before I read the rest of your message: For every encapsulated packet the ITR sends which might generate a PTB message in some router en-route to the ETR, the ITR needs to cache - I mean store for a few seconds - the start of the original packet and the nonce it put in the LISP header of the encapsulating header. I guess the ITR needs to store it for a few seconds, since it might take that long for the PTB to come back. Technically, maybe it should hold it for longer, but my guess is that 2 seconds should do the trick. Then, when a PTB arrives, the ITR needs to compare the LISP nonce in the PTB's fragment of the initial packet (see discussion above about how this requires more bytes than RFC 1191 requires) with its cached information about recently sent packets. It should also check other things such as the destination address in the packet fragment, to ensure it is the same as the ETR to which it tunnelled the packet. This will enable the ITR to uniquely identify one of the packets it recently sent. Then it can adjust for that ETR its record of path MTU, and generate a PTB packet to be sent to the sending host, from its cached fragment of the start of the original packet. After that, the ITR can use the stored value of MTU for that ETR and use it to decide whether to accept or reject with a PTB any packet to be tunneled to that ETR. I don't think your I-D doesn't mention this, but the ITR also needs to occasionally let a longer packet be encapsulated to this ETR - a packet long enough that once encapsulated it would exceed the ITR's current notion of path MTU to this ETR. This will only occur if and when one of the following occur: 1 - The original sending host, in the same communication session tries its luck with a longer packet for the same reason. RFC 1191 specifies the one sending host should not try a longer packet to a given destination address for 10 minutes after receiving a PTB. 2 - Some other sending host sending a longer packet through this ITR to an EID address which is mapped to the same ETR. 3 - The same sending host, in the same or another application, sending a long packet to a different destination address, which may or may not be in the same EID as the first destination address, which is mapped to the same ETR. Then, if the longer packet does not result in a PTB, the ITR should probably raise its notion of the MTU to that ETR accordingly. However, packet loss here (loss of the too long packet before the intermediate router with the limiting MTU, or loss of the PTB message from that router) could result in a too-long MTU setting in the ITR. This is not such a problem, since it would probably soon be corrected if subsequent packets passed through the ITR due to this too-high value and did result in a PTB being received by the ITR. The Ivip approach can use PTBs from intermediate routers, but does not rely on them absolutely. It uses positive and negative acknowledgement from the ETR for a small subset of packets which, once encapsulated, are of a length which falls within the ITR's "zone of uncertainty" for the path MTU to this ETR. This zone is reduced by every such packet and would, in general, quickly diminish to zero - after which the technique is only needed occasionally to test whether the MTU limit has risen. I think would be best to store the path MTU value in a separate body of data from however you store the mapping information. The mapping information is indexed on EID, I assume. You might have in the mapping cache thousands of entries which all use the same ETR. It makes no sense to store the ETR's path MTU in every one of those entries. I think the encapsulation process needs to check the path MTU to the ETR after it has determined which ETR address to tunnel each packet to. >> The intermediate router would need to send back sufficient of the >> original packet to ITR to include the LISP nonce. Otherwise, PTBs >> spoofed by off-path attackers would be accepted and the whole system >> could easily be DoSed. > > Probably there is a DoS risk, but IMO is from on-path attackers. How can > an off-path attacker know that a specific ITR is sending packets to a > specific ETR and send a fake ICMP message to shrink the MTU toward that > specific ETR? It is easy to find out where the ITRs of a particular ISP or end-user network are. Attackers could discover this by various means, but here is one: They get their own EID space, which is mapped to an RLOC address of one of their own machines - which pretends to be, or is, an ETR. Then, the attacker sends to some host in the ISP or end-user network a ping packet or any other packet which will elicit a response. That packet has a source address in the attacker's EID range, so the targeted host will send back a response to that address. The ITR in the targeted site will look up the mapping for the attacker's EID address and so tunnel the response packet to the attacker's "ETR". With LISP, APT and TRRP, the encapsulation outer header's source address is that of the ITR, so the attacker's "ETR" learns the address of the ITR. (With Ivip, the source address is that of the sending host.) So attackers can easily find the address of an ITR in some network of its choice where there are sending hosts. It could do this en-masse and so discover the addresses of ITRs in many such networks. The attacker presumably has some idea of where the sending hosts are for the destination network it wants to DoS. The attacker could find the addresses of Proxy Tunnel Routers which handle the attacker's EID. The attacker simply send packets from one of its own EID addresses to random IP addresses to get responses from a bunch of hosts, many of which will use a PTR (all those which don't have an ITR in their own network). If there were a single set of PTRs which handled every EID, then this would suffice to locate all PTRs in the world. However, at least in the Ivip model, there probably won't be OITRDs (the Ivip version of LISP's PTR) which handle every micronet. There seems to be no business plan for LISP PTRs, so I can't say how they would be organised. Assuming that there is one set of PTRs for one subset of the EID address space, and another set for another subset, then the above method will only allow the attacker to discover the PTRs which handle its subset. I can't easily think of a way an off-path attacker could find the addresses of the PTRs which handle the EID space of some network which the attacker wants to DoS. Nonetheless, attackers in general could figure out the addresses of PTRs in various PTR networks and share this information between themselves. So an attacker could find the addresses of some, many or most ITRs which might be tunneling packets to the site they want to DoS. The attacker presumably has a motivation to DoS a particular ETR. If the attacker wants to DoS the ETR(s) of a particular organisation, it can easily look up the mapping for that organisation's EID prefix to obtain the ETR addresses. With the ETR address and a list of ITR addresses, the attacker can inexpensively generate a sequence of spoofed PTB packets. (But see discussion below on how much information the ITR needs to store about recently sent packets, to force the attacker to correctly set length, checksum and (IPv4 only) Identification bits to match a packet actually sent, which the attacker, being off-path, can't see. Each such spoofed PTB, if recognised by the ITR, can be used to clobber the MTU the ITR perceives for the targeted ETR, so causing significant and reasonably persistent DoS for a potentially large number of sending hosts which rely on that ITR - and a potentially large number of destination hosts in potentially multiple destination networks which rely on this ETR. If the ITR requires the LISP nonce to be in the PTB fragment, then the system is secure against such spoofing, but then this PMTUD system will only work if all the intermediate routers which might cause an MTU problem send back at least 16 bytes rather than the RFC 1191 minimum of 8 bytes after the IP header. >> The ITR needs to store an initial fragment of each incoming traffic >> packet for some time, so it can generate a PTB message for the >> sending host. It can't rely on enough of the original packet coming >> back in the PTB from the intermediate router. The ITR needs to cache >> this for a second or two at least - while it waits for a possible >> PTB. This is an onerous requirement in a high-volume ITR. > > No. This is not the case. > Assume the following topology: > > H1-----------ITR1---------------ETR2-----------H2 > > where host H1 send packets to host H2. If a first packets triggers a > ICMP PTB in the DFZ, this is sent back to ITR1, which sjust stores the > fact that to reach ETR2 a smaller MTU must be used. Nothing is sent back > to H1. But that involves data loss. The Ivip approach is intended to avoid this. > H1 sends a second packet. On the ITR1 there will be a check on the MTU > triggering a second ICMP PTB to be sent back to H1. Ahh . . . OK, you can make it work this way if you accept data loss on the first large packet, expecting the sending host to generate another similarly large packet, which seems reasonable. I don't think this technique can be used with Ivip, but I will consider it when I write the PMTUD I-D. I withdraw my critique of LISP's stateful approach to PMTUD requiring storage of the initial part of longer packets for a few seconds. However, I think the text of draft-farinacci-lisp and your own OpenLISP I-D should be revised to make this process clearer. Still, if you are to check the nonce, you do need to store each nonce of recently sent packets. To do a proper check of the PTB, you need to store some packet details - to force the attacker to generate the correct Identification (IPv4 only) and Length bits from the IP header. Likewise, if you store the UDP checksum of recently sent packets, then you can force the attacker to get that right, which would be generally impossible except by lots of attempts for data packets. It would be easier to spoof the checksum and length of TCP SYN packets or some other commonly used short packets. To protect against that, your ITR would need to store the length of such (generally short) packets and make sure the potentially spoofed PTB message's MTU limit was not longer than the actual packet. This, combined with some general limit on how low you would accept the MTU to be according to any PTB, would probably make the system immune to this kind of attack. Also, I think you need to either check the LISP nonce (and accept the system will fail if the PTB original packet fragment doesn't contain it) or not expect it and so recognise that the system is open to a powerful DoS attack if you don't store a bunch of details of recent packets, and use them to carefully check all PTBs. This PTB checking process itself could represent a DoS vulnerability for a busy ITR. If it has a lot of details of packets recently sent - potentially hundreds of thousands or millions, I guess, and you are not requiring LISP nonces, then you still have to search through some long and constantly changing lists of packet details such as length, UDP checksum (IPv4 only) Identification etc. for every PTB received. This could easily get way out of hand - those cached lists of recent packet details are expensive enough to add to and clean out, and I guess they can't inexpensively be optimised for inexpensive searching to see which one matches a PTB. PTB messages are pretty short (inexpensive for the attacker to send) and could chew up a lot of ITR CPU power to process. Checking only a fraction of these PTBs (in order to limit the CPU time spent chewing through a flood of spoofed PTBs) would slow down the ITR's ability to adapt properly to actual MTU problems. > So, you need two big packets in order to make the feedback reach the > original sender, but the ITR does not need to store packets. > > Hope this clearer now. Yes - thanks. - Robin _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Tue Jan 27 08:01:36 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C5328C203; Tue, 27 Jan 2009 08:01:36 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42FE53A688D; Tue, 27 Jan 2009 07:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=-0.194, 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 krZtJVyb5ucP; Tue, 27 Jan 2009 07:54:03 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id F0D4C3A6ABB; Tue, 27 Jan 2009 07:54:02 -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 n0RFrjl0027186; Tue, 27 Jan 2009 07:53:45 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0RFrjHX027185; Tue, 27 Jan 2009 07:53:45 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 27 Jan 2009 07:53:45 -0800 From: David Meyer To: Jari Arkko Message-ID: <20090127155345.GA27142@1-4-5.net> References: <20090122211436.GA20128@1-4-5.net> <20090122212345.GC388@cisco.com> <20090122213114.GA21199@1-4-5.net> <497F16EC.2000802@piuha.net> MIME-Version: 1.0 In-Reply-To: <497F16EC.2000802@piuha.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) X-Mailman-Approved-At: Tue, 27 Jan 2009 08:01:35 -0800 Cc: int-area@ietf.org Subject: Re: [lisp] [Int-area] LISP agenda update 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: , Content-Type: multipart/mixed; boundary="===============0406546168==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0406546168== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jari, > The charter also needs a better description of the context, e.g., =20 > relation to IRTF work. Check the below. Dave --- LISP (Locator/ID Separation Protocol) Last Modified: 2009-01-27 Chair(s): Darrel Lewis TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Secretary: TBD =20 Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: The IAB's October 2006 workshop on Routing and Addressing Workshop [0] 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 via improved aggregation of RLOCs. However, in order to be efficiently aggregated, RLOCs must be allocated in a way that is congruent with the topology of the network ("Rekhter's Law"). Today's Provider Allocated IP address space is an example of this kind of allocation scheme. EIDs, on the other hand, are typically allocated along organizational boundaries. Since the network topology and organizational hierarchies are rarely congruent, it is difficult (if not impossible) to make a single number space efficiently serve both purposes. In summary, the Loc/ID split aims to decouple location and identity, thus allowing for efficient aggregation of the RLOC space, providing persistent identity in the EID space, and in some cases to providing for secure and efficient mobility. =20 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. LISP and companion documents (see below) are proposals that respond to the problems discussed at the IAB's October, 2006 Routing and Addressing Workshop [0]. The purpose of the WG is to work on the design on the LISP base protocol [1], the LISP+ALT mapping system [2], LISP Interworking [4] and LISP multicast [6]. 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 (presumably using technology developed in the SIDR working group) and/or other mapping systems. 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 Recommendations for Securing the LISP Mapping System to the IESG for Experimental. Jul 2010 Submit LISP for Multicast Environments to the IESG for Experimental.=20 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].=20 Aug 2010 Re-charter or close. Internet-Drafts: draft-farinacci-lisp-11.txt draft-farinacci-lisp-multicast-01.txt draft-fuller-lisp-alt-03.txt draft-lewis-lisp-interworking-02.txt Request For Comments: None References ---------- [0] Meyer, D. et. al., "Report from the IAB Workshop on Routing and Addressing", RFC 4984. [1] Farinacci, D. et. al., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-11.txt. [2] Fuller, V., et. al., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-03.txt [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-00.txt. [4] Lewis, D., et. al., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-02.txt. [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt. [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 --FL5UXtIhxfXey3p5 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) iEYEARECAAYFAkl/LgkACgkQORgD1qCZ2Kfz1QCgkPJY1meUYKEkusMfQt8NyUHO 0zwAn00kwrcVBGoC1DPHeyh809rYjfh5 =n6rI -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- --===============0406546168== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0406546168==-- From lisp-bounces@ietf.org Tue Jan 27 09:59:00 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAA328C193; Tue, 27 Jan 2009 09:59:00 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB7F28C1A8; Tue, 27 Jan 2009 09:58:58 -0800 (PST) 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 oESQcl-dPfS9; Tue, 27 Jan 2009 09:58:58 -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 EE7F33A6ABC; Tue, 27 Jan 2009 09:58:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,333,1231113600"; d="scan'208";a="134132309" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2009 17:58:40 +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 n0RHweG0026894; Tue, 27 Jan 2009 09:58:40 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0RHwVDj017851; Tue, 27 Jan 2009 17:58:40 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 12:58:33 -0500 Received: from cisco.com ([10.86.245.114]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 12:58:32 -0500 Date: Tue, 27 Jan 2009 12:58:29 -0500 From: Scott Brim To: Benson Schliesser Message-ID: <20090127175829.GL39727@cisco.com> Mail-Followup-To: Scott Brim , Benson Schliesser , lisp@ietf.org, routing-discussion@ietf.org, rrg@irtf.org, David Meyer , John Zwiebel References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 27 Jan 2009 17:58:32.0888 (UTC) FILETIME=[DE47D380:01C980A8] Authentication-Results: sj-dkim-3; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org I don't know which of the lists this is going to should be trimmed, or I would gladly do so. Excerpts from Benson Schliesser on Sun, Jan 25, 2009 05:53:49PM -0600: > My single-homed xTR (savvis) has one ALT peer right now (asp) and he > announces an aggregate net that covers my EID prefix. That's great > from a routing scale perspective. However if I were to multihome to > another net (dmm, for example) wouldn't I have to announce my EID > into the ALT via that path if I wanted to continue serving that EID > during an outage of my primary (asp) connectivity? You peer with your upstream ALT routers based on prefixes they are responsible for, and where the ALT routers are doesn't (necessarily) follow physical topology. For any prefix there will probably be more than one upstream ALT router. Yes, you announce your prefix to all upstream ALT routers responsible for the shorter including prefix. Table size should be minimal, depending on how things are configured in your neighborhood. It could just be default from each. At most it would be a set of highest-level prefixes, maybe some special ones, and some longer ones for local efficiency. > At the very least it has to be announced such that my primary > upstream sees it and can divert map-requests to my secondary path. > So do all of my xTRs need to have ALT tunnels to all of my EID > allocators in order to avoid de-aggregation in the ALT tables while > maintaining fault tolerant connectivity? What happens if an AS-wide > fault takes down all of my allocator's ALT routers? I understand > that my RLOCs are still aggregated by the underlying network's > routing regardless. Allocation is decoupled from ALT routers. RIRs may run high-level ALT routers but there may be intermediate ones too. For a particular prefix there should be multiple redundant ALT routers. For the most part they need to be within the region in which they are most used, even though some prefixes may be allocated and then move to completely different continents. > It would be good to discuss what all of this looks like for network > engineering purposes. For instance from the perspective of ALT traffic > engineering, an end-site xTR with end users surfing the web will probably > have a moderate collection of EID mappings that stay refreshed (Google, > Twitter, corp intranet, etc) and a small collection of mappings that get > used and expire (my blog, which nobody reads twice). This is different from > an xTR in front of a public website, which will basically build a huge > collection of mappings and have to worry more about the database size than > anything else. Right. The range in possible tactics is huge, and they all work as long as they speak the same protocol. Scott _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 28 05:15:04 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F181228C276; Wed, 28 Jan 2009 05:15:03 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68E928C276; Wed, 28 Jan 2009 05:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 Z79VUDuXZ4Mh; Wed, 28 Jan 2009 05:15:02 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 108A528C272; Wed, 28 Jan 2009 05:15:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,338,1231113600"; d="scan'208";a="126424202" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 28 Jan 2009 13:14:44 +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 n0SDEiPc018717; Wed, 28 Jan 2009 05:14:44 -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 n0SDEiU9010801; Wed, 28 Jan 2009 13:14: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, 28 Jan 2009 05:14:44 -0800 Received: from [10.31.245.108] ([10.21.84.68]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jan 2009 05:14:43 -0800 Message-Id: <1358FE71-B2B7-484B-9915-86CE35985C66@cisco.com> From: Dino Farinacci To: Scott Brim In-Reply-To: <20090127175829.GL39727@cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 28 Jan 2009 05:14:41 -0800 References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090127175829.GL39727@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 28 Jan 2009 13:14:43.0538 (UTC) FILETIME=[6268FB20:01C9814A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=911; t=1233148484; x=1234012484; 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]=20Economic=20issues=20of=20long- path=20/=20stretched=20routing |Sender:=20; bh=kjjbTHGHMsF3J7m9Du18LrECg9vknpmUZPqb5D3dRec=; b=VeEonZ4l0TwN04cLurIJ+IvYMaWcbPyfymc7gPw4V5zH0aHIQpzSP6SGUR ZfWq5tariMugz1TDtQT83O6hpu9tIW8B7OS5cUKhQ/uGsGI7GOGaFtr19oK2 KawOAxQjVr; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] Economic issues of long-path / stretched routing 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > You peer with your upstream ALT routers based on prefixes they are > responsible for, and where the ALT routers are doesn't (necessarily) > follow physical topology. For any prefix there will probably be more > than one upstream ALT router. Yes, you announce your prefix to all > upstream ALT routers responsible for the shorter including prefix. > Table size should be minimal, depending on how things are configured > in your neighborhood. It could just be default from each. At most it > would be a set of highest-level prefixes, maybe some special ones, and > some longer ones for local efficiency. And your neighborhood really doesn't need back-doors so we can keep the ALT hierarchical by shaping it as an acyclic tree and not a mesh of trees or a mess of links connecting up and down at *different* hierarchical levels like the underlying Internet is configured today. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 28 09:45:02 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953013A6B1C; Wed, 28 Jan 2009 09:45:02 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C4B3A6A74 for ; Wed, 28 Jan 2009 09:45:01 -0800 (PST) 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 X5W1O+kerCBe for ; Wed, 28 Jan 2009 09:45:01 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0DA003A67DA for ; Wed, 28 Jan 2009 09:45:01 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DB03B6BE5FF; Wed, 28 Jan 2009 12:44:42 -0500 (EST) To: lisp@ietf.org Message-Id: <20090128174442.DB03B6BE5FF@mercury.lcs.mit.edu> Date: Wed, 28 Jan 2009 12:44:42 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > From: Robin Whittle > The LISP team should do detailed critiques of APT and Ivip as part of > convincing IETF folks of the merits of LISP-ALT. Perhaps I'm confused, but I don't think the people working on LISP are trying to "convince" the IETF as a whole of the "merits of LISP". If some people out there in the Internet technical community think it looks good, and want to work on it, run it, etc, that's great; but if other people reach a contrary conclusion, and don't want to work on it, run it, etc (as is their choice), that's fine too. Sure, the people working on LISP would like to convince _some_ people that it's a good idea, so they get i) some help working on it (as much remains to be done), and ii) some places to deploy it (so some practical experience can be gained, in seeing how well it works, what problems crop up in actual service, etc), but that's a very different kettle of fish. Noel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 28 15:23:31 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AE83A6B2A; Wed, 28 Jan 2009 15:23:31 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3403A6B2A for ; Wed, 28 Jan 2009 15:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 DLr7CqhcQwiJ for ; Wed, 28 Jan 2009 15:23:30 -0800 (PST) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.181]) by core3.amsl.com (Postfix) with ESMTP id B13A03A63D3 for ; Wed, 28 Jan 2009 15:23:29 -0800 (PST) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :IW0NeQWrc+lwhhNjh1Z2K6NdlYX3YUP3q0u9XxCxGfSzuaPVaZi9ctfI Received: from [10.154.162.186] ([129.192.147.67]) by post.strato.de (klopstock mo24) (RZmta 18.13) with ESMTP id v0071bl0SNH2Vm for ; Thu, 29 Jan 2009 00:23:10 +0100 (MET) Resent-To: lisp@ietf.org From: Christian Vogt To: Dino Farinacci In-Reply-To: <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> Resent-From: Christian Vogt References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> Message-Id: <3103F803-D3A2-4757-86B6-7D8A97C679AC@ericsson.com> Resent-Date: Wed, 28 Jan 2009 15:23:05 -0800 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 28 Jan 2009 15:18:20 -0800 X-Mailer: Apple Mail (2.929.2) Resent-Message-Id: <20090128232329.B13A03A63D3@core3.amsl.com> Cc: rrg RG , int-area@ietf.org, routing-discussion@ietf.org, lisp@ietf.org Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org On Jan 24, 2009, Dino Farinacci wrote: >> 4 - LISP-ALT's Aggregation implies provider dependence. >> This is Christian Vogt's critique: >> http://psg.com/lists/rrg/2008/msg00259.html > > Not true. Aggregation here is for the EID-prefix. Service providers do > not carry EID-prefixes in their cores so you don't depend on them. The > decoupling of the address creates this. The dependence is now on the > ALT. And if your site resides in a specific region of the world, you > get > your EID-prefixes from that registry. So readdressing your domain > would > only occur if you moved it from one region to another (let's leave > mobile ASes out of this for now). Dino - There is a tradeoff between EID portability and path stretch along the ALT topology, and I believe the tradeoff made in LISP/ALT has been revised a few times. Portability of EID prefixes requires that the ALT topology follows EID-addressing. This leads to potentially longer-than-optimal paths along the ALT topology. Vice versa, if path stretch is to be limited, then portability of EID prefixes must be restricted. According to your email to Robin, LISP/ALT currently makes the following tradeoff: Portability of EID prefixes is limited geographically in order to curb path stretch along the ALT topology to the maximum that can happen within a geographical region. That's possible, of course. The cost is that networks scattered over different parts of the world, such as those of enterprises with global presence, cannot use a continuous address space internally -- even if they all attach to the same provider. - Christian _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 28 17:19:31 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66A728C1F8; Wed, 28 Jan 2009 17:19:31 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F9828C11F; Wed, 28 Jan 2009 17:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 uHSd1VxZyu2Z; Wed, 28 Jan 2009 17:19:29 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8E16A3A6899; Wed, 28 Jan 2009 17:19:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,340,1231113600"; d="scan'208";a="238637065" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Jan 2009 01:19:11 +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 n0T1JBWe005291; Wed, 28 Jan 2009 17:19:11 -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 n0T1JBKv008599; Thu, 29 Jan 2009 01:19:11 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, 28 Jan 2009 17:19:11 -0800 Received: from [10.24.197.109] ([10.21.74.187]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jan 2009 17:19:10 -0800 Message-Id: <440A01B3-E96C-461A-93EC-6FD8E74FC7D2@cisco.com> From: Dino Farinacci To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1057DFFA6@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 28 Jan 2009 17:19:06 -0800 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au><6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <497EB510.8060100@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1057DFFA6@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 29 Jan 2009 01:19:11.0257 (UTC) FILETIME=[97308890:01C981AF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=483; t=1233191951; x=1234055951; 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[Int-area]=20[rrg]=20Please=20respond=3 A=20Questions=20from=20the=20IESG=20as=20towhether=20a=20WG= 20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=9XQpk/a4R50JNyPkCQ9KVggNFSRunZDTl0IT9fFHD1c=; b=oLuxsZOx8t/OkkPL7cnWTRSNnAO9d0UDHasmGxBy2jsrKHdjgrSSCoWwhX n4cYroDPQNp4yrJv702DPMF+L6gOIVTgJeJ8ieJERGlEVuyeF54lydIxxezG WDcag4smhh; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: RRG , int-area@ietf.org, routing-discussion@ietf.org, lisp@ietf.org Subject: Re: [lisp] [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > The approach in the current LISP draft still relies on ICMPs > coming from anonymous network middleboxes (which Dino himself > has said that we cannot depend on), and provides insufficient I did not say that. I said you cannot depend on ICMP Unreachables. But ICMP TooBig and Time-Exceeded message are sent and are more dependable. That is, they can get lost when they are transmitted since they are single transmitted datagrams. But at least they are sent. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 28 18:52:33 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED3B3A6B56; Wed, 28 Jan 2009 18:52:33 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6C13A6B56; Wed, 28 Jan 2009 18:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 KpmZVmCC-0lw; Wed, 28 Jan 2009 18:52:31 -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 F13BD3A691E; Wed, 28 Jan 2009 18:52:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,340,1231113600"; d="scan'208";a="134906643" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 29 Jan 2009 02:52:13 +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 n0T2qDhL003672; Wed, 28 Jan 2009 18:52:13 -0800 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 n0T2qDwm003525; Thu, 29 Jan 2009 02:52:13 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, 28 Jan 2009 18:52:13 -0800 Received: from [10.24.197.109] ([10.21.74.187]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jan 2009 18:52:11 -0800 Message-Id: <83BCD1E8-9EDB-4D81-94E1-0823B957E08F@cisco.com> From: Dino Farinacci To: Christian Vogt In-Reply-To: <3103F803-D3A2-4757-86B6-7D8A97C679AC@ericsson.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 28 Jan 2009 18:52:04 -0800 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <3103F803-D3A2-4757-86B6-7D8A97C679AC@ericsson.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 29 Jan 2009 02:52:12.0315 (UTC) FILETIME=[95C266B0:01C981BC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3589; t=1233197533; x=1234061533; 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=20Please=20respond=3A=20Questions=20from= 20the=20IESG=20as=20to=20whether=20a=20WG=20forming=20BOF=20 is=20necessary=20for=20LISP |Sender:=20; bh=qrd/RARkhtJ0Gdwe9KVtZD0CdEsZ95qCkmw2o0nNFMY=; b=trULZT7LPldfpPJgTFohnC6aK2reDgzQ5+I0KVsuEOK/53uE+fUYfJUeps hqq1Fs+qQ0egdf11Aqd73z8FV0huKkhV/f/Z7n03utKrH+YtWHoCfZdZuk9q lodnfSYX1p; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rrg RG , int-area@ietf.org, routing-discussion@ietf.org, lisp@ietf.org Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > On Jan 24, 2009, Dino Farinacci wrote: > >>> 4 - LISP-ALT's Aggregation implies provider dependence. >>> This is Christian Vogt's critique: >>> http://psg.com/lists/rrg/2008/msg00259.html >> >> Not true. Aggregation here is for the EID-prefix. Service providers >> do >> not carry EID-prefixes in their cores so you don't depend on them. >> The >> decoupling of the address creates this. The dependence is now on the >> ALT. And if your site resides in a specific region of the world, >> you get >> your EID-prefixes from that registry. So readdressing your domain >> would >> only occur if you moved it from one region to another (let's leave >> mobile ASes out of this for now). > > > Dino - > > There is a tradeoff between EID portability and path stretch along the > ALT topology, and I believe the tradeoff made in LISP/ALT has been > revised a few times. Yes, but if you are portable within an aggregate boundary, you are okay. > Portability of EID prefixes requires that the ALT topology follows > EID-addressing. This leads to potentially longer-than-optimal paths And it does. > along the ALT topology. Vice versa, if path stretch is to be limited, > then portability of EID prefixes must be restricted. I envision the number of hops a Map-Request takes is 4 ALT-router hops. I think we can do that with how the aggregation and allocation assignment is done on the LISP network now. Now if the diameter of the tunnels are large, then there will be longer delays because the Map-Request will have to travel more physical hops. But I really think you are not going to find a better way. > According to your email to Robin, LISP/ALT currently makes the > following > tradeoff: Portability of EID prefixes is limited geographically in > order to curb path stretch along the ALT topology to the maximum that > can happen within a geographical region. Right that is the tradeoff, but a site in Europe is not going to move to the US. A new site that is added in the US will get EID-prefixes from ARIN and terminate it's tunnels to the routers in the allocation assignment hierarchy for ARIN. > That's possible, of course. The cost is that networks scattered over > different parts of the world, such as those of enterprises with global > presence, cannot use a continuous address space internally -- even if > they all attach to the same provider. Christian, when you come to IETF in the US and you use your VPN client to connect back home to Finland, and you go to a URL in San Jose (when you are at the SF IETF), your packets will to east over the Atlantic twice and back to the west coast. That's a delay we all seem to live with everyday. I am not justifying delay and I'm not at all saying this is going to happen on the ALT either. Remember this only happens for the first few packets to a new site when there is a cache miss from each ITR. You cannot push around 10^10 entries and store them everywhere. In fact there are chances with a push technology that you might have to store them in nodes that won't need them for use but will need to store them for distribution. That will be a big cost. So then you go get them when you need them. Please recall, for LISP to support such a large database (10^10 entries), it must be distributed. And you want them to be stored where the policy holders are for the mapping and you wan them to reside at the site that the mapping describes them. Dino > > > - Christian > > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Wed Jan 28 20:06:51 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F342228C27A; Wed, 28 Jan 2009 20:06:50 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCB528C27A for ; Wed, 28 Jan 2009 20:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 Q3cNbvfBs7J0 for ; Wed, 28 Jan 2009 20:06:50 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 1ABD228C205 for ; Wed, 28 Jan 2009 20:06:50 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CF45F6BE603; Wed, 28 Jan 2009 23:06:31 -0500 (EST) To: lisp@ietf.org Message-Id: <20090129040631.CF45F6BE603@mercury.lcs.mit.edu> Date: Wed, 28 Jan 2009 23:06:31 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > From: Christian Vogt > Portability of EID prefixes requires that the ALT topology follows > EID-addressing. This leads to potentially longer-than-optimal paths > along the ALT topology. Vice versa, if path stretch is to be limited, > then portability of EID prefixes must be restricted. Yes, but this is only for the first packet(s), until the mapping gets back to the ITR. Do you really think a few extra hops there are going to be a problem? (Especially given that due to EGP/IGP information flow barriers, paths probably aren't completely optimal anyway....) Also, what percentage of DNS resolutions take more than one round-trip (because of the use of multi-level DNS names)? Surely that's an even worse delay (several round-trips, as opposed to simply a few extra hops), but I don't think I've heard complaints about that? Noel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Thu Jan 29 18:04:47 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7153A6AA4; Thu, 29 Jan 2009 18:04:47 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7043A6AA4 for ; Thu, 29 Jan 2009 18:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.535 X-Spam-Level: X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=0.360, 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 osaeGF+b3SKG for ; Thu, 29 Jan 2009 18:04:45 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 481F53A6A63 for ; Thu, 29 Jan 2009 18:04:45 -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 7D64A175D74; Fri, 30 Jan 2009 13:04:24 +1100 (EST) Message-ID: <498260AB.902@firstpr.com.au> Date: Fri, 30 Jan 2009 13:06:35 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: RRG References: <497E9BB2.5040101@firstpr.com.au><497ED66B.8000505@net.t-labs.tu-berlin.de> <497F0B30.1010404@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1057A2DD3@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1057A2DD3@XCH-NW-7V2.nw.nos.boeing.com> Cc: "Templin, Fred L" , lisp@ietf.org Subject: Re: [lisp] [rrg] LISP PMTU - 2 methods in draft-farinacci-lisp-11 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Hi Fred, Thanks for these references, and some other PMTUD discussion in the "Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP" thread, which I will respond to here: >> I stand corrected about LISP's approach to PMTUD - the latest >> draft does include an outline of a workable solution. > > I don't know if you were fishing for a response, No. I meant it was at least going to work, if the PTBs contained the nonce. It may not work very well, but that is better than the stateless approach, which won't work at all. > but the > stateful solution outlined in the latest LISP draft still > has problems. It should also be mentioned that the approach > (drop first; return PTBs for subsequent) is not new and > has been proposed many times over the years. I hadn't heard of this approach before. I still think it has problems. > The approach in the current LISP draft still relies on ICMPs > coming from anonymous network middleboxes (which Dino himself > has said that we cannot depend on), Dino clarified this to say that he thinks we can rely on PTBs being sent - and generally rely on them being received: http://www.irtf.org/pipermail/rrg/2009-January/000899.html But ICMP TooBig and Time-Exceeded message are sent and are more dependable. That is, they can get lost when they are transmitted since they are single transmitted datagrams. But at least they are sent. I assume this is true - it makes sense. Anyone configuring a DFZ router or an internal router between any ITR and ETR would be badly mistaken not to allow generation of any PTBs. > and provides insufficient > means for authenticating any ICMPs that may come. For example, > even if the ICMPs were delivered, and even if they included > the LISP nonce, it would be impractical for the ITR to cache > enough nonces of enough recently-sent packets especially at > high data rates. I tend to agree, but it depends on how smart the ITR is about recognising "longer packets" and only caching details for that subset. There's no need for the ITR to cache a LISP nonce for the purposes of PMTUD if the packet is shorter than some constant below which it can be assumed there are no MTU problems. So VoIP packets and quite a few others will not need to have any nonce or other details cached. I wonder if there is a cryptographic approach to generating 32 bit nonces such that it is not necessary to cache each one in order to be able to verify that a nonce in a PTB matched a recently sent packet? For instance, for a period of a second or two, set a randomly selected set of 16 bits in the 32 bit nonce to some particular bit pattern, which is pseudo-random, which remains the same for the period and is cached. Then, change the other 16 bits for each generated nonce. Hmmm - this just makes it easier for an attacker to spoof a nonce. Maybe send the same nonce for all packets for 0.1 seconds . . . No - if an attacker can get a tunneled packet from this ITR to its own ETR then it use the nonce to spoof a PTB apparently from a tunnel to another ETR. Maybe there is some snappy crypto approach to this, but it needs to be lightweight when checking the nonce in a PTB - and knowledge of another recent nonce must not allow an attacker to improve their chances of spoofing a valid nonce of another packet tunneled to some other ETR. My plan in: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ is that a very small subset of packets get the special PMTUD treatment. Every such packet will result in a reduction of the zone of uncertainty about the path MTU to the ETR. Data will either be delivered or the ETR and therefore the destination network or the ITR will send a valid PTB to the sending host. Pretty quickly, ordinary RFC 1191 sending host behaviour will result in the zone of uncertainty being reduced to zero. Then, except for occasional attempts to try longer packets than the current estimate allows, or to confirm that packets are getting through when they are close to, or at, the current MTU limit, there is no special treatment of packets and so nothing to cache. (In Ivip, ordinarily tunneled packets hitting an MTU limit will not generate a PTB to the ITR - the PTB will go to the sending host and not be recognised there.) > So, the only option is to ignore ICMPs (leads to black holes) > or honor ICMPs (leads to denial of large packet service). If the ITR doesn't attempt to recognise PTBs, then it needs some other way of determining PMTU to the ETR - which involves special protocols between the ITR and ETR. This is part of what I am proposing. My approach does recognise PTBs if they are sent with enough of the offending packet to contain the nonce in the "Packet B", which is the same length as the original traffic packet would become with ordinary Ivip encapsulation. This requires the intermediate router send back at least 8 bytes more than the bare minimum 8 bytes required by RFC 1911. I think it is reasonable to expect DFZ and internal routers to do this. I recall someone writing that many do it already. It would be a straightforward config change or firmware update to make sure they all did it in time for the introduction of Ivip or any similar system. So secure recognition of PTBs is used by my system, but the system will still work without PTBs. > I have said this before, but AFAICT DF=1 is busted. I don't understand why. My approach should support any RFC 1191 sending host creating DF=1 packets as long as it likes, including as more and more paths between ITRs and ETRs change from ~1500 to ~9000 or whatever in the future. It is the DF=0 packets I think are a problem. I intend to handle them up to a certain length - something a little below 1500 bytes. Longer than that and the ITR will drop them. I think it is unreasonable for a sending host to expect the network to fragment its excessively long packets ca. 2015 or whenever Ivip or the like is deployed. RFC 1191 is a perfectly good approach and has been available since 1990. - Robin _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Fri Jan 30 08:28:42 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6013A6B68; Fri, 30 Jan 2009 08:28:42 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FBC23A6BF7; Wed, 28 Jan 2009 15:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 O0dXF9NIpN-f; Wed, 28 Jan 2009 15:18:44 -0800 (PST) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.181]) by core3.amsl.com (Postfix) with ESMTP id C6F233A6B2A; Wed, 28 Jan 2009 15:18:43 -0800 (PST) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :IW0NeQWrc+lwhhNjh1Z2K6NdlYX3YUP3q0u9XxCxGfSzuaPVaZi9ctfI Received: from [10.154.162.186] ([129.192.147.67]) by post.strato.de (mrclete mo3) (RZmta 18.13) with ESMTP id g061b3l0SMP2mf ; Thu, 29 Jan 2009 00:18:21 +0100 (MET) Message-Id: <3103F803-D3A2-4757-86B6-7D8A97C679AC@ericsson.com> From: Christian Vogt To: Dino Farinacci In-Reply-To: <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 28 Jan 2009 15:18:20 -0800 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> X-Mailer: Apple Mail (2.929.2) X-Mailman-Approved-At: Fri, 30 Jan 2009 08:28:41 -0800 Cc: rrg RG , int-area@ietf.org, routing-discussion@ietf.org, lisp@ietf.org Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org On Jan 24, 2009, Dino Farinacci wrote: >> 4 - LISP-ALT's Aggregation implies provider dependence. >> This is Christian Vogt's critique: >> http://psg.com/lists/rrg/2008/msg00259.html > > Not true. Aggregation here is for the EID-prefix. Service providers do > not carry EID-prefixes in their cores so you don't depend on them. The > decoupling of the address creates this. The dependence is now on the > ALT. And if your site resides in a specific region of the world, you > get > your EID-prefixes from that registry. So readdressing your domain > would > only occur if you moved it from one region to another (let's leave > mobile ASes out of this for now). Dino - There is a tradeoff between EID portability and path stretch along the ALT topology, and I believe the tradeoff made in LISP/ALT has been revised a few times. Portability of EID prefixes requires that the ALT topology follows EID-addressing. This leads to potentially longer-than-optimal paths along the ALT topology. Vice versa, if path stretch is to be limited, then portability of EID prefixes must be restricted. According to your email to Robin, LISP/ALT currently makes the following tradeoff: Portability of EID prefixes is limited geographically in order to curb path stretch along the ALT topology to the maximum that can happen within a geographical region. That's possible, of course. The cost is that networks scattered over different parts of the world, such as those of enterprises with global presence, cannot use a continuous address space internally -- even if they all attach to the same provider. - Christian _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sat Jan 31 11:50:17 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F82428C1D7; Sat, 31 Jan 2009 11:50:17 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EC63A6A8E; Sat, 31 Jan 2009 11:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 7kwwtJ4weDxQ; Sat, 31 Jan 2009 11:50:14 -0800 (PST) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.182]) by core3.amsl.com (Postfix) with ESMTP id 7C0AB3A67DA; Sat, 31 Jan 2009 11:50:13 -0800 (PST) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :IW0NeQWrc+lwhhNjh1Z2K6NdlYX3YUP3q0u9WROmBvx7THszQ1iClCjh Received: from [10.0.1.2] (c-71-198-187-109.hsd1.ca.comcast.net [71.198.187.109]) by post.strato.de (klopstock mo40) (RZmta 18.15) with ESMTP id L02617l0VJZoUu ; Sat, 31 Jan 2009 20:49:47 +0100 (MET) Message-Id: <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com> From: Christian Vogt To: Dino Farinacci In-Reply-To: <83BCD1E8-9EDB-4D81-94E1-0823B957E08F@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 31 Jan 2009 11:49:46 -0800 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <3103F803-D3A2-4757-86B6-7D8A97C679AC@ericsson.com> <83BCD1E8-9EDB-4D81-94E1-0823B957E08F@cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: rrg RG , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org On Jan 28, 2009, Dino Farinacci wrote: > You cannot push around 10^10 entries and store them everywhere. [...] Dino - I think we should experimentally compare ALT with other mapping systems before we decide whether pull-based or push-based mapping systems are better. Dismissing push-based mapping systems without corroborating data would be a bit premature in my opinion. In the absence of experimentation results, I would actually argue in favor of push-based mapping systems based on some analytical reasoning: Pull-based mapping systems have two important disadvantages compared to push-based mapping systems: - Performance penalty, i.e., additional propagation latencies for some packets, and higher loss probabilities for packets that take a sub- optimal path - Robustness penalty due to a new online dependency on components off the actual transmission path. (FWIW: All pull-based mapping systems have this penalty. Mapping requests must be routed via overlay infrastructure because the direct route is unknown at that time.) Furthermore, I do not share your concerns regarding push-based mapping systems: BGP is pushing routing data already today, and this works fine. Any routing-scalability-related issues with BGP are not due to BGP being push-based; they are due to frequent updates and a high load for core routers. Both of these issues would go away in an address indirection architecture (be it LISP, Ivip, APT, or Six/One Router), independent of whether you use a pull- or push-based mapping system. In conclusion: The overlay approach of ALT is certainly an interesting idea. But I think it would be premature to conclude that it is the only viable solution before we have more evidence to back this claim. - Christian PS: I admit that I have never been really good in avoiding cross- posting. But this is obviously my all-time negative record... _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sat Jan 31 11:56:17 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F214C3A694E; Sat, 31 Jan 2009 11:56:16 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5E628C1CB for ; Sat, 31 Jan 2009 11:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 qCXdRIZG07Fp for ; Sat, 31 Jan 2009 11:56:15 -0800 (PST) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.181]) by core3.amsl.com (Postfix) with ESMTP id 272F13A682D for ; Sat, 31 Jan 2009 11:56:10 -0800 (PST) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :IW0NeQWrc+lwhhNjh1Z2K6NdlYX3YUP3q0u9WROmBvx7THszQ1iClCjh Received: from [10.0.1.2] (c-71-198-187-109.hsd1.ca.comcast.net [71.198.187.109]) by post.strato.de (fruni mo13) (RZmta 18.15) with ESMTP id y05db1l0VILlHP ; Sat, 31 Jan 2009 20:55:49 +0100 (MET) Message-Id: <3841262C-A453-4DF7-8CDC-25D90148E2C9@ericsson.com> From: Christian Vogt To: Noel Chiappa In-Reply-To: <20090129040631.CF45F6BE603@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 31 Jan 2009 11:55:48 -0800 References: <20090129040631.CF45F6BE603@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.929.2) Cc: lisp@ietf.org Subject: [lisp] Delays in DNS vs. delays in pull-based 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org [ Forked from thread: "Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP". ] On Jan 28, 2009, Noel Chiappa wrote: > Also, what percentage of DNS resolutions take more than one round-trip > (because of the use of multi-level DNS names)? Surely that's an even > worse delay (several round-trips, as opposed to simply a few extra > hops), but I don't think I've heard complaints about that? Noel - There are two significant differences between the delays introduced by DNS during hostname resolution, and the delays introduced by a pull- based mapping system: - DNS-related delays do not affect transport protocols, whereas pull- based mapping systems do. - DNS does not create off-path dependencies for routing, whereas a pull-based mapping system does. In pull-based mapping systems, at least the mapping requests must travel via an overlay because the direct routing path is not yet known at the request time. This creates an off-path dependency for routing. The first bullet is a performance issue. Experimentation could help in finding out how much of a problem this is. The second bullet is a robustness issue. More analysis and discussion would help to better understand the consequences of this. - Christian _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sat Jan 31 12:25:27 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9D13A682D; Sat, 31 Jan 2009 12:25:27 -0800 (PST) X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72CD73A6AFE for ; Sat, 31 Jan 2009 12:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 fqPgwzzVjEnt for ; Sat, 31 Jan 2009 12:25:14 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 129D63A6AB6 for ; Sat, 31 Jan 2009 12:25:14 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2C8F86BE58D; Sat, 31 Jan 2009 15:24:55 -0500 (EST) To: lisp@ietf.org Message-Id: <20090131202455.2C8F86BE58D@mercury.lcs.mit.edu> Date: Sat, 31 Jan 2009 15:24:55 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > From: Christian Vogt > Any routing-scalability-related issues with BGP are not due to BGP > being push-based; they are due to frequent updates ... [this] > issue[] would go away in an address indirection architecture Not necessarily. It all depends on what functionality you're trying to get out of that layer of binding, i.e. how often the average binding changes. E.g. if you try and do some mobility through that binding layer (I'm not saying we should, just as an illustration) that will radically increase the rate/amount of updates. On a more general note, I actually did some 'back of the envelope' calculations a year or two ago, trying to decide whether to use push or pull, and my recollection is that the update rate numbers (i.e. the control traffic at each and every ITR) for push got fairly significant (in terms of the number of updates per second) even with only moderate numbers of mapping entries, and a fairly low assumed per-entry update rate (e.g. for provider changes only). Certainly, a full-push system is going to be distributing lots of mappings to boxes that never use them - my guess was something in the 99% region, if not much higher. (Long digression on the optimal mapping distribution system omitted - the points you raise are certainly valid, but there are good points on both sides, and I don't think the answer is clear-cut - if it were, we probably wouldn't still be discussing it.) Also, I'm not sure that for those working on LISP, ALT is the 'preferred' long-range answer to the question of 'what does the mapping subsystem look like'. I think the focus is on ALT at the moment in large part because it's fairly easy to deploy, because it re-uses existing code. (Dino et al, please correct me to the degree I am confused here.) It might well make sense to transition to something else in the long run - but then of course one has the transition issue to deal with, and from what thinking I have put into that particular problem, it's more problematic that some of the other long-term transition issues (e.g. to a different inter-xTR packet format, etc). So that would argue to make replacement of that subsystem priority number one... Noel _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp